Announcement

Collapse
No announcement yet.

Fedora Stakeholders Discuss Possibility Of Using Pre-Built Initramfs Images

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fedora Stakeholders Discuss Possibility Of Using Pre-Built Initramfs Images

    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?pag...Initramfs-2020

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

    Comment


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

      Comment


      • #4
        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).

        Comment


        • #5
          Originally posted by oleid View Post
          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.

          Comment


          • #6
            Originally posted by lowlands View Post
            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.

            Comment


            • #7
              Originally posted by lowlands View Post

              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.

              Comment


              • #8
                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.
                Last edited by brent; 01-28-2020, 09:02 AM.

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  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/documentat...rity-hardening

                  Comment


                  • #10
                    Originally posted by brent View Post
                    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.

                    Comment

                    Working...
                    X