Re: [qubes-users] Changing colors?

2018-08-20 Thread joeviocoe
On Monday, 26 March 2018 18:25:19 UTC-4, Chris Laprise  wrote:
> On 03/26/2018 05:08 PM, sevas wrote:
> > Ah, I mean to change the values of each color.
> > 
> > I want my green to be #00ffae and by blue to #00!
> > 
> > Vibrance!
> > 
> 
> IIRC, you can't edit the Xfce4 Qubes colors, but for KDE5 you can change 
> them in /home/user/.local/share/qubes-kde folder. At least you can with 
> Qubes 3.2; I don't know about Qubes 4.0 at this point.
> 
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

With xfce4, is there any way to change the title bar color of the default 
adwaita theme.  I want to keep the theme, but having dom0 as "blue" takes away 
from an already limited set of domain colors used for vms.  I don't want dom0 
looking too much like a DomU.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f2923265-e029-4628-860f-3550b4c3b21f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2018-08-20 Thread joeviocoe
Something unrelated completely corrupted my system.  dom0 got hosed and I was 
not able to recover. So I have reinstalled qubes from scratch, but this time I 
am using a software raid on 2 nvme pcie drives. 

Qubes 4 set up does allow for an encrypted raid the graphical setup.  It does 
not create an lvm.  I am using a separate drive with luks and an lvm thin pool.

So now I have 3 luks partitions opened on boot.  / (root), swap, and secondary 
drive that isn't important to the OS.

The way grub is set up by default now, is to have multiple "rd.luks.uuid=" 
parameters, one for each.  Also, after each luks parameter, if one of the raid 
volumes, there is a "rd.md.uuid=" parameter.
This works using a single luks passphrase at boot time.

Command line: placeholder root=UUID=9f9879f9-b275-4313-abef-1d99ecff7810 ro 
rd.luks.uuid=luks-4a69493c-62a7-4c2b-8f4b-a90133d925f5 
rd.luks.uuid=luks-d4d18b89-907e-47a2-bdc1-7da5096fc437 
rd.luks.uuid=luks-1dfee293-9d48-470b-8b53-d10ad9b13b0b 
rd.md.uuid=2d63c5de:209df367:6cc0fc7e:e96b1484 
rd.md.uuid=0a9b3000:21ca14f0:eea9dcd4:0fa1b693 i915.alpha_support=1 rhgb quiet 
rd.ykluks.hide_all_usb


So now I am thinking about your setup instructions, in this scenario.

>From what I've tested, multiple "rd.ykluks.uuid" and entries on the grub line, 
>tries to invoke multiple instances, and boot fails.  I then tried a single 
>rd.ykluks.uuid parameter with the comma separated uuids. And keep the existing 
>"rd.md.uuid" parameters after that. 

It doesn't work.  I just get a blinking cursor, no prompts or messages.
I've tried removing the "luks-" prefix on the UUIDs, but still fails.

If I remove the "rd.md.uuid" parameters... I do get prompted for yubikey 
password and it does begin to decrypt the volumes as expected.  But without the 
raid mounting "md" parameters... it doesn't boot from there.

My experience with dracut modules is very limited, but I want to test this RAID 
use case so your module is more robust.  What should I try next?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a1c607b0-5d1d-4e00-99e9-aa488d3212f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] VMWare vmdk converted to raw image - Will Not Boot (Windows or Linux)

2018-08-16 Thread joeviocoe
On Wednesday, 15 August 2018 06:52:02 UTC-4, awokd  wrote:

> 
> > $ qvm-create --verbose Win10 --class StandaloneVM --property
> > virt_mode=hvm --property kernel='' --property memory=4096 --property
> > maxmem=4096 --label=red --root-copy-from Win10.raw
> 
> How large is the root created when you use this method? Default is only
> 10GB, but both your images are much larger. Try manually creating the HVM
> without the copy, resizing the root volume to match the raw size, then
> "copy Win10.raw /dev/mapper/qubes_dom0-vm--Win10--root".

Yes.  Thank you.  That did it.

Set the system storage max size to greater than the filesytem size of the raw 
image.
dd if=Win10.raw of=/dev/mapper/qubes_dom0-vm--Win10--root

Now both boot.
 
I guess system storage should be a pref option in qvm-create, so we can still 
use --root-copy-from.  Or, better yet, determine size automatically and prompt 
the user to accept the larger storage size.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e3978e1-82bc-4394-8d56-8655b4987181%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2018-08-16 Thread joeviocoe
I love the new options.  It works great to open 3 luks volumes on boot now.  2 
of which have an LVM volume group for qubes, the 3rd just an extra ext4 volume.

Two questions:
1)  Can you execute multiple cryptsetup commands at the same time?  It has to 
wait a few seconds for each one in sequence, which lengthens the overall boot 
time.  Or would there be a problem if the script exits before all required luks 
volumes are open?  Maybe run cryptsetup commands with &, then finish by 
checking if all commands are complete.

2)   I would like a stealth mode where the default prompt is for the luks 
passphrase, just like it would be without your module.  In the background, 
looking for the yubikey.  When found, change the prompt to ask for the yubikey 
password.  But then systemd-ask-password would need to be something that can be 
cancelled/replaced by script, is that possible?  The other option would be to 
not change the prompt at all, and just run the ykchalresp command if the 
yubikey is detected, and skip it if not.

Let me know what you think.  
And thank you again for the hard work.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/37b463a3-0cf7-4caa-bf5d-c0181f9bd3b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2018-08-15 Thread joeviocoe
Thanks.  I'll try it.
What's the best to add the UUID?  I assume edit the grub.cfg directly.  But 
will kernel updates overwrite?  Do I need to edit something else and run dracut 
-f?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f09343a5-6ff7-4283-b8e2-d1df0e3a1b95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2018-08-15 Thread joeviocoe

> Please note that the current version will probably not work with a default 
> qubes LUKS-on-LVM installation. But if some experienced user is willing to 
> help testing i'll try to come up with a version that supports this too.
> 
> Besides the yubikey/luks stuff the module handles the rd.qubes.hide_all_usb 
> stuff via its own rd.ykluks.hide_all_usb command line parameter because the 
> yubikey is connected via USB and needs to be accessable until we got the 
> challenge from it. i am still unsure if this is the best method to implement 
> this. So if anyone with a deeper knowledge of qubes/dracut does have a 
> better/more secure solution i happy about any help.
> 
> Regards
> the2nd



So I've screwed up... when I filled up my LVM, I added a disk to the Volume 
Group and expanded the pool.  

But I didn't encrypt the new drive, thinking I had LVM on LUKS.  But I have 
this now.
[root@dom0]# lsblk | grep -v "\-\-" 
NAME MAJ:MIN RM   SIZE 
RO TYPE  MOUNTPOINT 
sdb8:16   0   3.7T  
0 disk   
└─sdb1 8:17   0   3.7T  
0 part   
  ├─qubes_dom0-pool00_tmeta  253:10   2.1G  
0 lvm   
  │ └─qubes_dom0-pool00-tpool253:30 1T  
0 lvm   
  │   ├─qubes_dom0-pool00253:60 1T  
0 lvm   
  │   ├─qubes_dom0-root  253:40 192.6G  
0 lvm   / 
  ├─qubes_dom0-pool00_meta0  253:63   0   2.1G  
0 lvm   
  └─qubes_dom0-pool00_tdata  253:20 1T  
0 lvm   
└─qubes_dom0-pool00-tpool253:30 1T  
0 lvm   
  ├─qubes_dom0-pool00253:60 1T  
0 lvm   
  ├─qubes_dom0-root  253:40 192.6G  
0 lvm   / 
sr0   11:01  1024M  
0 rom   
loop0  7:00   500M  
0 loop   
sda8:00 232.9G  
0 disk   
└─sda1 8:10 232.9G  
0 part   
nvme0n1  259:00 232.9G  
0 disk   
├─nvme0n1p1  259:10 1G  
0 part  /boot 
└─nvme0n1p2  259:20 231.9G  
0 part   
  └─luks-bfcca13a-213d-46ec-b156-53df348dba30253:00 231.9G  
0 crypt 
├─qubes_dom0-pool00_tdata253:20 1T  
0 lvm   
│ └─qubes_dom0-pool00-tpool  253:30 1T  
0 lvm   
│   ├─qubes_dom0-pool00  253:60 1T  
0 lvm   
│   ├─qubes_dom0-root253:40 192.6G  
0 lvm   / 
└─qubes_dom0-swap253:50  23.3G  
0 lvm   [SWAP] 


With this LVM on LUKS setup, extending the thin pool onto a new disk that was 
added to the volume group... winds up leaving plain text data on the new disk.


Here's what I think my setup will have to be: 

nvme0n1 (2 drives in hw RAID 0) 
├─nvme0n1p1   part  /boot 
└─nvme0n1p2   part   
  └─luks (same key)   crypt 
├─qubes_dom0-pool00_tmeta lvm   
├─qubes_dom0-pool00_tdata lvm   
│ └─qubes_dom0-pool00-tpool   lvm   
│   ├─qubes_dom0-pool00   lvm   
│   ├─qubes_dom0-root lvm   / 
│   └─ ... vm lvm 
└─qubes_dom0-swap lvm   [SWAP] 

sda  (2 drives in hw RAID 0) 
└─sda1part   
  └─luks (same key)   crypt 
└─qubes_dom0-pool00_tdata lvm   
  └─qubes_dom0-pool00-tpool   lvm   
├─qubes_dom0-pool00   lvm   
├─qubes_dom0-root lvm   / 
└─ ... vm lvm 

With your ykluks dracut module:
> The default Qubes OS installation is a LVM-on-LUKS setup which will not work 
> yet. Patches for LVM-on-LUKS are welcome as well as experienced testers 
> because a dont have a LVM-on-LUKS installation to test with.

I will be a tester for this.

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/08e39e6c-97f6-456b-b0c6-c09a86a8a856%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-14 Thread joeviocoe
I use a custom dracut module from the2nd, ykluks, so I don't know about how to 
modify it to unlock multiple volumes.
Also, I may want to stick with LUKS instead of ecryptfs because yubikey support.

Can you elaborate on the steps for using Btrfs during install of Qubes, the 
documentation is still pretty old and doesn't really go over the non standard 
options.

Does Qubes 4.0 need LVM for snapshots and backups while vm is running?  I 
haven't seen anything about why LVM thin provisioning is done on Qubes, or what 
I would lose if I went with something else like Btrfs or even Ext4.

Here's what I think my setup will have to be:

nvme0n1 (2 drives in hw RAID 0)
├─nvme0n1p1   part  /boot
└─nvme0n1p2   part   
  └─luks (same key)   crypt
├─qubes_dom0-pool00_tmeta lvm   
├─qubes_dom0-pool00_tdata lvm   
│ └─qubes_dom0-pool00-tpool   lvm   
│   ├─qubes_dom0-pool00   lvm   
│   ├─qubes_dom0-root lvm   / 
│   └─ ... vm lvm
└─qubes_dom0-swap lvm   [SWAP] 

sda  (2 drives in hw RAID 0)
└─sda1part   
  └─luks (same key)   crypt
└─qubes_dom0-pool00_tdata lvm   
  └─qubes_dom0-pool00-tpool   lvm   
├─qubes_dom0-pool00   lvm   
├─qubes_dom0-root lvm   / 
└─ ... vm lvm

And if I need another drive added (sdb),... I just insert the drive, create 
another luks partition, unlock, add to Volume Group (qubes-dom0), lvextend 
pool00?

-

What would Btrfs look like?
This?:

nvme0n1 (2 drives in hw RAID 0)
├─nvme0n1p1   part  /boot
└─nvme0n1p2   part
  └─luks (same key)   crypt
├─qubes (btrfs)   part  /
└─qubes_dom0-swap part  [SWAP] 

sda  (2 drives in hw RAID 0)
└─sda1part   
  └─luks (same key)   crypt
└─qubes (btrfs)   part  /

Under Btrfs, does qubes simply have each vm as a image file under the 
/var/lib/qubes/appvms// directory?  Do I lose the ability to backup 
live, or any other features?  How does performance compare to LVM

And to add another drive (sdb), how would I extend with Btrfs?

Thanks Chris.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fd83485c-3dab-4421-97b1-30d26388feb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: yubikey password

2018-08-14 Thread joeviocoe
On Tuesday, 14 August 2018 07:04:09 UTC-4, Brendan Hoar  wrote:
> On Monday, August 13, 2018 at 5:47:06 PM UTC-4, joev...@gmail.com wrote:
> > Are you sure they are using Yubikey's "Static Password" slot?  That is the 
> > only component that enumerates as a USB keyboard.  The normal yubikey setup 
> > enumerates as a Smartcard, which is how the challenge/response works.  With 
> > this, there is no keyboard to attach as an input device and no keystrokes 
> > to manage.  You attach the USB to the AppVM, and that's it.
> 
> Yubikeys are USB "composite" devices that can have one or more interfaces 
> enabled. 
> 
> [Note that while a USB *compound* device is a USB device with a built in USB 
> hub that has multiple USB devices attached, a USB *composite* device does not 
> incorporate a USB hub but instead presents as a single device with multiple 
> interface endpoints.]
> 
> A stock contemporary Yubikey NEO or Yubikey 4 may be shipped with the 
> following interfaces enabled all on the same single USB device: HID (with 
> superset of keyboard functionality to support a variety of OTP functions), 
> CCID (smartcard running multiple javacard applets), and U2F.
> 
> Yubikeys are also configurable such that each interface can been disabled as 
> necessary (for corporate roll out, compatibility with older software* that 
> doesn't handle multiple interfaces well, prevention of inadvertent OTP 
> generation, etc.). One cannot assume that a Yubikey that presents a CCID 
> interface will also provide a HID interface
> 
> Therefore "Normal Yubikey setup" is a moving target. :)
> 
> Brendan
> 
> * if you guessed OpenPGP, you get a star...though my experience with multiple 
> smartcards in use with Microsoft AD products tells me OpenPGP isn't the only 
> badly behaved smartcard client out there...

Thanks for the clarification Brendan.  I actually meant that a normal setup for 
yubikey,... on Qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d0217304-aafe-4b3b-a7a1-df09882194a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] VMWare vmdk converted to raw image - Will Not Boot (Windows or Linux)

2018-08-13 Thread joeviocoe
I have to work with VMWare images often, so I would like them to be run in 
Qubes.
They gave me a Windows 10 and a Kali vmware virtual machines.
Many people, including myself, have tested these as working in VMWare Player.  
There isn't a problem with the source.

The vmx files only points to the images I am converting, so I don't think I am 
missing something there.

-

$ file C-Drive.vmdk
C-Drive.vmdk: VMware4 disk image

$ qemu-img info C-Drive.vmdk
image: C-Drive.vmdk
file format: vmdk
virtual size: 100G (107374182400 bytes)
disk size: 13G
cluster_size: 65536
Format specific information:
cid: 1024382763
parent cid: 4294967295
create type: monolithicSparse
extents:
[0]:
virtual size: 107374182400
filename: C-Drive.vmdk
cluster size: 65536
format:

$ qemu-img convert -f vmdk C-Drive.vmdk -O raw Win10.raw

$ file Win10.raw
Win10.raw: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 
"Invalid partition table" at offset 0x17b "Error loading operating system" at 
offset 0x19a "Missing operating system", disk signature 0x8d1c10fa; partition 1 
: ID=0x7, active, start-CHS (0x0,32,33), end-CHS (0x3ff,254,63), startsector 
2048, 209711104 sectors

$ qemu-img info Win10.raw
image: Win10.raw
file format: raw
virtual size: 100G (107374182400 bytes)
disk size: 12G

$ sudo fdisk -l Win10.raw 
Disk Win10.raw: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8d1c10fa

Device  Boot Start   End   Sectors  Size Id Type
Win10.raw1 * 2048 209713151 209711104  100G  7 HPFS/NTFS/exFAT

--

$ qvm-create --verbose Win10 --class StandaloneVM --property virt_mode=hvm 
--property kernel='' --property memory=4096 --property maxmem=4096 --label=red 
--root-copy-from Win10.raw

When I start the VM... it boots to the Windows "Diagnostics" menu, and any 
attempts to fix/repair fail.
I have tried booting this VM to a Windows 10 iso to see if it could repair it 
too, no luck.

==

The Kali VM is similar, in that it will not boot using this convert to raw 
method.  It boots to the grub rescue menu.

The only difference between Kali and Windows VMware, is that Kali disk was 
split into a span of 8 vmdk's.  But qemu-img does create a single raw image as 
expected.

$ qemu-img convert -f vmdk *.vmdk -O raw Kali.img

$ qemu-img info Kali.img 
image: Kali.img
file format: raw
virtual size: 60G (64424509440 bytes)
disk size: 19G

$ file Kali.img 
Kali.img: DOS/MBR boot sector; partition 1 : ID=0x82, active, start-CHS 
(0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 123179008, 2648064 sectors

$ sudo fdisk -l Kali.img 
Disk Kali.img: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xaaea4a6f

Device Boot Start   End Sectors  Size Id Type
Kali.img1 *123179008 125827071 2648064  1.3G 82 Linux swap / Solaris



I've tried qvm-start with hddisk and cdrom option.  No luck there.
I've tried using VMWare's "ovftool" to package the vm, tar extract the single 
new vmdk, then convert to raw.
I've tried converting to qcow2.  
And tried running "testdisk" to find and fix MBR and partition tables.

I can mount the images to view the file systems if I want.  But somewhere in 
the conversion (qemu-img) or the VM creation (qvm-create ... root-copy-from), 
the MBR or partitioning gets screwed up and cannot boot.  I need to boot and 
run these VMs.

But I am lost.  It would seem straight forward, as everywhere I look on the 
internet, converting to raw is pretty easy and should work in Qubes 4.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/aeab97c6-4bab-46f5-bea9-6feb15d4eb58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] VMWare vmdk converted to raw image files, will not boot (Linux or Windows)

2018-08-13 Thread joeviocoe
I have to work with VMWare images often, so I would like them to be run in 
Qubes.
They gave me a Windows 10 and a Kali vmware virtual machines.

Many people, including myself, have tested these as working in VMWare Player.  
There isn't a problem with the source.

The vmx files only points to the images I am converting, so I don't think I am 
missing something there.

-

$ file C-Drive.vmdk
C-Drive.vmdk: VMware4 disk image

$ qemu-img info C-Drive.vmdk
image: C-Drive.vmdk
file format: vmdk
virtual size: 100G (107374182400 bytes)
disk size: 13G
cluster_size: 65536
Format specific information:
cid: 1024382763
parent cid: 4294967295
create type: monolithicSparse
extents:
[0]:
virtual size: 107374182400
filename: C-Drive.vmdk
cluster size: 65536
format: 

$ qemu-img convert -f vmdk C-Drive.vmdk -O raw Win10.raw

$ file Win10.raw
Win10.raw: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 
"Invalid partition table" at offset 0x17b "Error loading operating system" at 
offset 0x19a "Missing operating system", disk signature 0x8d1c10fa; partition 1 
: ID=0x7, active, start-CHS (0x0,32,33), end-CHS (0x3ff,254,63), startsector 
2048, 209711104 sectors

$ qemu-img info Win10.raw
image: Win10.raw
file format: raw
virtual size: 100G (107374182400 bytes)
disk size: 12G

$ sudo fdisk -l Win10.raw 
Disk Win10.raw: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8d1c10fa

Device  Boot Start   End   Sectors  Size Id Type
Win10.raw1 * 2048 209713151 209711104  100G  7 HPFS/NTFS/exFAT

--

$ qvm-create --verbose Win10 --class StandaloneVM --property virt_mode=hvm 
--property kernel='' --property memory=4096 --property maxmem=4096 --label=red 
--root-copy-from Win10.raw

When I start the VM... it boots to the Windows "Diagnostics" menu, and any 
attempts to fix/repair fail.
I have tried booting this VM to a Windows 10 iso to see if it could repair it 
too, no luck.

==

The Kali VM is similar, in that it will not boot using this convert to raw 
method.  It boots to the grub rescue menu.

The only difference between Kali and Windows VMware, is that Kali disk was 
split into a span of 8 vmdk's.  But qemu-img does create a single raw image as 
expected.

$ qemu-img convert -f vmdk *.vmdk -O raw Kali.img 

$ qemu-img info Kali.img 
image: Kali.img
file format: raw
virtual size: 60G (64424509440 bytes)
disk size: 19G

$ file Kali.img 
Kali.img: DOS/MBR boot sector; partition 1 : ID=0x82, active, start-CHS 
(0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 123179008, 2648064 sectors

$ sudo fdisk -l Kali.img 
Disk Kali.img: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xaaea4a6f

Device Boot Start   End Sectors  Size Id Type
Kali.img1 *123179008 125827071 2648064  1.3G 82 Linux swap / Solaris



I can mount drives and/or partitions to view the file systems.  But somewhere 
in the conversion (qemu-img) or the VM creation (qvm-create ... root-copy-from)

I've tried qvm-start with hddisk and cdrom option.  No luck there.
I've tried using VMWare's "ovftool" to package the vm, tar extract the single 
new vmdk, then convert to raw.
I've tried converting to qcow2.  
And tried running "testdisk" to find and fix MBR and partition tables.

But I am lost.  It would seem straight forward, as everywhere I look on the 
internet, converting to raw is pretty easy and should work in Qubes 4.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/25a5af10-101c-464f-8de4-a0be3336ef8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: yubikey password

2018-08-13 Thread joeviocoe
> That's a TemplateBasedHVM and InputKeyboard is running, but (as you say) 
> not allowed - I advised creating a HVM (Standalone) and you'll see it works. 
> You refer to this case below. 

It's not InputKeyboard that is the problem, it is Qubes-Gui.  StandaloneVMs Not 
based on a Template, won't have any qubes services running.  But attaching a 
USB keyboard is also not possible.  
For my test, my AppVM (Kali) was installed from an ISO (not a template), and I 
installed Qubes services/agents from deb packages.  This allowed USB 
passthrough, but I never got the qubes-gui installed.  So it does work.

> People have reported using yubikeys in this configuration in the past. 

I have read a lot of the yubikey / qubes implementations, as I am currently 
using one.
Are you sure they are using Yubikey's "Static Password" slot?  That is the only 
component that enumerates as a USB keyboard.  The normal yubikey setup 
enumerates as a Smartcard, which is how the challenge/response works.  With 
this, there is no keyboard to attach as an input device and no keystrokes to 
manage.  You attach the USB to the AppVM, and that's it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9c4f62c4-4fa6-4be8-9c02-4d5681d30e5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread joeviocoe
On Monday, 13 August 2018 17:13:06 UTC-4, Chris Laprise  wrote:
> On 08/13/2018 04:47 PM, 
> > Related question.
> > 
> > If I installed Qubes and used LUKS encryption (I have to run cryptsetup 
> > openLuks just to see the LVM inside)... then I add physical drives to my 
> > Volume Group, and start adding more AppVMs to the pool, that starts writing 
> > to the PV...
> > Is the data on the new drive, encrypted?
> > Can anyone forensically pull data from those new AppVMs since it wasn't 
> > originally a part of the LUKS encrypted drive?
> 
> Based on the sparse description I'd say No, the new space is not 
> encrypted. You have to add separate LUKS/dmcrypt block layers to those 
> new devices and then treat those dmcrypt block devices as the new pvs.
> 
> If you're doing this to qubes_dom0, then it could be a little tricky 
> getting all of the encrypted "pvs" to unlock at the same time during the 
> boot process. You'd need to investigate how crypttab and grub 
> accommodate that multi-volume setup.
> 
> -- 
> 
> Chris Laprise
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


I would imagine it would require a longer grub entry with rd.luks attributes 
for other UUIDs.

But it seems I have an LVM over LUKS configuration... when what I want is a 
LUKS over LVM.

Here's what I have:

[root@dom0]# lsblk | grep -v "\-\-"
NAME MAJ:MIN RM   SIZE 
RO TYPE  MOUNTPOINT
sdb8:16   0   3.7T  
0 disk  
└─sdb1 8:17   0   3.7T  
0 part  
  ├─qubes_dom0-pool00_tmeta  253:10   2.1G  
0 lvm   
  │ └─qubes_dom0-pool00-tpool253:30 1T  
0 lvm   
  │   ├─qubes_dom0-pool00253:60 1T  
0 lvm   
  │   ├─qubes_dom0-root  253:40 192.6G  
0 lvm   /
  ├─qubes_dom0-pool00_meta0  253:63   0   2.1G  
0 lvm   
  └─qubes_dom0-pool00_tdata  253:20 1T  
0 lvm   
└─qubes_dom0-pool00-tpool253:30 1T  
0 lvm   
  ├─qubes_dom0-pool00253:60 1T  
0 lvm   
  ├─qubes_dom0-root  253:40 192.6G  
0 lvm   /
sr0   11:01  1024M  
0 rom   
loop0  7:00   500M  
0 loop  
sda8:00 232.9G  
0 disk  
└─sda1 8:10 232.9G  
0 part  
nvme0n1  259:00 232.9G  
0 disk  
├─nvme0n1p1  259:10 1G  
0 part  /boot
└─nvme0n1p2  259:20 231.9G  
0 part  
  └─luks-bfcca13a-213d-46ec-b156-53df348dba30253:00 231.9G  
0 crypt 
├─qubes_dom0-pool00_tdata253:20 1T  
0 lvm   
│ └─qubes_dom0-pool00-tpool  253:30 1T  
0 lvm   
│   ├─qubes_dom0-pool00  253:60 1T  
0 lvm   
│   ├─qubes_dom0-root253:40 192.6G  
0 lvm   /
└─qubes_dom0-swap253:50  23.3G  
0 lvm   [SWAP]


Even better, I should look into a RAID setup too.  
If I choose btrfs for my next install, I can avoid the LVM problems, but can I 
expand onto new physical volumes by adding more drives?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a43f228b-819b-449f-916e-658bfba2a128%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread joeviocoe
Related question.

If I installed Qubes and used LUKS encryption (I have to run cryptsetup 
openLuks just to see the LVM inside)... then I add physical drives to my Volume 
Group, and start adding more AppVMs to the pool, that starts writing to the 
PV...
Is the data on the new drive, encrypted?
Can anyone forensically pull data from those new AppVMs since it wasn't 
originally a part of the LUKS encrypted drive?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fb9e3b7d-472e-42d6-ba46-f11f9974d0c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread joeviocoe
On Monday, 13 August 2018 16:13:06 UTC-4, Chris Laprise  wrote:
> On 08/13/2018 06:48 AM, 'awokd' via qubes-users wrote:
> > On Mon, August 13, 2018 7:59 am, 
> > 
> >> Should I mount each LV
> >> and attempt to import the root.img and private.img files? How would I
> >> mount those to get to the files, and how would import to Qubes?
> > 
> > Sounds pretty FUBARd. LVs don't have .img files; if you can manage to get
> > them mounted you might be able to recover contents. Boot from some
> > recovery distribution and get the Qubes PV attached, then "mount 
> > /dev/mapper/qubes_dom0-vm--vmname--private" for example.
> 
> Thin LVs can be imaged like normal volumes, however. I would try 
> 'vgchange -ay' then 'lvchange -ay' on the drive and then look for the 
> vm*private volumes in /dev/mapper.
> 
> Once you got that, you can do stuff like this to backup:
> 
> # dd if=/dev/mapper/qubes_dom0-vm--work--private | gzip >work_img.gz
> 
> and this to restore:
> 
> #  gunzip -c work_img.gz | dd 
> of=/dev/mapper/qubes_dom0-vm--work--private conv=sparse
> 
> This example is unencrypted, so take care with the remaining backup details.
> 
> Also keep in mind that thin-provisioned lvm is still pretty young -- it 
> is NOT 'like' regular non-thin lvm, but more like a new filesystem on 
> top of regular lvm. If reliability is high on your list then Btrfs may 
> be better... it seems to be older with a lot more people using it, and 
> has more internal error-correction mechanisms (but it still isn't 
> recommended for RAID5/6). Btrfs is worth considering as an alternative.
> 
> -- 
> 
> Chris Laprise
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

Thanks.

Is Btrfs an option when installing Qubes 4.0?

BTW,
Qubes fully recovered.

Like last time I messed things up by filling up the LVM,
Here are the steps:

Insert a bigger drive
create PV from new drive
added PV to VG
LVmove pool00_tdata from full drive to new PV
LVextended Pool00 to give room
LVextended pool00_tmeta (this was the corrupted part)
LVconvert --repair qubes_dom0/pool00
I did try all this yesterday, but the drive I put in, had a previous Qubes 4 
install. Even with deleting the partitions, it seemed to still recognize the 
Volume Group information on it. And since it is also named qubes_dom0... it 
really messed things up and had me going down rabbit holes with a VG with a 
MISSING PV. No commands really work when in that stuck state.

The issue still remains if anything will be done with Thin Provisioning to 
prevent this from happening. Last time this happened, there was no disk storage 
applet. This time, there was, but I just didn't see what a vmdk file was going 
to be on disk.

Should VMs get automatically paused when approaching the limit?
Also, should dom0 be inside the thin pool? Or would it make sense to keep it as 
its own LV? Yeah, it means dom0 cannot grow with the pool, but should it?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6ee3-cf40-494f-9d33-50757a45c178%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)

2018-08-13 Thread joeviocoe
Qubes OS 4.0

Well, I broke my Qubes.
I was messing with a large vmdk converted to raw image, expanded to 100G on a 
Volume Group that could not handle it.

Some errors did pop up, but with the space filled up, I could not do anything.
After reboot, no vms would start.
After attempting to repair using lvm2 tools, will no longer boot up.


I don't know enough about thin provisioning. I may have made it worse by 
attempting to add another Physical Volume. The volume I added was a 
re-partitioned disk that had a previous Qubes 4 install on it... which also had 
the same volume group name of qubes_dom0. This was causing all sorts of trouble 
like causing the PV to be MISSING (which stops most commands from executing). 
While the VG included this new PV, I attempted to expand the Pool00 and its 
metadata. Expanding to a new PV had resolved the last time I ran out of space. 
But this time it seemed to make things much worse.

I think I am going to have to reinstall Qubes onto some new drives that I will 
buy and possibly RAID.
My question is, what is the easiest way to recover the qubes?

I do have some backups, but...

If I wanted to move LVs over to the new Qubes, is that as easy as changing the 
VG name, and moving the whole pool?
Should I mount each LV and attempt to import the root.img and private.img 
files? How would I mount those to get to the files, and how would import to 
Qubes?

Most LVs say, "Thin's thin-pool needs inspection."
I have tried repairing:

root@kali:~# lvconvert --repair qubes_dom0/pool00
Using default stripesize 64.00 KiB.
terminate called after throwing an instance of 'std::runtime_error'
  what():  transaction_manager::new_block() couldn't allocate new block
  Child 15634 exited abnormally
  Repair of thin metadata volume of thin pool qubes_dom0/pool00 failed 
(status:-1). Manual repair required!

I could not fix this by adding another disk to the VG.


Here are the outputs you may be wanting:

root@kali:~# lvmdiskscan 
  /dev/nvme0n1   [ 232.89 GiB] 
  /dev/loop0 [   2.45 GiB] 
  /dev/mapper/q1 [ 231.88 GiB] LVM physical volume
  /dev/nvme0n1p1 [   1.00 GiB] 
  /dev/sda1  [ 232.88 GiB] LVM physical volume
  /dev/nvme0n1p2 [ 231.88 GiB] 
  /dev/sdb3  [   3.64 TiB] 
  /dev/sdd1  [  58.84 GiB] 
  /dev/sdd4  [ 667.00 MiB] 
  0 disks
  7 partitions
  0 LVM physical volume whole disks
  2 LVM physical volumes

I got /dev/mapper/q1 after cryptsetup luksOpen /dev/nvme0n1p2 q1

root@kali:~# pvs
  PV VG Fmt  Attr PSize   PFree 
  /dev/mapper/q1 qubes_dom0 lvm2 a--  231.88g 15.80g
  /dev/sda1  qubes_dom0 lvm2 a--  232.88g 0 

root@kali:~# vgs
  VG #PV #LV #SN Attr   VSize   VFree 
  qubes_dom0   2  59   0 wz--n- 464.76g 15.80g

root@kali:~# lvs
  LV VG Attr   LSize   Pool   
Origin  Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 qubes_dom0 twi-cotzM- 425.47g  
  90.48  99.95   
  root   qubes_dom0 Vwi-a-tz-- 192.59g pool00   
  99.95  
  swap   qubes_dom0 -wi-a-  23.29g 
...


Please let me know how much, if anything is recoverable.
Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ad5c4410-3371-44d9-a428-37b04619f141%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: yubikey password

2018-08-12 Thread joeviocoe
On Sunday, 12 August 2018 09:59:57 UTC-4, Unman  wrote:
> On Fri, Aug 10, 2018 at 11:00:30AM -0700, :
> > On Friday, 10 August 2018 11:31:08 UTC-4, Unman  wrote:
> > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, 
> > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should 
> > > > say something like this.
> > > > 
> > > > sys-usb  dom0 allow,user=root
> > > > 
> > > > Yes, If you have a sys-usb set up, then the USB keyboard will attach 
> > > > there first.  More specifically, the USB Host Controller that the USB 
> > > > keyboard is plugged into is attached to sys-usb.  But the keyboard 
> > > > device is immediately sent to dom0 per the rpc policy.  Because a 
> > > > keyboard that stays attached to sys-usb, can only type into sys-usb.  
> > > > And not the interactive window you see when you open up a terminal for 
> > > > sys-usb... but rather its own session.
> > > > dom0 needs the keyboard and mouse.  The USB Host Controller still 
> > > > resides in sys-usb, but the USB raw data passes to dom0 upon boot.
> > > > 
> > > > Unfortunately, the rpc policy is generic based on all USB devices 
> > > > enumerating as a keyboard.  So it may not be able to selectively attach 
> > > > a yubikey to an AppVM.
> > > > 
> > > 
> > > But the point is that the yubikey will be attached to a different qube,
> > > and can be treated as a keyboard there. This means that one can
> > > selectively link the yubikey to distinct qubes for input there, and the
> > > sys-usb policy will not be relevant.
> > > The Input.Keyboard policy needs to be set for the qube to which the
> > > yubikey is attached.
> > 
> > Yeah, that would be nice if it were that granular.  
> > 
> > I don't have my yubikey set for a static key, but let me test this with my 
> > input stick, which is like a USB rubber ducky.  It enumerator as a 
> > keyboard, and I have just attached it to the app VM I am typing on.
> > I am speech to text on my phone, Bluetooth to InputStick USB and typing 
> > into here.
> > 
> > It only works with, "sys-usb dom0 allow,user=root" in 
> > /etc/qubes-rpc/policy/qubes.InputKeyboard 
> > And it does NOT work with "sys-usb APPVM_NAME allow,user=root".
> > No USB device attaching is needed, as the rpc rule simple allows dom0 
> > access to sys-usb keyboard.
> > 
> > As I said... Keyboards need to be sent to dom0, or else it cannot type in 
> > the GUI.  
> > 
> > This will work for all USB keyboards as you cannot specify Yubikey 
> > keystrokes only type in a single AppVM.  Not the most secure... which is 
> > why Qubes recommends PS2 keyboards if running on a desktop and using the 
> > built in keyboard on laptops. It avoids the USB blanket rule for keyboards 
> > going to dom0.  And since LUKS encryption passphrases are entered after 
> > initramfs hides usb from boot process, a non-usb keyboard is essential for 
> > full disk encryption.
> > 
> > All that said,
> > it is still a much more secure option to use ykchalresp which comes with 
> > yubikey tools.  The USB device that does this function is not the keyboard 
> > part, and you have to explicitly Attach to the VM you want.  Also, no 
> > static key to be sniffed or accidentally typed somewhere.  I use it for 
> > KeePass, LUKS, PAM.d login, OTP tokens, everything.  
> > 
> > 
> 
> What you say about connecting keyboards isn't quite true.
> If you have passed the device through to a qube, then you need to set
> the policy *for that qube*. i.e -
>  dom0 allow, user=root
> 
> I don't use yubikeys so I cant speak for them, but that works for
> keyboards. It does mean that the attached keyboard input *could* be sent to
> any qube after user error.
> 
> Of course, the granularity of passthrough is currently missing, but it's 
> possible
> to hack this in various ways.
> 
> If you create a HVM and assign it a USB controller, then usb attached
> devices can insert key strokes *without* using qubes.InputKeyboard. This
> looks like a reasonable approach if you have more than one controller,
> and keeps the usb keystrokes confined to the qube.
> 
> If you only have one controller, then you could stop the Sender service
> in the qube, let the keyboard do it's stuff in that qube, remove the
> yubikey, and then re-enable the service. A bit unwieldy but security
> always comes at a price, and you could automate this with a key
> combination.
> 
> It's also possible to use qrexec to directly pass keystrokes from one
> qube to another. You can manually run the input proxy service and pipe
> it through to another qube. I've hacked this via dom0 (poc) and it works
> fine - you also need to process the /dev/input/event input to generate
> keyboard input in X in the qube, but that's pretty standard. If it's of
> interest I could work this up.
> 
> unman

> "If you have passed the device through to a qube, then you need to set 
the policy *for that qube*. i.e -  dom0 allow, user=root "

Yes, and I did say that before,
"It only works with, "sys-usb dom0 allow,user=root" in 

Re: [qubes-users] Re: yubikey password

2018-08-10 Thread joeviocoe
On Friday, 10 August 2018 11:31:08 UTC-4, Unman  wrote:
> On Fri, Aug 10, 2018 at 07:39:45AM -0700, 
> > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should say 
> > something like this.
> > 
> > sys-usb  dom0 allow,user=root
> > 
> > Yes, If you have a sys-usb set up, then the USB keyboard will attach there 
> > first.  More specifically, the USB Host Controller that the USB keyboard is 
> > plugged into is attached to sys-usb.  But the keyboard device is 
> > immediately sent to dom0 per the rpc policy.  Because a keyboard that stays 
> > attached to sys-usb, can only type into sys-usb.  And not the interactive 
> > window you see when you open up a terminal for sys-usb... but rather its 
> > own session.
> > dom0 needs the keyboard and mouse.  The USB Host Controller still resides 
> > in sys-usb, but the USB raw data passes to dom0 upon boot.
> > 
> > Unfortunately, the rpc policy is generic based on all USB devices 
> > enumerating as a keyboard.  So it may not be able to selectively attach a 
> > yubikey to an AppVM.
> > 
> 
> But the point is that the yubikey will be attached to a different qube,
> and can be treated as a keyboard there. This means that one can
> selectively link the yubikey to distinct qubes for input there, and the
> sys-usb policy will not be relevant.
> The Input.Keyboard policy needs to be set for the qube to which the
> yubikey is attached.

Yeah, that would be nice if it were that granular.  

I don't have my yubikey set for a static key, but let me test this with my 
input stick, which is like a USB rubber ducky.  It enumerator as a keyboard, 
and I have just attached it to the app VM I am typing on.
I am speech to text on my phone, Bluetooth to InputStick USB and typing into 
here.

It only works with, "sys-usb dom0 allow,user=root" in 
/etc/qubes-rpc/policy/qubes.InputKeyboard 
And it does NOT work with "sys-usb APPVM_NAME allow,user=root".
No USB device attaching is needed, as the rpc rule simple allows dom0 access to 
sys-usb keyboard.

As I said... Keyboards need to be sent to dom0, or else it cannot type in the 
GUI.  

This will work for all USB keyboards as you cannot specify Yubikey keystrokes 
only type in a single AppVM.  Not the most secure... which is why Qubes 
recommends PS2 keyboards if running on a desktop and using the built in 
keyboard on laptops. It avoids the USB blanket rule for keyboards going to 
dom0.  And since LUKS encryption passphrases are entered after initramfs hides 
usb from boot process, a non-usb keyboard is essential for full disk encryption.

All that said,
it is still a much more secure option to use ykchalresp which comes with 
yubikey tools.  The USB device that does this function is not the keyboard 
part, and you have to explicitly Attach to the VM you want.  Also, no static 
key to be sniffed or accidentally typed somewhere.  I use it for KeePass, LUKS, 
PAM.d login, OTP tokens, everything.  


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/150e4742-af7f-4b9c-84b6-4a52faf600e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: yubikey password

2018-08-10 Thread joeviocoe
Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should say 
something like this.

sys-usb  dom0 allow,user=root

Yes, If you have a sys-usb set up, then the USB keyboard will attach there 
first.  More specifically, the USB Host Controller that the USB keyboard is 
plugged into is attached to sys-usb.  But the keyboard device is immediately 
sent to dom0 per the rpc policy.  Because a keyboard that stays attached to 
sys-usb, can only type into sys-usb.  And not the interactive window you see 
when you open up a terminal for sys-usb... but rather its own session.
dom0 needs the keyboard and mouse.  The USB Host Controller still resides in 
sys-usb, but the USB raw data passes to dom0 upon boot.

Unfortunately, the rpc policy is generic based on all USB devices enumerating 
as a keyboard.  So it may not be able to selectively attach a yubikey to an 
AppVM.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7615fd30-64e4-4594-bd7c-be4b58ecd5c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: yubikey password

2018-08-10 Thread joeviocoe
On Wednesday, 8 August 2018 13:34:14 UTC-4, Arnulf Maria Bultmann  wrote:
> Hello,
> I use my yubikey besides other things as a password safe. under windows there 
> is no problem to use the yubikey to type in the password into keepass.
> Now I want to use the yubikey for thesame procedure under qubes 4.0.
> I use a security-vm for keepass and connect the yubikey from sys-usb to 
> security-vm. It's no problem to use the personalization gui. but how can I 
> use the yubikey in this vm as a kind of usb-keyboard to put the stored 
> password into keepass or for example an editor?
> thanks in advance for your help
> Arnulf

I don't think USB keyboards attach to AppVMs normally.  They attach to dom0, 
and use the qubes-gui windows manager to type and control mouse movement and 
clicks.
So if you were to attach it to an AppVM.. I am not sure it could even type into 
the session you are viewing.  Keyboards and mice have to attach to dom0 in 
order for it to interact with the windows it renders.


Have you considered using Chal/Resp instead of static password?  It is way more 
secure since you are not using one password for everything... and the secret 
never gets send across USB.  Keepass works with Challenge / Response, and even 
works with LUKS encryption of Qubes OS.  KeeChallenge and OtpKeyProv plugin for 
Keepass running on mono in a debian AppVM.  Then you can attach the Yubikey to 
that vm, and Challenge Response with something you know.. opens the vault.
http://richardbenjaminrush.com/keechallenge/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/225ee7fe-639a-4099-b307-ff4a2718d73a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

2018-02-10 Thread joeviocoe
Yubikey can have different modes of authentication.  I remember looking at the 
work of adubois last year as a possible solution.
My Yubikey has a slot used for Challenge/Response, which is MUCH easier to work 
with when you have multiple systems and devices.

I guess YubicoOTP would require something like a custom PAM module... but with 
Challenge/Response, my solution was to use the built-in pam_exec.so to run a 
very short script when authenticating.

The only dependency is to install ykpers on sys-usb as it uses ykchalresp.

https://gist.github.com/Joeviocoe/929ebde1066a22491bf93ccc9d6c0ba3

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e5d1abf4-4627-4a09-927c-ec4294cc481d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Display blank / won't refresh image after suspend/resume (if inverted/rotated)

2018-02-08 Thread joeviocoe
In RC4.0... After suspend/resume
Any monitors that were inverted or rotated, will be black.
The mouse does move across the screen... but no objects move on this screen.

Refreshing the configurations by toggling to another terminal (ctrl-alt-f2) 
then back again (ctrl-alt-f1), or changing the resolution/position of screens 
in xrandr/arandr/etc/... will restore the last known image on the affected 
monitors.

Reconfiguring the affected screen to remove invert/rotate settings does restore 
the image refreshing ability. The monitors behave normal, but I need them 
inverted.

Logging off or restarting X server does not fix the issue.
A reboot is needed to restore the desired behavior of having a working and 
inverted screen.

Very problematic as I do need to suspend resume a lot.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/41d8329d-6ab7-4e14-89b4-9173aa5abc3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS 4.0-rc4 has been released!

2018-02-02 Thread joeviocoe
Great, thank you so much.

Can you please update https://www.qubes-os.org/doc/releases/4.0/schedule/
Thanks again

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1d403e22-bf5f-4c13-91e1-47438b7a4994%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to deal with Yubikey ?

2018-02-02 Thread joeviocoe
On Friday, 2 February 2018 01:03:14 UTC-5, ThierryIT  wrote:
> Le jeudi 1 février 2018 18:01:21 UTC+2, awokd a écrit :
> > On Thu, February 1, 2018 3:46 pm, ThierryIT wrote:
> > > What am I doing wrong ?
> > >
> > >
> > > I have a Yubikey4 U2F + CCID.
> > > Not detected with "qvm-block"
> > > Detected as sys-usb:4-2 by dom0 (qvm-usb).
> > >
> > >
> > > I have tried:
> > >
> > >
> > > - qvm-device usb attach vm_name sys-usb:4-2  (device attached failed)
> > > - qvm-device block attach vm_name sys-usb:4-2 (backend vm 'sys-usb'
> > > doesn't expose device 4-2)
> > 
> > Another poster said these aren't block devices, so don't try to use those
> > commands on it.
> > 
> > "qvm-device usb attach vm_name sys-usb:4-2" should work. What does
> > "qvm-usb attach vm_name sys-usb:4-2" do?
> > 
> > If it's the same error, did you install qubes-usb-proxy in your templates?
> > See https://www.qubes-os.org/doc/usb/.
> 
> I have installed "qubes-usb-proxy" on my StandaloneVM.
> -> qvm-usb l : sys-usb:4-2 Yubico_Yubikey_4_U2F+CCID
> 
> -> qvm-device usb attach vm-name sys-usb:4-2 : Device attach failed: No 
> device info received, connection failed, check backend side for details
> -> same things

You are using qvm-usb command to list... but are using "qvm-device" to attach?  
I don't think that is a valid command in Qubes 3.2.  Do you mean qvm-pci?

You should be using qvm-usb to both list, and attach/detach usb devices.
Run qvm-usb -h... follow the manual.
usage: qvm-usb -a [options]  :

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2392b43e-4964-4322-944c-9ff6771098b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to deal with Yubikey ?

2018-01-31 Thread joeviocoe
qvm-usb command shows you how to attach USB devices to VMs.  There is no GUI 
method like there is for block devices.  

Remember, Yubikey is not a storage/block device.  It is a USB that acts more 
like a HID keyboard.  

Mine works on 3.2 just fine using sys-usb, then attaching to whatever VM needs 
it.

On Wednesday, 31 January 2018 09:14:36 UTC-5, ThierryIT  wrote:
> How did you attached it ? I am trying without success ... I can attached it 
> from dom0 using: qvm-block a vm_name dom0:sdd 
> Is it correct under Qubes4.0r3 ?
> 
> 
> Le mardi 23 janvier 2018 09:51:17 UTC+2, Kushal Das a écrit :
> > On Tue, Jan 23, 2018 at 12:17 PM, ThierryIT  wrote:
> > > Hello,
> > >
> > > I have today to deal with two problems:
> > >
> > > 1) I am using Yubikey to be authentified on some web site like Github ...
> > > 2) I am using Yubikey to stock my PGP keys and to use them with mainly my 
> > > emails (Thinderbird+Enigmail)
> > >
> > > What to do under Qubes to make this possible ?
> > > I have already sys-usb running.
> > 
> > On Qubes 4.0rc3, I just attach it to the vm as required, and use it.
> > No configuratino is required.
> > 
> > Kushal
> > -- 
> > Staff, Freedom of the Press Foundation
> > CPython Core Developer
> > Director, Python Software Foundation
> > https://kushaldas.in

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/008377f5-41d4-4460-ae36-2accec859729%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!

2018-01-12 Thread joeviocoe
P.S.

Can you please update https://www.qubes-os.org/doc/releases/4.0/schedule/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0c5bfb06-5fd0-4217-a03c-cbadc6857ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!

2018-01-12 Thread joeviocoe
Great news.  Thank you.

I would prefer a fully functional Qubes Manager since a widget that requires 
mouse click or hover is a pain in the butt to keep as a running dashboard.  
That is what I like about the 3.2 version... that I can keep it in one of my 
extra monitors.  Seeing CPU spikes without having to drill down for it is 
convenient.

Thanks again.

On Friday, 12 January 2018 21:58:03 UTC-5, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> The Qubes VM Manager will be returning in Qubes 4.0-rc4, which is
> scheduled for release next week. The returning Qubes Manager will be
> slightly different from the 3.2 version. Specifically, it will not
> duplicate functionality that is already provided by the new 4.0
> widgets. Specific examples include attaching and detaching block
> devices, attaching and detaching the microphone, and VM CPU usage.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZdZwACgkQ203TvDlQ
> MDB4GBAAqKQKgbUHWuTpzfW8o2HOjvM/fSxt9gSlDi+tS3x/dogNC0riO6VgFIJr
> zNUm2/7nYF4iAiES0HamgVfNBHFpKY1QZgRYyokrLMK78HmCyIKJ3A0cF2LOvlsS
> x88xpwBL0zwUX0y/eqsaxGGIqr9D1c25psYdi/IeE3KhR35gz/2j8HiB1/mEl0Z4
> JvepszI6HD7vJ41ullWsygHemTT2JAeFSCG0zWrfdxvkwYFQgXEn+AeEhgOL6BhM
> RXFuMWnl2w0cbnPgDpnmT0IVHlz8gRsljkyWLkqT4k/pldhy9OCjtMKuHGIaaen6
> KLF2rGkpVObfgQQrQOdll03KrFqPona5ywtdeQUMDGVoNJXuhFidyCLWEKPBlAhS
> LDCb/UxRbbPhwol4eEYeOnxWbCMgEwnEtnkEZiT4m9y3lQQLK+8zSZpW5uMLDzs0
> om9Xd9iba7hZomXE1rEcg2UaYok0lSQmzGS2YKh3OQbEmXtrZdILXVo0NLtDcTun
> q47PzYjKc82ZeUZSLBjfkgf0mhocPuwk3FLsMb3rwW0kEbzuRZjHKgxgnRbOK67b
> qH0roZ8GHrX7Xu4AvjYxUvlkTU+h2ObPMvxf2IR1/S37UUyrwNFEaC6czA/VmVV6
> 5SzFVGJkH/SFZsQ9qvzgjz/8OnLOMvBi3X/ee21G8s4ACmcrmrM=
> =fcWR
> -END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e4f0c35-164c-4631-a51c-502ce7c57b46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Hardware not supported on Qubes 4.0 rc2

2017-10-27 Thread joeviocoe
On Thursday, 26 October 2017 13:37:10 UTC-4, Anirban Kar  wrote:
> My Hardware:
> Processor- AMD Athlon X2 5200
> Mobo- Asrock 960GC-GS FX
> RAM- DDR2 800 MHz 2× 2GB
> HDD - Seagate 250 GB SATA 7200 rpm
> 
> 
> I can install and use Qubes 3.2 without any hassel but facing a hardware 
> incompatibility notification while installing Qubes 4.0 rc2. Ignoring the 
> notification and installing Qubes 4.0 rc2 results to a system which does not 
> have a sys-net vm. I am adding a screenshot of the notification. I am quite 
> sure that my processor supports AMD-V.

iommu:
  'no'

Says it all.
Read the release notes and blog posts on rc1 and rc2.  PV vs. HVM was the 
difference between the two.

qvm-prefs sys-net virt_mode pv

This may work, but future versions of qubes are going away from PV all 
together, so AMD-Vi (IOMMU) will be a requirement.
I upgraded my hardware for this reason.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9e711662-fa28-47f4-b1db-009a8485d2a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Hardware not supported on Qubes 4.0 rc2

2017-10-26 Thread joeviocoe
On Thursday, 26 October 2017 13:37:10 UTC-4, Anirban Kar  wrote:
> My Hardware:
> Processor- AMD Athlon X2 5200
> Mobo- Asrock 960GC-GS FX
> RAM- DDR2 800 MHz 2× 2GB
> HDD - Seagate 250 GB SATA 7200 rpm
> 
> 
> I can install and use Qubes 3.2 without any hassel but facing a hardware 
> incompatibility notification while installing Qubes 4.0 rc2. Ignoring the 
> notification and installing Qubes 4.0 rc2 results to a system which does not 
> have a sys-net vm. I am adding a screenshot of the notification. I am quite 
> sure that my processor supports AMD-V.

In Qubes 3.2 run an HCL Report and make sure directio is shown.  Post the 
report here.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/db1e50e4-26f2-4fe7-a5d5-8e53fb538423%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Windows 10 guest support (in Qubes 4.x)?

2017-10-25 Thread joeviocoe
On Wednesday, 25 October 2017 15:59:47 UTC-4, Yethal  wrote:
> 
> Code is on GitHub, nothing's stopping you from forking/sending a pull request

Please refrain from "just do it yourself" responses in the Qubes-Users group 
forum.  
People here are not developers, which has its own group forum.  This is why the 
original post ended with, "...raise some funding so that a capable developer 
can work on this topic."

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d60b506e-201c-4042-ba6b-e66799ed9950%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2017-10-24 Thread joeviocoe
On Sunday, 22 October 2017 08:56:55 UTC-4, the2nd  wrote:
> Regarding the other questions/problems.
> 
> 2) If you want to unlock the luks device without yubikey you can use the 
> steps from the "Something went wrong :(" section, skipping step 4. This 
> should disable the ykluks module and re-enable normal luks handling for one 
> boot.
> 
Thanks.

> 3) I do have two notebooks with Qubes 3.2 and yubikey for luks unlock Both do 
> a re-prompt on wrong password. Can you please describe in detail what steps 
> could be used to reproduce?
I actually meant to write originally, that it is not a problem with wrong 
password.  But rather a timeout if waiting for a while.  Entering the password 
after a few minutes results in an error and I must reboot.
> 
> Thanks
> the2nd
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Oct 3, 2017 at 5:11 AM, Ron Hunter-Duvar  wrote:
> On 10/02/2017 08:34 PM, joev...@gmail.com wrote:
> 
> 
> On Saturday, 5 August 2017 11:20:27 UTC-4, the2nd  wrote:
> 
> 
> Hi,
> 
> 
> 
> i switched to Qubes OS 3.2 on my notebook some weeks ago. Besides some issues 
> i had it works very well.
> 
> 
> 
> One problem was to get the installer to install qubes on LVM-on-LUKS. I 
> preferred this over the default LUKS-on-LVM setup because you dont have to 
> encrypt any LV separately.
> 
> ...
> 
> Please note that the current version will probably not work with a default 
> qubes LUKS-on-LVM installation. But if some experienced user is willing to 
> help testing i'll try to come up with a version that supports this too.
> 
> 
> 
> Besides the yubikey/luks stuff the module handles the rd.qubes.hide_all_usb 
> stuff via its own rd.ykluks.hide_all_usb command line parameter because the 
> yubikey is connected via USB and needs to be accessable until we got the 
> challenge from it. i am still unsure if this is the best method to implement 
> this. So if anyone with a deeper knowledge of qubes/dracut does have a 
> better/more secure solution i happy about any help.
> 
> 
> 
> Regards
> 
> the2nd
> 
> 
> This is working great for me.
> 
> A few questions though:
> 
> 
> 
> 1)  The default Qubes 3.2 install seems to be LVM-on-LUKS where there is only 
> one LUKS encryption and root/swap LVMs within that.  So your instructions 
> work with the default install.
> 
> 
> 
> ...
> 
> 
> I'd have to say that the2nd is right. I didn't notice on my first Qubes 3.2 
> install, because I only had one encrypted partition on my OS drive (skipped a 
> swap partition, despite the installer's whining). Second time around I gave 
> in and created one.
> 
> 
> 
> lsblk shows sda2 with a luks-encrypted / within it, and sda3 with a 
> luks-encrypted swap. If it were LVM-on-LUKS, it would be a single 
> luks-encrypted partition two logical volumes within it.
> 
> 
> 
> Ron
> 
> 
> 
> PS: I'm a Qubes-noob, but long-time Linux user.
> 
> 
> 
> -- 
> 
> You received this message because you are subscribed to a topic in the Google 
> Groups "qubes-users" group.
> 
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/qubes-users/hB0XaquzBAg/unsubscribe.
> 
> To unsubscribe from this group and all its topics, send an email to 
> qubes-users...@googlegroups.com.
> 
> To post to this group, send email to qubes...@googlegroups.com.
> 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/814cee70-0b5c-12a4-ee3e-bdb1f5479f3e%40shaw.ca.
> 
> 
> 
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/78d52a21-22fd-4fea-9c24-996ec5d86ad9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2017-10-24 Thread joeviocoe
On Monday, 23 October 2017 23:42:56 UTC-4, the2nd  wrote:
> Is there only one line? Or one line per uuid? Can you provide the complete 
> Output?
> 
> 
> Regards
> the2nd
> 
> 
> 
> Am 24.10.2017 5:31 vorm. schrieb "Ron Qubed" :
> 
> On Sunday, October 22, 2017 at 6:56:55 AM UTC-6, the2nd wrote:
> 
> > Hello,
> 
> >
> 
> > sorry for the long delay. Didnt had time to answer.
> 
> >
> 
> > If some of you is willing to help with testing LUKS-on-LVM could you please 
> > provide the output of the commands below?
> 
> >
> 
> > sudo su -
> 
> > . /usr/lib/dracut/modules.d/99base/dracut-lib.sh
> 
> > getarg rd.ykluks.uuid
> 
> >
> 
> > If you have not modified your grub config for the ykluks dracut module yet 
> > use this getarg command:
> 
> > getarg rd.luks.uuid
> 
> ...
> 
> > Thanks
> 
> > the2nd
> 
> 
> 
> getarg rd.ykluks.uuid outputs nothing for me. But then, I'm not using a 
> Yubikey.
> 
> 
> 
> getarg rd.luks.uuid outputs "luks-", where lsblk shows that partition 
> name to be a "crypt [SWAP]" on sda3 (sda1 being my /boot/efi/, and sda2 
> containing "crypt /".
> 
> 
> 
> Not sure if/how any of this helps, but there it is.
> 
> 
> 
> Ron
> 
> 
> 
> 
> 
> 
> --
> 
> You received this message because you are subscribed to a topic in the Google 
> Groups "qubes-users" group.
> 
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/qubes-users/hB0XaquzBAg/unsubscribe.
> 
> To unsubscribe from this group and all its topics, send an email to 
> qubes-users...@googlegroups.com.
> 
> To post to this group, send email to qubes...@googlegroups.com.
> 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/3fe76359-4792-4177-b6a6-014426c8024b%40googlegroups.com.
> 
> 
> For more options, visit https://groups.google.com/d/optout.

for me,... it is a single line:
[root@dom0 ~]# getarg rd.ykluks.uuid
luks-96fcb441-0f4c-4856-bcb7-1c76ab31ad73

[root@dom0 ~]# lsblk
...
sdc  8:32   0   3.7T  0 disk  
├─sdc2   8:34   0   500M  0 part  /boot
├─sdc3   8:35   0   3.7T  0 part  
│ └─luks-96fcb441-0f4c-4856-bcb7-1c76ab31ad73
│  253:00   3.7T  0 crypt 
│   ├─qubes_dom0-root  253:10   3.6T  0 lvm   /
│   └─qubes_dom0-swap  253:20   7.7G  0 lvm   [SWAP]
└─sdc1   8:33   0 1M  0 part  
...

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3300e54f-72ba-4956-96a3-f23fbead6f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Support for Windows Tools (QWT) for Qubes 4.0 RC1

2017-10-23 Thread joeviocoe
On Monday, 23 October 2017 11:37:13 UTC-4, Olesia K  wrote:
> hello Qubes users
> 
> I am trying to get windows tools installed on Qubes4.0 RC1. I a getting an 
> error message when I do so.
> 
> Input:
> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
> qubes-windows-tools
> 
> Result:
> Failed to synchronize cache for repo 'qubes-dom0-unstable', disabling. Last 
> metdata expiration check:0:00:05 ago on Mon Oct 23 07:35:40 2017. No package 
> qubes-windows-tools available. 
> Error: Unable to find match.

Are your sys-firewall and sys-net VMs running?
When you run qubes-dom0-update, it sends commands to the firewall via qrexec to 
allow dom0 outbound to the update servers.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/badeccf3-b9ad-4355-a2dc-c433a1d2365d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2017-10-02 Thread joeviocoe
On Saturday, 5 August 2017 11:20:27 UTC-4, the2nd  wrote:
> Hi,
> 
> i switched to Qubes OS 3.2 on my notebook some weeks ago. Besides some issues 
> i had it works very well.
> 
> One problem was to get the installer to install qubes on LVM-on-LUKS. I 
> preferred this over the default LUKS-on-LVM setup because you dont have to 
> encrypt any LV separately.
> 
> After fiddling around some other issues i wanted to use my yubikey to unlock 
> the luks partition on boot like i did it before with my ubuntu installation 
> (https://github.com/cornelinux/yubikey-luks).
> 
> After trying this:
> https://github.com/bpereto/ykfde/blob/master/README-dracut.md
> 
> Which did not work and besides this does manage some IMHO useless (someone 
> may correct me if i am wrong) extra challenges within the initramfs.
> 
> And reading this:
> https://groups.google.com/forum/#!searchin/qubes-users/yubikey$20luks%7Csort:relevance/qubes-users/7pIS_grFZ4s/AlCoPuf-BwAJ
> 
> and this:
> https://github.com/QubesOS/qubes-issues/issues/2712
> 
> I came to the conclusion that there is no working solution yet. So i tried to 
> write my own dracut module. The main problem with this was to find the best 
> hook in the boot process to send the user password to the yubikey and unlock 
> the luks partition. After some testing i got a version which works for my 
> purposes.
> 
> You can find the module and some install instructions at: 
> https://github.com/the2nd/ykluks
> 
> Please note that the current version will probably not work with a default 
> qubes LUKS-on-LVM installation. But if some experienced user is willing to 
> help testing i'll try to come up with a version that supports this too.
> 
> Besides the yubikey/luks stuff the module handles the rd.qubes.hide_all_usb 
> stuff via its own rd.ykluks.hide_all_usb command line parameter because the 
> yubikey is connected via USB and needs to be accessable until we got the 
> challenge from it. i am still unsure if this is the best method to implement 
> this. So if anyone with a deeper knowledge of qubes/dracut does have a 
> better/more secure solution i happy about any help.
> 
> Regards
> the2nd

This is working great for me.
A few questions though:

1)  The default Qubes 3.2 install seems to be LVM-on-LUKS where there is only 
one LUKS encryption and root/swap LVMs within that.  So your instructions work 
with the default install.

2)  It is not clear what can be done if you forget your Yubikey one day and 
want to use the really strong LUKS passphrase from another slot.
Is "Something went wrong" section in which you specify an older initramfs, the 
only way?  Do I need to periodically update this backup "org" initramfs?  And 
it doesn't mention anything about uncommentting the commented crypttab entry 
from the install instructions?

3)  It does seem to hang after timing out.  It will accept the password, but 
will not continue booting.  I can't turn the system on, and come back later to 
use the yubikey.  It seems like it is set to timeout in a minute or so.


Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7f87fd91-f884-4f8e-ba4a-03cf8e447d57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Some HVM systems don't pickup IP from DHCP

2017-09-22 Thread joeviocoe
On Thursday, 5 November 2015 05:07:41 UTC-5, Unman  wrote:
> On Thu, Nov 05, 2015 at 01:26:34AM -0800, Henri KONSTAIN wrote:
> > Wondering that as well.
> > MAC and IP are setup on DHCP server but the Qubes install did not 'take' it.
> > Had to enter manual entries in IPV4 Settings.
> > 
> > On Thursday, 5 November 2015 05:00:22 UTC+1, Pete Howell wrote:
> > >
> > > I've noticed on several installs, that the system would not pickup an IP 
> > > address and had to have one hardcoded.  Does anyone know why this happens?
> > >
> > 
> 
> You should read the fine documentation on creating HVMs :
> https://www.qubes-os.org/doc/hvm-create/
> 
> particularly the section on "Setting up networking for HVM domains".

"Even though we do have a small DHCP server that runs inside HVM untrusted stub 
domain to make the manual network configuration not necessary for many VMs, 
this won’t work for most modern Linux distributions which contain Xen 
networking PV drivers (but not Qubes tools) built in which bypass the 
stub-domain networking (their net frontends connect directly to the net backend 
in the netvm). In this instance our DHCP server is not useful."

Weird, I have an HVM running solely from a LiveCD built on Thinstation.  It 
picks up DHCP just fine.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/72f740b0-9e49-455d-bb18-91216a801956%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how to get higher screen resolutions for Linux-based HVMs

2017-09-22 Thread joeviocoe
On Wednesday, 26 August 2015 19:55:46 UTC-4, Marek Marczykowski-Górecki  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Wed, Aug 26, 2015 at 04:32:12PM -0700, Eric Shelton wrote:
> > A lot of the time in an HVM, out of the box X11 fails to either use the 
> > QEMU VESA display adapter, or fails to recognize the full range of 
> > available resolutions because the emulated adapter does not provided EDID 
> > data.  However, this can generally be fixed by editing or creating 
> > /etc/X11/xorg.conf to include the following portions:
> > 
> > Section "Device"
> > Identifier "device"
> > Driver "vesa"
> > EndSection
> > 
> > Section "Monitor"
> > Identifier "monitor"
> > HorizSync 20.0 - 50.0
> > VertRefresh 40.0 - 80.0
> > Option "DPMS"
> > EndSection
> > 
> > Section "Screen"
> > Identifier "screen"
> > Device "device"
> > Monitor "monitor"
> > DefaultDepth 24
> > Subsection "Display"
> > Modes "1920x1200" "1680x1050" "1400x1050" "1024x768"
> > EndSubsection
> > EndSection
> > 
> > Not every line of the above configuration may be needed, but it allowed me 
> > to take a Linux distro that initially only offered me 800x600 resolution, 
> > and now I am running it at 1920x1200.  Actually, it appears to offer all of 
> > the resolutions up to 1920x1200, and not just the four shown above. 
> >  Probably the "Device" and "Monitor" sections are the main factors in this 
> > working now, and it has little to do with the modes listed in the config 
> > file.
> 
> I think it is already documented here:
> https://www.qubes-os.org/doc/LinuxHVMTips/
> 
> - -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBCAAGBQJV3lHkAAoJENuP0xzK19csJlcH/j4pzaxo5y9CjtUi0iQg0iAD
> Tj1xqtacxZCxpwFHC5B3nLD4IC9iFLhcSLsBjCSB/McDvJjZ2kRrnu6r6oZqECzV
> 8CJE1r4O9cnXJq58eK5tKt/sjxHTAVGYDuKHJnKhcegG+r0Vk9VDwxU0KbhtnetQ
> eW9QOt+fKsJvJ43rZ7c+se0BCAKq8ekObZ2iT+hJXcr5GN3AboU9ECzkAfbwi1zI
> eODdh4F/CjP6UawP9goDZjnYusBCMC0BY8c2URqWGG+I8bvjl82etUuOfryTH5Gd
> m2e/glOuBnejeGGVH8c7SsXdsTg4vGLDTK13g8nx0HazMUubpLUy8CXhIzqaOdY=
> =TGso
> -END PGP SIGNATURE-

When following the instructions in https://www.qubes-os.org/doc/LinuxHVMTips/ 
... I do get the higher resolutions.  So large, in fact it is too big.  There 
are other resolutions now available to me.  
But whatever I select, results in a screen that seems to have a sync problem.  
The video is scrambled, only the default resolution works (which is now too 
large).

Is there a fix for this?
I have tried setting HorizSync to many different values.  This does result in 
different resolution options available in the menu... but the same problem of 
not being able to have a working resolution.

My HVM is Lubuntu 17.04

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4b3c4016-fc03-456b-ab28-4cea4da52daa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Yubikey in challenge/response mode to unlock LUKS on boot

2017-09-19 Thread joeviocoe
On Saturday, 5 August 2017 11:20:27 UTC-4, the2nd  wrote:
> Hi,
> 
> i switched to Qubes OS 3.2 on my notebook some weeks ago. Besides some issues 
> i had it works very well.
> 
> One problem was to get the installer to install qubes on LVM-on-LUKS. I 
> preferred this over the default LUKS-on-LVM setup because you dont have to 
> encrypt any LV separately.
> 
> After fiddling around some other issues i wanted to use my yubikey to unlock 
> the luks partition on boot like i did it before with my ubuntu installation 
> (https://github.com/cornelinux/yubikey-luks).
> 
> After trying this:
> https://github.com/bpereto/ykfde/blob/master/README-dracut.md
> 
> Which did not work and besides this does manage some IMHO useless (someone 
> may correct me if i am wrong) extra challenges within the initramfs.
> 
> And reading this:
> https://groups.google.com/forum/#!searchin/qubes-users/yubikey$20luks%7Csort:relevance/qubes-users/7pIS_grFZ4s/AlCoPuf-BwAJ
> 
> and this:
> https://github.com/QubesOS/qubes-issues/issues/2712
> 
> I came to the conclusion that there is no working solution yet. So i tried to 
> write my own dracut module. The main problem with this was to find the best 
> hook in the boot process to send the user password to the yubikey and unlock 
> the luks partition. After some testing i got a version which works for my 
> purposes.
> 
> You can find the module and some install instructions at: 
> https://github.com/the2nd/ykluks
> 
> Please note that the current version will probably not work with a default 
> qubes LUKS-on-LVM installation. But if some experienced user is willing to 
> help testing i'll try to come up with a version that supports this too.
> 
> Besides the yubikey/luks stuff the module handles the rd.qubes.hide_all_usb 
> stuff via its own rd.ykluks.hide_all_usb command line parameter because the 
> yubikey is connected via USB and needs to be accessable until we got the 
> challenge from it. i am still unsure if this is the best method to implement 
> this. So if anyone with a deeper knowledge of qubes/dracut does have a 
> better/more secure solution i happy about any help.
> 
> Regards
> the2nd

This is working great for me.
A few questions though:

1)  The default Qubes 3.2 install seems to be LVM-on-LUKS where there is only 
one LUKS encryption and root/swap LVMs within that.

2)  It is not clear what can be done if you forget your Yubikey one day and 
want to use the really strong LUKS passphrase from another slot.
Is "Something went wrong" section in which you specify an older initramfs, the 
only way?  Do I need to periodically update this backup "org" initramfs?  And 
it doesn't mention anything about uncommentting the commented crypttab entry 
from the install instructions?

3)  It does seem to hang on a incorrect password.  Is there supposed to be a 
reprompt if incorrect?

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3214c36a-a9ce-4fb1-9b6f-7a6a0c7da3ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Custom initramfs

2017-09-19 Thread joeviocoe
On Monday, 18 September 2017 23:32:53 UTC-4, cooloutac  wrote:
> On Sunday, September 10, 2017 at 6:02:24 PM UTC-4, joev...@gmail.com wrote:
> > On Monday, 29 August 2016 01:34:11 UTC-4, Raphael Susewind  wrote:
> > > > while initially I thought it would be interesting to try, the only 
> > > > situation when yubikey could actually improve security is having to 
> > > > boot a Qubes PC under unavoidable surveilance.
> > > 
> > > came to the same conclusion - probably not worth the security
> > > tradeoff... Perhaps one can implement a 2FA solution for FDE using
> > > something like paperkey? It would still be the 'someone peeks over my
> > > shoulder in a cafe' kind of scenario, but without the USB compromise
> > 
> > It is not just 'unavoidable surveillance'.
> > Qubes doesn't just run on Laptops.  Think about Desktops.  They require USB 
> > Keyboards since most modern desktop systems don't have PS/2. And since they 
> > require USB Keyboards to enter the LUKS Passphrase, that means the 
> > "rd.qubes.hide_all_usb" option in the bootloader will render the whole 
> > system inaccessible.  So USB security at boot time is not an option, 
> > therefore, not a tradeoff with 2FA.  
> > 
> > It isn't for the "lazy" people either.  2FA means that I don't have to 
> > weaken my passphrase so its memorable.  And if snooped by some Evil Maid 
> > attack methods, they'll need to pull the token from my cold dead hands too.
> > 
> > I am hoping someone will finish this idea and make it available, especially 
> > for desktop users with yubikey.
> > Unfortunately, I don't have much knowledge on initramfs or dracut to 
> > produce something usable myself.  I have searched all over, and only find 
> > the same abandoned ideas, or directions to using Yubikey for something 
> > other than LUKS, or on a Debian based system.
> > 
> > Please help.
> > Thank you.
> 
> almost all motherboards still come with ps/2.  only budget gaming ones don't. 
>  but even most gaming ones do.

Fair point.  I was thinking more in my price range.  Dell XPS 8900.

My solution so far is to use YKLUKS from here:  https://github.com/the2nd/ykluks

It does include a grub2 "rd.ykluks.hide_all_usb" feature to only temporarily 
turn on USBs during the 
https://groups.google.com/forum/#!msg/qubes-users/hB0XaquzBAg/aPQmmLBwBgAJ
"Besides the yubikey/luks stuff the module handles the rd.qubes.hide_all_usb 
stuff via its own rd.ykluks.hide_all_usb command line parameter because the 
yubikey is connected via USB and needs to be accessable until we got the 
challenge from it. i am still unsure if this is the best method to implement 
this. So if anyone with a deeper knowledge of qubes/dracut does have a 
better/more secure solution i happy about any help."

It works.  I think its the best I can do since I am more concerned with 2FA 
than bad USB devices.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/58fe4e5d-508d-4613-a926-79a0e5571c30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Custom initramfs

2017-09-10 Thread joeviocoe
On Monday, 29 August 2016 01:34:11 UTC-4, Raphael Susewind  wrote:
> > while initially I thought it would be interesting to try, the only 
> > situation when yubikey could actually improve security is having to boot a 
> > Qubes PC under unavoidable surveilance.
> 
> came to the same conclusion - probably not worth the security
> tradeoff... Perhaps one can implement a 2FA solution for FDE using
> something like paperkey? It would still be the 'someone peeks over my
> shoulder in a cafe' kind of scenario, but without the USB compromise

It is not just 'unavoidable surveillance'.
Qubes doesn't just run on Laptops.  Think about Desktops.  They require USB 
Keyboards since most modern desktop systems don't have PS/2. And since they 
require USB Keyboards to enter the LUKS Passphrase, that means the 
"rd.qubes.hide_all_usb" option in the bootloader will render the whole system 
inaccessible.  So USB security at boot time is not an option, therefore, not a 
tradeoff with 2FA.  

It isn't for the "lazy" people either.  2FA means that I don't have to weaken 
my passphrase so its memorable.  And if snooped by some Evil Maid attack 
methods, they'll need to pull the token from my cold dead hands too.

I am hoping someone will finish this idea and make it available, especially for 
desktop users with yubikey.
Unfortunately, I don't have much knowledge on initramfs or dracut to produce 
something usable myself.  I have searched all over, and only find the same 
abandoned ideas, or directions to using Yubikey for something other than LUKS, 
or on a Debian based system.

Please help.
Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/322e0c18-8d97-49b8-a96e-911bc029e510%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.