I’ve installed EndavourOS using the September 2020 release. During installation, I’ve created a partition layout with an unencrypted boot partition and an encrypted root partition, as I used to do in other distributions before.
However, through a German blog article on KDE Neon I came across a possible security problem with Calamares, which is said to make encryption completely useless with this partition layout. The problem is said to be the following according to Calamares bug tracker: “the current Calamares code always puts a LUKS keyfile into the initramfs as soon as you enable LUKS encryption, which is why leaving /boot unencrypted in manual partitioning currently defeats the whole purpose of using LUKS”.
Although the bug seems to be be fixed now, the september release was published before this merge request. So was EndavourOS affected by this bug (I’m not sure, therefore I didn’t posted in the bug section)? How do I find out?
And if it’s the case, is there a way to fix this without reinstalling the system?
I know, but I already installed the system back in October or so and only now read the report on the mentioned bug. I just wanted to know if my encryption is now completely insecure and if I have to reinstall…
Thank you!
But before we get to that, so that we don’t mess up your system, could you please post the output of the following commands.
lsblk ls /boot ls / sudo cat /etc/crypttab | grep -v "#"
sudo cryptsetup luksDump /dev/sdaN | grep Slot
Replace sdaN with your encrypted devices partition (probably sda3 or sda2). Run … blkid | grep crypto_LUKS | cut -d \: -f 1 … to find out which devices are encrypted.
This is why I prefer the /boot directory within an encrypted root partition, so kernel and initramfs images cannot be tampered with and potentially “trojan horsed”.
mkinitcpio creates the initramfs, not Calamares, so I assume Calamares provides the necessary settings in /etc/mkinitcpio.conf.
This config setting will add the Calamares created crypto keyfile to a generated initramfs.
FILES="/crypto_keyfile.bin"
This is required for an encrypted /boot partition.
Want the keyfile removed from your unencrypted /boot initramfs images, then just remove it from the mkinitcpio config and regenerate.
FILES=""
You may have to enter your luks password twice though.
@jonthan
As @otherbarry described, it’s quite easy removing the keyfile entry. You’ll maybe also want to clean up some other things and remove the unneeded keyfile(s) etc.
But before you address this, could you please provide the data I asked for above. This is for future reference; just to see how calamares set up your system and what really needs to be changed for you to have a secure system.
Oh, and maybe also provide the output of cat /etc/mkinitcpio.conf | grep FILES
This would surely also be useful for others, so thanks in advance.
Sorry, my fault, should have been sudo blkid | grep crypto_LUKS | cut -d \: -f 1
As @otherbarry already confirmed you aren’t affected by the vulnerability described in your initial post.
But, there are some unnecessary leftovers from the calamares install you might also want to get rid of.
You don’t need the luks-c[...] /crypto_keyfile.bin [...] line in /etc/crypttab. Just comment or remove it from the file.
Your encrypted partitions (/dev/nvme0n1p6) luks-header contains two passphrases. If you didn’t manually add a second passphrase after installation the keyslot 1 typically holds crypto_keyfile.bin as a passphrase. This was added by calamares but seeing that you don’t need to chain-unlock anything automatically without inputting a passphrase it doesn’t serve any purpose and can be deleted from the luks-header with the following command: sudo cryptsetup luksKillSlot /dev/nvme0n1p6 1
You now have no need for /crypto_keyfile.bin and can delete this file.
For good measure, just rebuild with sudo mkinitcpio -p linux
You’ll then have a system without any unnecessary passfiles and entries lying about; the way it would have been set up during a manual install.
Sorry @otherbarry, I never stated using keyfiles being “wrong”.
It’s just, in @jonthan’s case, IMO this keyfile and the keyslot it’s taking up serve absolutely no purpose and would never have been used if the encryption would have been set up by hand.
But I’m always willing to learn and change my long established ways if need be. Maybe you could enlighten me, as to why the OP should need that specific keyfile and the keyslot it takes up? And if he doesn’t, why he should keep it?
This is default behavior when using an encrypted /boot, which the OP clearly isn’t. If you’d for example manually install the Arch way with an unencrypted /boot and a single encrypted root partition, you’d never create a useless keyfile (here crypto_keyfile.bin) and add it to one of the keyslots. Real world analogy: Unless you copy that key and store it elsewhere, you’d just have a key lying around in a room you always, and only can, unlock by other means (your initial key =password).
Calamares default password + keyfile setup works with an encrypted and an unencrypted /boot setup, right. But in case of the latter, it doesn’t “hurt” but also doesn’t serve any purpose whatsoever. It’s probably just a shortcut or “lazy” programming (I totally understand that this isn’t a high priority for the developers!) on calamares side.
That’s why, IMHO, I still stand by those recommendations.
Just two questions on this, although it may be little bit off-topic. I followed your HOWTO, but I chose a separate unencrypted boot partition. So, as far as I understood, I can delete the entry in /etc/crypttab and delete the /crypto_keyfile.bin and emtpy the key slot. If I do not empty the key slot, would this be a problem here since I don’t want to kill the wrong key slot? Second, is this
No, you’ll just have “a door with a second keyhole, for that you don’t have a key” . If you don’t empty the keyslot it will just take up space and reduce the available keyslots by one. But it’s no problem if you don’t remove the key.
BTW, if you haven’t added any keys manually, calamares always sets up two keys; your initial unlock password in keyslot 0 and the keyfile (/crypto_keyfile.bin) in slot 1. In this case it is perfectly safe to remove keyslot 1.
No, I don’t think so, because calamares usually sets that up right during install there’s no need to add or remove this manually. But I’ll maybe take some time to check if this still is the case.
Technically the only use case that should not require a keyfile is an unecrypted /boot with a single encrypted root partition. Which Calamares requires to be manually partitioned.
All other scenarios should use a keyfile.
Encypted /boot requires a keyfile.
Unencrypted /boot with multiple encrypted partitions (ie root + swap, or root + home, or root + home + swap, etc) should use a keyfile. Otherwise the password is required to be typed once per partition each boot.
It does no harm leaving the keyfile config and keyfile there as it may be needed later if an additional luks partition is added manually (ie swap or home or data or pacman cache or …).
Wouldn’t call it lazy not catering for the one manual partitioning variant that technically does not require a keyfile.
Removing the keyfile config in this instance is simply not needed, and creates unnecessary risk.
. If you don’t empty the keyslot it will just take up space and reduce the available keyslots by one. But it’s no problem if you don’t remove the key.