Hello everyone! Is there a way to get a system installed with encrypted root that prompts for the passphrase only once? Also, does anyone know why this is? I suspect that a normal encrypted guix install prompts for it twice, first to unlock grub and then to unlock the root drive.
Yes, I’ve done it.
Here are my notes slalomsk8er / RDE LUKS2 unlock once · GitLab - sorry for the mess 
I think, there is a fault in my notes as it wont work if GRUB isn’t installed and configured without the modifications once.
1 Like
I think the way to do it is to write a new bootloader that installs kernel images and initrd into /boot and create a grub.cfg that points to them.
If you are worried about secure boot, you can install unified kernel images and point grub.cfg to UKIs. It should be called grub-uefi-uki-bootloader and grub-uefi-uki-signed-bootloader. The signed variant supports secure boot.
1 Like
Thanks for the answers! I now unlock my root with a keyfile as per this and @dgr 's instructions on how to create the keyfile. The option to do so seems to be a recent addition.
Now my only gripe with guix is that grub does not respect the keyboard-layout variable while unlocking /boot and that i can’t find a way to use an un-encrypted /boot (which I guess is better for security). But in the light of all the other positives, I’m sure to stick with this.
I think GRUB respects my keyboard-layout. I try to check at home and keep you posted.
So, /boot is just a directory in the LUKS2 encrypted root file system?
If that’s the case, then initramfs can have the LUKS2 keyfile to allow you to enter the passphrase only once during boot.
Yes, this is how it works. But it doesn’t matter if it’s the root or the boot file system that is LUKS2 encrypted as long as the additional initramfs with the key is on an FS that got unlocked by the first passphrase entered into the first grub stage that’s installed on the EFI partition. A check of the TPM to see if the EFI and the grub first stage are clean would help to reduce risk from the evil maid scenario but with I’m of the opinion, that with HW access all is over anyway, and I’m fine with only protecting my data from a device theft.
purism sells computers with pureboot. Pureboot combines coreboot with heads firmware.
Heads firmware can verify whether it is modified with librem key which is a variant of nitro key. Librem key is an external USB device that checks the integrity of heads firmware and signed files in /boot.
Heads firmware in restricted mode asks a user to sign files in /boot with librem key if they are not signed, or the signatures are outdated.
So, if you carry librem key with you, you can detect evil maid attacks. But, this will not protect you from airport security because airport security will just take librem key and subvert librem key if they have a competent hacker.
However, if airport security takes librem key from you, you will know that they will probably overwrite librem key and heads firmware. Thus, evil-maid attack cannot be hidden in this case.
The fact that you carry librem key with you makes it impossible to launch an evil-maid attack without alerting you. You will be notified of evil-maid attacks.
The problem is that gnu guix system doesn’t have heads bootloader and heads-signed bootloader, yet. It can take many years to pass the review process and get these bootloaders merged. I wish somebody wrote heads bootloader and heads-signed bootloader and host them on a third party guix channel registered to toys search engine until they are merged into gnu guix core.
You will be notified of evil-maid attacks.
Sadly not true as evil maid can just amend a device with a screen and keylogger - no amount of software/firmware can protect against that.
So I’m fine with just having my data protected if I loose access to the machine as all other measures are in no relation to effort vs. security.
If guix would support tooling for single passphrase for LUKS2 and secure boot with own keys OOB, I’m not sure if heads would add much more security for the extra effort and very limited HW.
You are right, but pureboot restricted mode can detect tampering in firmware and /boot.
Detecting hardware modification is impossible.
It’s still good to be able to detect firmware tamperings.
What is secure boot for? As far as I know, root access can modify firmware and TPM. Thus, secure boot alone is not sufficient for remote attacks that succeed in root access.
For secure boot to be protected from remote attacks, you would have to place a write lock on firmware.
With secure boot you can only run signed bootloaders.
So if you install your keys into the firmware and sign your grub first stage then the unprotected EFI partition is secured against tempering. So it would fix the biggest hole in my current “only one passphrase solution”. It also enables measured boot and trusted boot - see What measured boot and trusted boot means for Linux | Opensource.com .
But, you also have to place a write lock on UEFI. If a malware with root access just flashes firmware or modifies UEFI, then secure boot can be circumvented.
Not without your kernel detecting it and refusing to unlock the disk with the LUKS2 key file. But yes, setting the admin password on your firmware is a must.
Linux kernel doesn’t care about secure boot. I think you were talking about TPM measured boot.
If you can just flash firmware as root, you can reset UEFI.
Not all UEFI firmwares are lockable.
The initrd can be made to care.
On my Debian at work, I use measured boot to unlock the LUKS2 key.
So in an other machine the disk will not unlock without me entering the passphrase. This is just a precaution if the disk would not be properly handled when the workstation gets decommissioned and replicates the MSFT disk encryption.