Security implications of keyfiles on a LUKS-encrypted /boot
 

Hello.

NOTICE: This setup is assumed to be performed on a Ubuntu or Debian based system with the old msdos disk partition table.

I've recently found out it's possible to setup a linux system with the /boot folder being part of the LUKS-encrypted rootfs. This setup has an unpleasant side-effect of requiring the user to enter the decryption passphrase twice - once for the initial decryption by GRUB2 to load the kernel/initramfs into memory and another for the kernel to decrypt and mount the rootfs itself. There is however a convenient workaround where a keyfile is used on a secondary LUKS slot to decrypt the rootfs during kernel boot. This will make the rootfs decrypt automatically, so the user has to enter the decryption passphrase only once. I am curious about the security implications of this approach.

The setup guides are provided here:
http://www.pavelkogan.com/2014/05/23...sk-encryption/
http://www.pavelkogan.com/2015/01/25...nt-encryption/

My worries are mainly the keyfile. The first document describes that the keyfile should be safe while the device is powered off, which is obvious since the only copy at this point is located inside the encrypted container. When powered on, there are a number of potential problems since the keyfile now resides in many places including:

1. Inside the /boot folder
2. Inside the initramfs images
3. Inside the system memory

1) If not properly protected, the keyfile can be accessed by anyone on the system. The file should at least be owned by root and be made read-only by root (400): -r---------. We also have to keep in mind that the update script will have to be able to read this file on kernel updates to include it in the new initramfs images.

2) I am unsure whether including the keyfile within an initramfs image is a good idea, but the author of those guides did not find a better way of loading a keyfile into memory by GRUB2. The keyfile will be copied into the initramfs images on update-initramfs, so those files must also be protected. Setting a read-only flag on them alone isn't the brightest idea because new images will occasionally popup when system updates take place. We should make sure that all new files are also protected accordingly. The best solution I've found is to use the setfacl command on the /boot folder to give all newly created files a "400" mask.

3) The entire initramfs image will be copied into memory by GRUB2 at boot. I am not exactly sure, if this memory region is still accessible after boot, but it should probably be securely erased after booting is done. Perhaps something can be done with the initramfs scripts to securely overwrite the keyfile with random data after rootfs decryption has finished.


Thoughts, ideas?