Fedora Stakeholders Discuss Possibility Of Using Pre-Built Initramfs Images

[phoronix]

Phoronix: Fedora Stakeholders Discuss Possibility Of Using Pre-Built Initramfs Images

Another alternative to slow initramfs generation could be distributing pre-built initramfs images to users. An additional benefit of that is possibly better security with measured boot capabilities, a matter currently being discussed by Fedora stakeholders...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Pre-Built-Initramfs-2020

[Britoid]

Silverblue has been using prebuilt initramfs images for a while, I guess it makes a lot of sense.

[rene]

Pre-built, yet minimal initrd like major distributions such as #t2sde are using? ;-) https://t2sde.org

[oleid]

Pre-built is fine, as long as you can add additional files, like a local key to decrypt a hard drive (without typing a password).

[lowlands]

Pre-built is fine, as long as you can add additional files, like a local key to decrypt a hard drive (without typing a password).

What is the use case for such a setup? Probably stating the obvious but wouldn't "auto-decrypt" defeat the purpose of an encrypted hard drive? I use dracut-sshd to remotely ssh into a booting server to enter the key.

[starshipeleven]

What is the use case for such a setup? Probably stating the obvious but wouldn't "auto-decrypt" defeat the purpose of an encrypted hard drive? I use dracut-sshd to remotely ssh into a booting server to enter the key.

I've heard the same but with TPM, which at least makes it half-way useful (as anyone stealing the drive won't have the device with the key in the TPM to decrypt it).

Congrats on dracut-sshd, btw.

[Britoid]

What is the use case for such a setup? Probably stating the obvious but wouldn't "auto-decrypt" defeat the purpose of an encrypted hard drive? I use dracut-sshd to remotely ssh into a booting server to enter the key.

You would be reliant on the userspace to protect unauthorized access to files, so gdm, etc. You have a chain of trust, so you can verify software hasn't been tampered with, but it would fall apart if there's a bug.

[brent]

Even if there is a bug with user authorization, auto-decrypt still protects against someone stealing your disk and the likes, with no impact on user experience. And that is arguably an important attack scenario with mobile devices.

You can also use the TPM to strengthen a weak FDE password, which is very useful. This is what iOS and Android do: you typically have a quite short PIN, but it's strengthened with an embedded secure processor, for instance by hashing with a secret key that can not be read at all. So brute-forcing is not feasible in practice.

The downside of this is, of course, that data recovery is impossible if the device breaks. With LUKS, you can have multiple key slots, so you can register an additional (long) passphrase for decryption and store it somewhere safe, but that requries additional setup and additional user actions.

[lowlands]

I've heard the same but with TPM, which at least makes it half-way useful (as anyone stealing the drive won't have the device with the key in the TPM to decrypt it).

Thanks, using TPM for storing the key makes sense. Red Hat has an interesting approach where it gets the key from a remote server:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening

[Britoid]

Even if there is a bug with user authorization, auto-decrypt still protects against someone stealing your disk and the likes, with no impact on user experience. And that is arguably an important attack scenario with mobile devices.

You can also use the TPM to strengthen a weak FDE password, which is very useful. This is what iOS and Android do: you typically have a quite short PIN, but it's strengthened with an embedded secure processor, for instance by hashing with a secret key that can not be read at all. So brute-forcing is not feasible in practice.

The downside of this is, of course, that data recovery is impossible if the device breaks. With LUKS, you can have multiple key slots, so you can register an additional (long) passphrase for decryption and store it somewhere safe, but that requries additional setup and additional user actions.

Windows gets around this by letting you store a recovery key, either on Microsofts servers or as a file. This would probably be the best solution.