5 ms·

The biggest blocker for me using systemd-boot is that there's no signed EFI binary yet so you can't use Secure Boot (unless you want to enrol your own signing k

The biggest blocker for me using systemd-boot is that there's no signed EFI binary yet so you can't use Secure Boot (unless you want to enrol your own signing key, which is inconvenient and I'm not even sure is possible on cloud providers.) If you use Ubuntu, Canonical provide a GRUB binary signed by Microsoft's shim.

georgyo 4y ago
Here is a question for you, what value is secure boot providing you that you cannot get from an encrypted root filesystem with a TPM and systemd-cryptsetup. That is too say, the signed grub binary can be used to load literally anything. It can even chain load into another non-signed modified grub. On the other hand, the crypt setup route ensures that you bios, grub, TPM, and many other measurements are correct. Look at table one here: https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html# https://www.freedesktop.org/software/systemd/man/systemd-cry... One of those measurements is secure boot, but I cannot for the life me figure out what value it is adding.
- sgtnoodle 4y ago
  Secure boot doesn't prevent code from doing whatever it wants once it's running. It prevents the system from starting to run code that isn't trusted in the first place. That's still necessary even if you have a TPM. If you're storing your disk encryption key in a TPM, there needs to be an API for the OS init routine to access the key from the TPM. You can't depend on any secrets outside of the TPM before decrypting the storage (otherwise you wouldn't need a TPM), so instead you need to guarantee that the code accessing the TPM's API isn't malicious. Typically, once the OS reads out the storage encryption key, the OS then immediately asks the TPM to disable its API until a subsequent boot. From that point on the kernel has the key in RAM, and there's no way for unprivileged code to access it (other than bugs). Secure boot provides the mechanism to make that possible. If you don't have secure boot enabled, someone could boot a malicious image that has access to the TPM's API before it's disabled, and therefore gain access to your storage. They would still need to get that image on your computer of course. As you say, though, the vast majority of software running once the OS is booted isn't necessarily secure. Secure boot alone doesn't really help much for foiling bad actors with physical access, since you can just go into the bios settings and disable it. That's why bios typically have their own password protection. On some "embedded" computers, it's practically impossible to turn secure boot once it's been enabled; there's literal fuses inside the chip that get blown.
  - georgyo 4y ago
    The TPM api isn't disabled after boot, and things still use it the computer starts up. IE, it's possible to use the TPM for ssh/gpg keys. Other things like esims and password managers can still use them. It also isn't something that any software can use to just spit out the secrets it stores. The whole point of the TPM is that it will only release information if the measurements of the system match. IE, if I chainload grub->window that will cause a different measurement then it the system just booted windows. But again, secure boot will only run signed images, but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want.
    - Foxboron 4y ago
      >but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want. No, it implements the verifier API which needs to be disabled for this to be true. This should not be the case for distributions utilizing the shim+grub setup (Ubuntu/SUSE/Fedora/Debian/etc)
    - sgtnoodle 4y ago
      I mean the API for accessing the disk encryption key is disabled, not that the whole TPM is disabled. I think we're both saying the same thing, just with different terminology. The TPM will only give the CPU the key when it asks if the current string of measurement matches what the TPM expects. The OS changes the measurement before it starts running untrusted code, and so the TPM no longer gives the same access. I think the critical point is that the measurements are made by the CPU, not the TPM. Malicious code running on the CPU can tell the TPM whatever it wants to tell it. The TPM is notionally just a peripheral hanging off a low speed serial bus. All the TPU can do is watch the sequence of measurements being fed to it, and decide whether or not it looks suspicious. The idea is that everything is chained off of an initial known to be trustworthy state. The initial known state is provided by boot-up, where the first code to run comes from ROM or an EEPROM or flash chip. Secure boot is the mechanism by which that boot-up code can load more code off a storage device and authenticate it. Secure boot is literally what keeps the system secure while booting, before the TPM is configured. Your point about grub being insecure in some ways is likely true. It's been around a long time, and existed before secure boot. The grub image itself being on an unencrypted partition doesn't matter, though, because it is signed; secure boot won't run it if it isn't authentic. I don't think the configuration matters much either. Grub can be configured to give the TPM a measurement of what it's actually loading, i.e. the kernel and initrd and boot options. The TPM can then refuse to give up its secrets if that measurement doesn't match what it expects. Booting is complicated, and when you're mucking around with stuff like grub, it's easy to accidently break the chain without realizing it. There's a reason why corporate IT tends to prefer Mac, Chrome OS, or Windows based computers; it's easier to say that the system is properly secured through boot until the corporate spyware is running. As a practical matter, though, a broken link or two doesn't mean that the whole chain is useless. Stuff like secure boot, TPM, etc. all decrease the attack surface. You shouldn't store nuclear detonation codes on a computer you know isn't perfectly secured, but it's probably fine for your tax return from 2015 and meme collection; no one's going to bother individually targeting you.
still_grokking 4y ago
Secure Boot without enrolling your own keys and deleting the shipped ones is not more than snake oil. In such a case you can just disable it as it doesn't provide anything than additional hassle.
- cedws 4y ago
  Sorry, I think you misunderstand the purpose of Secure Boot.

georgyo 4y ago

Here is a question for you, what value is secure boot providing you that you cannot get from an encrypted root filesystem with a TPM and systemd-cryptsetup. That is too say, the signed grub binary can be used to load literally anything. It can even chain load into another non-signed modified grub. On the other hand, the crypt setup route ensures that you bios, grub, TPM, and many other measurements are correct. Look at table one here: https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html# https://www.freedesktop.org/software/systemd/man/systemd-cry... One of those measurements is secure boot, but I cannot for the life me figure out what value it is adding.

sgtnoodle 4y ago
Secure boot doesn't prevent code from doing whatever it wants once it's running. It prevents the system from starting to run code that isn't trusted in the first place. That's still necessary even if you have a TPM. If you're storing your disk encryption key in a TPM, there needs to be an API for the OS init routine to access the key from the TPM. You can't depend on any secrets outside of the TPM before decrypting the storage (otherwise you wouldn't need a TPM), so instead you need to guarantee that the code accessing the TPM's API isn't malicious. Typically, once the OS reads out the storage encryption key, the OS then immediately asks the TPM to disable its API until a subsequent boot. From that point on the kernel has the key in RAM, and there's no way for unprivileged code to access it (other than bugs). Secure boot provides the mechanism to make that possible. If you don't have secure boot enabled, someone could boot a malicious image that has access to the TPM's API before it's disabled, and therefore gain access to your storage. They would still need to get that image on your computer of course. As you say, though, the vast majority of software running once the OS is booted isn't necessarily secure. Secure boot alone doesn't really help much for foiling bad actors with physical access, since you can just go into the bios settings and disable it. That's why bios typically have their own password protection. On some "embedded" computers, it's practically impossible to turn secure boot once it's been enabled; there's literal fuses inside the chip that get blown.
- georgyo 4y ago
  The TPM api isn't disabled after boot, and things still use it the computer starts up. IE, it's possible to use the TPM for ssh/gpg keys. Other things like esims and password managers can still use them. It also isn't something that any software can use to just spit out the secrets it stores. The whole point of the TPM is that it will only release information if the measurements of the system match. IE, if I chainload grub->window that will cause a different measurement then it the system just booted windows. But again, secure boot will only run signed images, but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want.
  - Foxboron 4y ago
    >but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want. No, it implements the verifier API which needs to be disabled for this to be true. This should not be the case for distributions utilizing the shim+grub setup (Ubuntu/SUSE/Fedora/Debian/etc)
  - sgtnoodle 4y ago
    I mean the API for accessing the disk encryption key is disabled, not that the whole TPM is disabled. I think we're both saying the same thing, just with different terminology. The TPM will only give the CPU the key when it asks if the current string of measurement matches what the TPM expects. The OS changes the measurement before it starts running untrusted code, and so the TPM no longer gives the same access. I think the critical point is that the measurements are made by the CPU, not the TPM. Malicious code running on the CPU can tell the TPM whatever it wants to tell it. The TPM is notionally just a peripheral hanging off a low speed serial bus. All the TPU can do is watch the sequence of measurements being fed to it, and decide whether or not it looks suspicious. The idea is that everything is chained off of an initial known to be trustworthy state. The initial known state is provided by boot-up, where the first code to run comes from ROM or an EEPROM or flash chip. Secure boot is the mechanism by which that boot-up code can load more code off a storage device and authenticate it. Secure boot is literally what keeps the system secure while booting, before the TPM is configured. Your point about grub being insecure in some ways is likely true. It's been around a long time, and existed before secure boot. The grub image itself being on an unencrypted partition doesn't matter, though, because it is signed; secure boot won't run it if it isn't authentic. I don't think the configuration matters much either. Grub can be configured to give the TPM a measurement of what it's actually loading, i.e. the kernel and initrd and boot options. The TPM can then refuse to give up its secrets if that measurement doesn't match what it expects. Booting is complicated, and when you're mucking around with stuff like grub, it's easy to accidently break the chain without realizing it. There's a reason why corporate IT tends to prefer Mac, Chrome OS, or Windows based computers; it's easier to say that the system is properly secured through boot until the corporate spyware is running. As a practical matter, though, a broken link or two doesn't mean that the whole chain is useless. Stuff like secure boot, TPM, etc. all decrease the attack surface. You shouldn't store nuclear detonation codes on a computer you know isn't perfectly secured, but it's probably fine for your tax return from 2015 and meme collection; no one's going to bother individually targeting you.

still_grokking 4y ago

Secure Boot without enrolling your own keys and deleting the shipped ones is not more than snake oil. In such a case you can just disable it as it doesn't provide anything than additional hassle.

cedws 4y ago
Sorry, I think you misunderstand the purpose of Secure Boot.