Advise on dealing with Calamares bug on Full Disk Encryption (LUKS)

Hello, I have a FDE build from when Calamares was affected by CVE-2009-13179 and I would like to fix the problem without having to start out fresh but I have some questions.

In summary, from what I understood from the Calamares blog, there needs to be a crypto_keyfile.bin stored inside the initramfs however initramfs mistakenly had read permissions by others, which means the crypto_keyfile.bin is also readable.

Quotes from Calamares blog

Most Linux systems boot using an initial ramfs , containing tools, drivers, and data used during system boot. For an encrypted hard disk, that data includes the key file that is used to encrypt the hard disk. The initial ramfs is generally stored on an encrypted boot partition, but it is a regular file once the system has booted. If an attacker can read the initial ramfs file, the attacker can extract the key file from the initial ramfs – it is not otherwise encrypted on-disk.
(...)
After installation, any user on the installed system may be able to read the initial ramfs (if it installed with vulnerable permissions), and extract the key information. Unless something changes the permissions on the initial ramfs file, this vulnerability persists across reboots and any user with access to the /boot directory (where initial ramfs files live) can obtain the key.
(...)
Users of mkinitcpio may be vulnerable, since it uses the umask when generating new files. Most Live CDs that use mkinitcpio seem to have an unsafe umask of 022 set, so that the resulting file is readable by others. Calamares now sets a safe umask before generating the file, and actively changes the permissions on initial ramfs files to a safe value during installation.

And they give some mitigation options for systems affected:

Mitigations
For installated systems with a potentially vulnerable initial ramfs:

  • set a safe umask for the root user,
  • change the permissions of initial ramfs files in /boot to a safe value,
  • (for users of update-initramfs ) add a configuration snippet to set the umask to a safe value when creating initial ramfs files.

Following the mitigation advise, I changed permissions (chmod) of all initramfs files to a 0600 but I'm not sure if I should change umask to 077 as described on the blog post and how to properly do this, I'm afraid it could generate problems somewhere else.

Can I change umask to 077 in /etc/profile without consequences or is there a better option?

Anyone?

Well, if I understood correctly from archlinux forum, mkinitcpio will maintain the permission set on existing initramfs files, but, when installing new kernels from Manjaro Settings Manager, it also sets permission 0644 for for initramfs files that contain the keyfile.

So, do I have to set umask to 077, or is there a way to force pacman or Manjaro Settings Manager to set safe permissions after install for initramfs files?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by