Been down the rabbit hole lately of UEFI Secure Boot issues, and decided to write an overview of how it works out-of-the-box in the excellent Debian-based Linux Mint LMDE 6.

Have mostly been researching this stuff as I was looking to replace GRUB entirely with systemd-boot on one of my systems. Will likely write a follow-up piece documenting that journey if I think it’d be interesting to some nerds out there.

  • tony@lemmy.hoyle.me.uk
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    2
    ·
    1 year ago

    If you want to experiment with UEFI you don’t need systemd-boot either, just create an efi bootable kernel and direct boot it. reFind is still around I think too for graphical boot (although that’s mainly used by macs… apple users like guis :p).

  • Laser@feddit.de
    link
    fedilink
    arrow-up
    18
    arrow-down
    3
    ·
    1 year ago

    First, I’d personally always opt for systemd-boot instead of GRUB when I have the choice. GRUB is just very complex and systemd-boot rather simple.

    Getting Secure Boot to work isn’t always trivial, especially since mainboards and TPMs don’t always document how enrolling your own keys works.

    • The Doctor@beehaw.org
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      Hard same. systemd-boot is about as tricky as, say, syslinux (which I used to use) to get working, which is itself far simpler to work with than GRUB ever was.

    • saltedpenguin@artemis.camp
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      1 year ago

      personally for me, grub beaks when sdax changes but, in systemd boot doesn’t. this is my main reason to prefer it. easy access to boot configuration is a plus i guess.

    • MonkderZweite@feddit.ch
      link
      fedilink
      arrow-up
      1
      arrow-down
      2
      ·
      edit-2
      1 year ago

      GRUB is just very complex and systemd-boot rather simple.

      Well, except the Systemd part. Efistub or Refind it is for me.

      • Laser@feddit.de
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        systemd-boot is basically gummiboot with an interface to systemd so that the latter can get information on boot time in firmware and stuff. I prefer a boot loader instead of Efistub because it allows easier configuration of boot options etc. but it just comes down to personal preference

  • Presi300@lemmy.world
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    7
    ·
    1 year ago

    How to use secure boot in linux:

    Step 1. Go to the UEFI settings and disable it

    Done

  • JakenVeina@lemm.ee
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    Fun read.

    So, is the implication here that ONLY Microsoft keys can be in the db, and thus they’re the ultimate authority on who gets signed? Does Microsoft somehow own the UEFI standard?

    Relatedly, can anyone elaborate on their reason for refusing to sign GRUB? I’m not following just from that short quote.

    • TiffyBelle@feddit.ukOP
      link
      fedilink
      English
      arrow-up
      16
      ·
      1 year ago

      Microsoft doesn’t own the standard. It’s actually an open standard maintained and contributed to by a whole host of technology companies. This is contrary to the old BIOS method which was originally proprietary to IBM.

      The fact they have such wide authority in signing is a product of how wide-reaching their market share it. They essentially mandate that OEMs include their signing keys in the signature database if their systems are to ship with Windows, thus making them a de facto authority on what gets signed. This was a point that made a lot of people in the FOSS community uncomfortable and still does to this day, although if one wants they can actually take full control of the Secure Boot process by replacing the Platform Key (PK) with their own. This gives ultimate control to the owner of the machine as they can then replace the Key Exchange Keys to allow them to replace Microsoft’s keys within the signature database (db). This completely removes reliance on any third party signatures and enables ditching the first-stage Shim bootloader from the boot flow entirely, since the owner could just sign whichever bootloader they wanted to use directly with their own key in the database. As it would require manually signing everything from the bootloader to the kernel and its modules though, including re-signing them after updates, this is definitely a much more involved way of doing things although arguably even more secure as the system would be entirely locked down to only binaries signed by its owner at that point.

      As to why they don’t sign GRUB, it’s about licensing. Since GRUB is GPLv3, there are provisions in the license that Microsoft interprets as potentially mandating them to disclose their private key to facilitate users installing modified versions of it. Ubuntu came to the same conclusion when contemplating how to deal with Secure Boot back in the day, where they wanted to provide an alternative to the Microsoft keys by having Canonical’s keys also shipped with firmware, although proliferation of their keys is a lot less widespread and in some peoples’ eyes not all that much different than just using VeriSign’s service for the Microsoft keys anyway.

    • Semperverus@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      ·
      1 year ago

      You can put your own keys in on many motherboards using some of the command line EFI tools, but you would have to basically recompile everything from scratch using your keys to get them to run. I.e. might as well switch to gentoo at that point.

      On the other hand, Microsoft’s keys are a common target and if the distro is partners with MS, they can have their packages signed with the MS keys. This is technically less secure as the key is widely shared and if it gets cracked somehow, anyone using it is compromised. But it’s a “good enough” solution for many who care to use secureboot at all.

      Personally I just turn it off, and I haven’t experienced any attacks on my machines over the last decade that would take advantage of something that low level. Then again, I’m very careful with what I download and who I open emails from, etc.

  • henfredemars@infosec.pub
    link
    fedilink
    English
    arrow-up
    5
    ·
    1 year ago

    Perhaps I missed it when skimming the article, but why were you looking to replace GRUB?

    In case it was in the article, it might be worth adding that information up here.

    • TiffyBelle@feddit.ukOP
      link
      fedilink
      English
      arrow-up
      18
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Good question! There’s a few reasons, I guess:

      • There’s a large element of “because I can” to this, just to explore how stupid the scope of systemd is as a suite.
      • There’s a small practical element. GRUB itself is quite a hefty tool to accommodate all kinds of boot setups, and it works well. If you have a simple boot setup though you could probably shave a couple of seconds off of the boot time just by using the simplified sd-boot and loading the kernel via its EFIStub.
      • A learning exercise in self-signing EFI binaries, enrolling a MOK (if I use Shim), and setting up scripts to handle updates.

      All boils down to my enjoyment of doing weird nerdy things though, ultimately. =)

  • terminhell@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    1 year ago

    Interesting. I guess this could be a method to allow actual full disk encryption? Unless there’s a way to have grub encrypted too?

    • Laser@feddit.de
      link
      fedilink
      arrow-up
      8
      ·
      1 year ago

      What do you mean by that? TPM and Secure boot do not manage encryption, but rather authentication and key management aspects. You still need an unencrypted UEFI partition storing your EFI binaries. This partition is always readable by an attacker, however any changes to binaries will make booting fail. Also no secrets should be stored here.

    • Skull giver@popplesburger.hilciferous.nl
      link
      fedilink
      arrow-up
      8
      arrow-down
      1
      ·
      1 year ago

      While secure boot and encryption aren’t directly related: yes, you can encrypt everything but the EFI partition. That include the boot partition, if you have such a partition in the first place.

      Secure boot + FDE should be safe if you use your own secure boot keys to sign your own bootloader (unless your motherboard vendor is shit and allows “BIOS password recovery” like the BIOS in my PC). The EFI partition doesn’t need encryption, because the UEFI firmware will validate the bootloader, and the bootloader will validate its configuration, making it impossible to do an evil maid attack.

      If you allow Microsoft’s standard keys, someone can just put an outdated, exploitable signed Grub bootloader on your disk that leaks the keys or messes with initramfs. That’s why custom keys are important. It’s practically impossible to defend against this while still allowing arbitrary boot disks.

      You can configure the bootloader to unlock the disk with a password, with a key stored on the TPM, or both. Just a password is what most people probably use, the TPM solution is useful if you want encryption without the hassle (like default Bitlocker does), and the combination will make it impossible to decrypt a cloned drive even if the attacker knows the password.

      This can be a problem if you ever need to recover your OS. You can clear out your secure boot keys if you have the password to your UEFI configuration, but if you forget it, you’ll be stuck booting only disks you’ve signed. Forgetting your password and losing your signing keys means that you can’t boot anything. Some UEFI firmware allows a forced reset that will clear out all settings and all TPM secrets. If you’ve used a TPM for security purposes, these firmwares will effectively make your encrypted data inaccessible after a reset, which is exactly what you want most likely.

      For further recovery methods, you can have multiple keys on your encrypted LUKS volume. For example, you could store a key file on a USB drive in a safe somewhere that you can use to decrypt your disk even if you forget your password. This allows for data recovery when a TPM encrypted disk is taken out of a broken laptop, for example.

      I have a full disk encryption setup with Grub, but I believe alternative bootloaders can do it too (and even better). It wasn’t that hard to set up, all I did was set up a LUKS partition next to the boot partition, put LVM inside that to do multiple virtual partitions easily, and then configure fstab and crypttab.

  • jungleben@infosec.pub
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    If distros signed the bootloaders with their own keys, then I would configure my system to only use those keys and not include Microsoft’s.

  • witx@lemmy.sdf.org
    link
    fedilink
    arrow-up
    2
    arrow-down
    2
    ·
    1 year ago

    The EFI binary is signed by a private key, whose public key signature is present in the trusted Signature Database (db).

    Shouldn’t it be the opposite? i.e signed by a public key?

    • Hugin@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      Nope. You sign with the private key and verify with the public key. Basically you use the private key to do stuff only you should be able to do and the public key is used by the public to verify it was you who did it.