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 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+unsubscribe@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.
getarg rd.ykluks.uuid outputs nothing for me. But then, I'm not using a Yubikey.
getarg rd.luks.uuid outputs "luks-<uuid>", 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+unsubscribe@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.
--
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+unsubscribe@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/08e39e6c-97f6-456b-b0c6-c09a86a8a856%40googlegroups.com.
Thanks. Something messed up though.I added a single comma, and the uuid for the new Crypt_luks... To that line in etc/default/grub.I ran mkgrub and dracut -f as per the normal installation.Got an error saying it could not find the device, then I realized the only recently made the updates to the GitHub.Downloaded and installed the new git. the changes seem pretty straightforward, and shouldn't cause a problem.But now, I have an error from dracut-initqueue saying cryptsetup command not found on line 66 of ykluks.shAlso, the yubikey prompt to insert, does not show up. Just a blank screen until I insert the key, then it does prompt for the passphrase.I reinstalled the old version I had, removed the second uuid from default grub, and reran the mkgrub & dracut -f... It is prompting me to insert the yubikey again, but I still have the error of command not found for cryptsetup.I have two entries in etc/crypttab, for each uuid, but those are both commented out.I don't know why dracut cannot find the command.Now I have to use the full passphrase by removing the yk as shown in the recovery steps.On Wed, Aug 15, 2018, 12:43 PM __ __ <hei...@gmail.com> wrote:You can add it to the GRUB_CMDLINE_LINUX in /etc/default/grub
On Wed, Aug 15, 2018 at 6:38 PM, <joev...@gmail.com> wrote:
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 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+unsubscribe@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/f09343a5-6ff7-4283-b8e2-d1df0e3a1b95%40googlegroups.com.
Good to know that it works now. 😊Maybe i should add an option to make my module work without the yubikey in case the yubikey is lost or otherwise not available. This should not be hard to implement......Joeviocoe Gmail <joev...@gmail.com> schrieb am Mi., 15. Aug. 2018, 22:23:Yep, that's simply fixed it. It is strange that it needs to be explicit now when it had not before.also, I see that you are using the same display message function for everything. 1 second sleep time before it hides was too short, so I changed to 60 seconds.Thank you for updating you are awesome module. Both Luks volumes open at boot time now, so I can try extending my LVM to the new drive without leaving the data unencrypted.In case of recovery, I'm not sure how easy it will be to stop using your module with two encrypted volumes that need to be unlocked before the lvm. I don't think the native rd.luks.uuid Will allow comma separated values.I will let you know how well it boots after I extend the lvm to the new drive so you can update your documentation regarding LUKS on LVM.Thanks again.
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.
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.
Yes, it is working for me on Qubes 4.0 and I have used it with LVM and Raid configurations.