Hello, thank you for your answer.
[email protected] writes: > Hi, > > I see. > > I think back then the idea was to remove the custom key-file feature > entirely--which I didn't want to do (since it has existed in guix releases). I am glad you did not do this, since I use it a lot. > Yes, /etc/luks_script is only available in the initrd (... overlay). IF we > wanted to then we could copy it out--but I'd rather not by default (it would > retain a passphrase for longer than necessary in the vast majority of cases). > > I have learned (from bitter experience) to not be overly smarty pants in > security. The dumbest most straightforward possible implementation is the one > guix uses. Agree. Additionally, I cannot really think of any benefit of copying it out. After the root pivot, any yet-to-be-unlocked devices will likely not be those GRUB has password(s) to. > In this case, Guix's reads /etc/luks_script, finds the entry for the > partition > in question, and then tries to open the luks volume using that. If > /etc/luks_script file is missing entirely, it complains since I don't want to > hobble debugging a potential borked bootloader. For GRUB this makes sense, if the file is missing, something is likely wrong. > This open-luks-device is used by gnu/system/mapped-devices.scm for opening ANY > mapped device, not just at boot. It's also used by gnu/system/linux-initrd.scm > raw-initrd to open it at boot. > > That's it. > > I can see that if you do already specify a key-file for a specific volume, you > probably want to use that one. > > In the end if you have multiple possible mechanisms for the passphrase (but > for > example not specify exact which volume that is for), then that is a policy > question. That means all users will end up wanting all possible combinations > of > the policy to be implemented. I do see your point, but in this specific case, I am not able to come up with a situation when having the key-file first would be a problem for anyone. Even if—e.g., due to stale configuration—the key would no longer match the drive, it will still fallback to the /etc/luks_script (and password). > Your patch makes guix prefer custom key-file to the grub-provided passphrase, > rather than the other way around as it was before. > > I have no opinion on whether that is better (except that it happens not to > warn > as a side effect of the key-file being used)--but, sure, we can do that patch > :-) The side-effect is all I care about ^_^. I am unlocking lots of drives, so there is plenty of these warnings. And, more annoyingly, since /etc/luks_script will *never* exist after root pivot, there is zero action I can take to address them. (Hm, based on your remark above, I could just touch /etc/luks_script and that should suppress the warning? Not very elegant though.) > Authentication is a huge can of worms. In an ideal world the user could > specify > in config.scm that "use the grub-provided passphrase to unlock /, then to log > into the default user with it and then unlock the gnome secrets manager with > it" > or whatever other policy sentence :) > Or smartcards, Bluetooth (non-)proximity alert, HSM and so on. I still did not find the courage to actually enable Bluetooth stack on my laptops.. :) > We could also remove "If /etc/luks_script file is missing entirely, it > complains"--but do we want to? (it exists for the worst case where grub lost > the newc ability or ghosts invaded the computer or any other unknown unknown) Well, if someone would be using the unlock code for their own purposes (e.g., manually triggered Shepherd action to unlock a USB drive or something), without a key file, they would get the warning every time. But since no one complained, probably no one does that? Though, if the file is gone, you can tell that it is gone by having to input password twice. So there will be signs. Maybe we could live without the warning? (Wait, we have bootloaders that are not GRUB right? Do they print the warning every time, or they simply do not support encrypted root? How does it work there?) > Or we could check whether we are in the initrd or already booted (can > we, safely? I did not found anything that would already exist, but we could always create a sentinel file somewhere. Or maybe just make #:pre-mount argument to boot-system take initrd? argument. > Also, do we want to make it hardcoded policy that the passphrase > doesnt survive beyond the initrd? Or allow the user to customize the > initrd to DO copy it, or do we want an official guix feature implying > that copying to happen etc), and so on. Is there a case where copying the /etc/luks_script is actually useful? I have learned in would not help in my case, sure, but is there some situation when you need to unlock a dick GRUB was given password to, but is not unlocked and mounted before root pivot? I cannot think of any, but that might me just my lack of imagination. > We should first think of what we want. > Security is one of the things were it is extremely useful to plan first. Makes sense, though in the current heat wave I am not the best at thinking. :) Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
