GRUB Bootloader Picks Up A Verifier Framework For Secure Boot, TPM, PGP Verification

[starshipeleven]

Actually on UEFI laptops (everything modern?) it's possible to boot Linux kernel directly as an EFI application (EFISTUB). This can be additionally signed to work with SecureBoot avoiding the GRUB/bootloader entirely.

This usually requires to have the kernel in the EFI partition, and some script to automate updates and EFI variable setup to boot it. It's not really common.

[Lizintacer]

This usually requires to have the kernel in the EFI partition, and some script to automate updates and EFI variable setup to boot it. It's not really common.

SecureBoot signing script copies the kernel to EFI partition automatically on each kernel update and that's not really a problem that the kernel is there - it works very well with the "encrypted root" partition scheme (kernel is the only thing that is not encrypted but it's signed).

As for the setup of "EFI variables" to boot, it's just pointing to the correct file in UEFI firmware ("bios"), not much more complex than setting up boot order.

[starshipeleven]

SecureBoot signing script copies the kernel to EFI partition automatically on each kernel update and that's not really a problem that the kernel is there - it works very well with the "encrypted root" partition scheme (kernel is the only thing that is not encrypted but it's signed).

As for the setup of "EFI variables" to boot, it's just pointing to the correct file in UEFI firmware ("bios"), not much more complex than setting up boot order.

I'm not saying it is hard, just that most distros don't do it by default.

[discordian]

sorry wtf is this? GPL3 grants that to users, if you don't own the system or you have no permission from the owner/admin you are not a user. Are you confusing it with the Affero GPL license?

Consider what would be required if your Motherboards Bios Implements secure boot and is under GPL3. Anyone that bought a motherboard would be elligible to replace the bios, thus in someway either be able to replace the Bios with unsigned code or be able to sign own code as a drop-in replacement. In the same way hes able to forge a compromised Bios, that must be able to run on those motherboards (thanks to GPL3). A secure chain has the sole reason to prevent having 3rd parties creating compromised software that can be inserted, while GPL3 legally requires this . (Grub being a bootloader would just move this down one step).

You can surely name me one example where this works, despite having multiple users with identical certificates?
I guess you could come up with some schemes where every user gets its own cert down the chain, but thats an administrative nightmare noone wants to have for something critical as the bootsequence.

[starshipeleven]

Consider what would be required if your Motherboards Bios Implements secure boot and is under GPL3.

Anyone that buys a motherboard is eligible to change his own mobo's bios. This is subtle but important.

GPLv3's obligations end where the mobo manufacturer job ends. They ship a board firmware that is open, with no keys nor passwords used to lock it down, to an end user. End of their obligations, everyone is happy.

The end user is NOT subject to GPLv3's obligations unless he also redistributes the code (or the hardware with the firmware in it), and as long as he is using it for himself, he is NOT redistributing it.
So the board can use all kinds of security systems that will work once he inserts his own key and switches them on, this isn't against the GPLv3 as long as they are functionality provided to the user, to serve his needs.

Once I take the mobo and insert my key to sign my stuff, there is no obligation for the manufacturer to get stuff they never owned (my keys) and give it to third parties, which is also illegal. And since i'm NOT distributing the GPLv3 software or the hardware it is on, I'm exempt from having to disclose it and whatever modifications I make to it.

The GPLv3 would only force me to do that once I decide to sell the hardware, so the other end user can enjoy the same freedom they also enjoyed.

The only license that grants rights to passers-by that aren't owning the hardware is the Affero.

[discordian]

Anyone that buys a motherboard is eligible to change his own mobo's bios. This is subtle but important.

GPLv3's obligations end where the mobo manufacturer job ends. They ship a board firmware that is open, with no keys nor passwords used to lock it down, to an end user. End of their obligations, everyone is happy.

With secure boot (alikes) you need to have a way to either sign your own Bios, or disable secure boot. Which means you cant depend on a chain-of-trust.

The end user is NOT subject to GPLv3's obligations unless he also redistributes the code (or the hardware with the firmware in it), and as long as he is using it for himself, he is NOT redistributing it.
So the board can use all kinds of security systems that will work once he inserts his own key and switches them on, this isn't against the GPLv3 as long as they are functionality provided to the user, to serve his needs.

The whole point is that you can verify that code is green-lighted and signed by a 3rd party you trust. Whats the point in signing if you are the only one using it?

Once I take the mobo and insert my key to sign my stuff, there is no obligation for the manufacturer to get stuff they never owned (my keys) and give it to third parties, which is also illegal. And since i'm NOT distributing the GPLv3 software or the hardware it is on, I'm exempt from having to disclose it and whatever modifications I make to it.

The GPLv3 would only force me to do that once I decide to sell the hardware, so the other end user can enjoy the same freedom they also enjoyed.

The only license that grants rights to passers-by that aren't owning the hardware is the Affero.

I still dont get why I would sign my own Software that none else uses, for scrambling your data and identification its pretty useless aswell if you already have an TPM chip.
There is nothing to gain implementing this in a bootloader, unless that bootloader is also signed (with a key the BIOS accepts), and this goes all the way down to a builtin CPU Key.


Ubuntu for example explicitly does not sign Grub because of GPL3 (https://lists.ubuntu.com/archives/ub...ne/035445.html).

...but in the event
that a manufacturer makes a mistake and delivers a locked-down system
with a GRUB 2 image signed by the Ubuntu key, we have not been able to
find legal guidance that we wouldn't then be required by the terms of
the GPLv3 to disclose our private key in order that users can install a
modified boot loader. At that point our certificates would of course be
revoked and everyone would end up worse off.

So in the end, with GPL3 somewhere in the chain, you cant ship with secure boot enabled for legal reasons.
Which means you never can be sure whether your system had been compromised, as it cant be delivered with an always active, intact Chain-of-trust.

once have malicious software running, it can disable secure boot and do whatever it likes.

[starshipeleven]

With secure boot (alikes) you need to have a way to either sign your own Bios, or disable secure boot. Which means you cant depend on a chain-of-trust.

Sorry what? You only need to make sure the board firmware can't be re-flashed easily. Which is apparently a big issue with most computers, but GRUB or Linux can't do anything about that.

Going down to signing your own BIOS and insert the key in the CPU/Chipset is kind of unnecessary as with most mass-produced hardware a malicious attacker can just go and replace the whole motherboard with his own new mobo with a compromised firmware.

The whole point is that you can verify that code is green-lighted and signed by a 3rd party you trust. Whats the point in signing if you are the only one using it?

The issue with software signed by third parties is that a software with known vulnerabilities is still technically "valid" as it was signed with a "valid" and "trusted" third party key.
A malicious attacker can and will swap the latest software with the older vulnerable one, and then he can run his exploits.

Meanwhile the user can just change his signing key all times he wants.

Half-decent key revocation infrastructure in place to blacklist the keys used to sign older and vulnerable software is not trivial to set up (your board firmware needs to phone home and update its blacklisted key database with secure servers from the vendor), and at this time there is nothing, so they can go screw themselves, it's NOT secure.

scrambling your data and identification its pretty useless aswell if you already have an TPM chip.

TPM is just a secure key storage. Encryption is just one of the client software that can use a TPM to store the key.

And again I don't need a TPM when I can remember the password myself.

There is nothing to gain implementing this in a bootloader, unless that bootloader is also signed (with a key the BIOS accepts),

Yeah that's the point. This allows to use GRUB for true Secure Boot scenarios where the goal isn't just to bypass an always-on Secure Boot implementation and you actually want to enforce signatures on booted kernels.

I can concede that GRUB is completely pointless with UEFI anyway so I'm not seeing why I should even want to use GRUB, but whatever.

and this goes all the way down to a builtin CPU Key.

Unnecessary, see above.

Ubuntu for example explicitly does not sign Grub because of GPL3 (https://lists.ubuntu.com/archives/ub...ne/035445.html).
So in the end, with GPL3 somewhere in the chain, you cant ship with secure boot enabled for legal reasons.

That's exactly what I said, you cannot ship security measures enabled, it's the user that should insert his key, sign his stuff and enable security.

You can't have true security if the user isn't an active part in it.

Which means you never can be sure whether your system had been compromised, as it cant be delivered with an always active, intact Chain-of-trust.

GPLv3 is more secure than that. GPLv3 is not trusting even the software vendor.

The GPLv3's idea of trust is based on having the source code. With the source on hand the user creates his chain of trust by compiling and flashing a BIOS image or by comparing checksums with the onboard firmware (you know, reproducible builds are a thing), and then inserting his own keys for the bootloader and/or kernel.

[discordian]

Sorry what? You only need to make sure the board firmware can't be re-flashed easily. Which is apparently a big issue with most computers, but GRUB or Linux can't do anything about that.

Going down to signing your own BIOS and insert the key in the CPU/Chipset is kind of unnecessary as with most mass-produced hardware a malicious attacker can just go and replace the whole motherboard with his own new mobo with a compromised firmware.

The issue with software signed by third parties is that a software with known vulnerabilities is still technically "valid" as it was signed with a "valid" and "trusted" third party key.
A malicious attacker can and will swap the latest software with the older vulnerable one, and then he can run his exploits.

Meanwhile the user can just change his signing key all times he wants.

Half-decent key revocation infrastructure in place to blacklist the keys used to sign older and vulnerable software is not trivial to set up (your board firmware needs to phone home and update its blacklisted key database with secure servers from the vendor), and at this time there is nothing, so they can go screw themselves, it's NOT secure.

TPM is just a secure key storage. Encryption is just one of the client software that can use a TPM to store the key.

And again I don't need a TPM when I can remember the password myself.

Yeah that's the point. This allows to use GRUB for true Secure Boot scenarios where the goal isn't just to bypass an always-on Secure Boot implementation and you actually want to enforce signatures on booted kernels.

I can concede that GRUB is completely pointless with UEFI anyway so I'm not seeing why I should even want to use GRUB, but whatever.

Unnecessary, see above.

That's exactly what I said, you cannot ship security measures enabled, it's the user that should insert his key, sign his stuff and enable security.

You have security measures that should try to prevent malicious code from running, but if a used can replace the BIOS/Bootloadern then so can malicious code.
Secure Boot is a measure to prevent this by design, and the design requires signed code to be always enabled. Implementing it halfway is implementing it broken, and as far as I understand its not possible if GPL3 requires to be replaced while retaining functionality.

You can't have true security if the user isn't an active part in it.

GPLv3 is more secure than that. GPLv3 is not trusting even the software vendor.

Yeah, trusting none and doing nothing is the most secure and safe variant. Its just the opposite of practicable if you go to these extremes.

The GPLv3's idea of trust is based on having the source code. With the source on hand the user creates his chain of trust by compiling and flashing a BIOS image or by comparing checksums with the onboard firmware (you know, reproducible builds are a thing), and then inserting his own keys for the bootloader and/or kernel.

If all software is coming from your end anyway, you don't need keys at all. Do you check your drivers license to verify your identity to yourself?

[nivedita]

You have security measures that should try to prevent malicious code from running, but if a used can replace the BIOS/Bootloadern then so can malicious code.
Secure Boot is a measure to prevent this by design, and the design requires signed code to be always enabled. Implementing it halfway is implementing it broken, and as far as I understand its not possible if GPL3 requires to be replaced while retaining functionality.

Yeah, trusting none and doing nothing is the most secure and safe variant. Its just the opposite of practicable if you go to these extremes.
If all software is coming from your end anyway, you don't need keys at all. Do you check your drivers license to verify your identity to yourself?

Secure boot is generally not meant to prevent modification by a user who is physically present. Most (all?) desktop and server implementations will allow installing your own signing keys. Signing the software you installed with your own key is meant to prevent that software from being modified without your knowledge.
The reason canonical mentioned in that old email is the risk that a manufacturer doesn’t provide a way to install your own keys. GPLv3 could make canonical liable for “aiding” in the manufacturers license violation.