Announcement

Collapse
No announcement yet.

Fedora Stakeholders Discuss Possibility Of Using Pre-Built Initramfs Images

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    Djhg2000
    Senior Member

  • Djhg2000
    replied
    What happened to the idea of removing initramfs entirely with compiled-in storage drivers and keeping kernel boot options in the bootloader? I tried this in Debian for a while and the performance advantage was very noticable from rotating media.

    Leave a comment:

  • skeevy420
    Senior Member

  • skeevy420
    replied
    Originally posted by Britoid View Post

    It being in an archive allows it to be easily compressed and signed "as one". It's also easier to do atomic upgrades if you're only moving/renaming two files.
    I know and I don't necessarily disagree, but, still, there has to be some sort of alternative other than "wrapping it all up in an archive". Partition check-summing or something like that.

    Leave a comment:

  • Britoid
    Senior Member

  • Britoid
    replied
    Originally posted by skeevy420 View Post

    No, unless you don't know any better so you don't use a LUKS encrypted GRUB that requires a password followed by unlocking everything else VIA key files stored on either /boot/keys or on a USB drive so you can remove it once the keys are used and shit is decrypted.

    I'd rather them move the initramfs out of the archive and over to /boot/init or something like that. If it's going to be a prebuilt and known initramfs, like how /sbin used to contain known boot binaries, then take the stuff out of the damn archive so it's easier to work with.
    It being in an archive allows it to be easily compressed and signed "as one". It's also easier to do atomic upgrades if you're only moving/renaming two files.

    Leave a comment:

  • CommunityMember
    Senior Member

  • CommunityMember
    replied
    Originally posted by oleid View Post
    Pre-built is fine, as long as you can add additional files
    There already exist mechanisms for an image to load/layer an additional image, so something like a base image, which satisfies many use cases for boot, and allows one to create an additional (much smaller, faster to build) image for any more esoteric devices/drivers and system specific configuration, would appear to be a viable path.

    Leave a comment:

  • skeevy420
    Senior Member

  • skeevy420
    replied
    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.
    No, unless you don't know any better so you don't use a LUKS encrypted GRUB that requires a password followed by unlocking everything else VIA key files stored on either /boot/keys or on a USB drive so you can remove it once the keys are used and shit is decrypted.

    I'd rather them move the initramfs out of the archive and over to /boot/init or something like that. If it's going to be a prebuilt and known initramfs, like how /sbin used to contain known boot binaries, then take the stuff out of the damn archive so it's easier to work with.

    Leave a comment:

  • lowlands
    Senior Member

  • lowlands
    replied
    Originally posted by Britoid View Post

    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.
    Heh those pesky bugs I've read about using a read-only root filesystem to further limit the attack vector. Good to see so many developments, ideas and solutions to keep us safe.

    Leave a comment:

  • Britoid
    Senior Member

  • Britoid
    replied
    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.

    Leave a comment:

  • lowlands
    Senior Member

  • lowlands
    replied
    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

    Leave a comment:

  • brent
    Senior Member

  • brent
    replied
    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.
    brent
    Senior Member
    Last edited by brent; 28 January 2020, 09:02 AM.

    Leave a comment:

  • Britoid
    Senior Member

  • Britoid
    replied
    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.

    Leave a comment:

Working...
X