![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59It's fairly straightforward to boot a UEFI Secure Boot system using something like Shim or the Linux Foundation's loader, and for distributions using either the LF loader or the generic version of Shim that's pretty much all you need to care about. The physically-present end user has had to explicitly install new keys or hashes, and that means that you no longer need to care about Microsoft's security policies or (assuming there's no exploitable flaws in the bootloader itself) fear any kind of revocation.
But what about if you're a distribution that cares about booting without the user having to install keys? There's several reasons to want that (convenience for naive users, ability to netboot, that kind of thing), but it has the downside that your system can now be used as an attack vector against other operating systems. Do you care about that? It depends how you weigh the risks. First, someone would have to use your system to attack another. Second, Microsoft would have to care enough to revoke your signature. The first hasn't happened yet, so we have no real idea how likely the second is. However, it doesn't seem awfully unlikely that Microsoft would be willing to revoke a distribution signature if that distribution were being used to attack Windows.
How do you avoid that scenario? There's various bits of security work you need to do, but one of them is to require that all your kernel modules be signed. That's easy for the modules in the distribution, since you just sign them all before shipping them. But how about third party modules? There's three main options here:
The first option is easy, but not likely to please users. Or hardware vendors. Not ideal.
The second option is irritating for a bunch of reasons, and a pretty significant one is license-related. If you sign a module, does that mean you're endorsing it in some way? Does signing the nvidia driver mean that you think there's no license concerns? Even ignoring that, how do you decide whose drivers to sign? We can probably assume that companies like AMD and nvidia are fairly reputable, but how about Honest John's Driver Emporium? Verifying someone's identity is astonishingly expensive to do a good job of yourself, and not hugely cheaper if you farm it out to a third party. It's also irritating for the driver vendor, who needs a separate signature for every distribution they support. So, while possible, this isn't an attractive solution.
The third option pushes the responsibility out to other people, and it's always nice to get other people to do work instead of you. The problem then is deciding whose keys you trust. You can push that off to the user, but it's not the friendliest solution. The alternative is to trust any keys that are signed with a trusted key. But what is a trusted key? Having the distribution sign keys just pushes us back to option (2) - you need to verify everyone's identity, and they need a separate signing key for every distribution they support. In an ideal world, there'd be a key that we already trust and which is owned by someone willing to sign things with it.
The good news is that such a key exists. The bad news is that it's owned by Microsoft.
The recent discussion on LKML was about a patchset that allowed the kernel to install new keys if they were inside a PE/COFF binary signed by a trusted key. It's worth emphasising that this patchset doesn't change the set of keys that the kernel trusts - the kernel trusts keys that are installed in your system firmware, so if your system firmware trusts the Microsoft key then your kernel already trusts the Microsoft key. The reasoning here is pretty straightforward. If your firmware trusts things signed by Microsoft, and if a bad person can get things signed by Microsoft, the bad person can already give you a package containing a backdoored bootloader. Letting them sign kernel modules doesn't alter the power they already have over your system. Microsoft will sign PE/COFF binaries, so a vendor would just have to sign up with Microsoft, pay $99 to Symantec to get their ID verified, wrap their key in a PE/COFF binary and then get it signed by Microsoft. The kernel would see that this object was signed by a trusted key and extract and install the key.
Linus is, to put it mildly, unenthusiastic about this idea. It adds some extra complexity to the kernel in the form of a binary parser that would only be used to load keys from userspace, and the kernel already has an interface for that in the form of X509 certificates. The problem we have is that Microsoft won't sign X509 certificates, and there's no way to turn a PE/COFF signature into an X509 signature. Someone would have to re-sign the keys, which starts getting us back to option (2). One way around this would be to have an automated service that accepts PE/COFF objects, verifies that they're signed by Microsoft, extracts the key, re-signs it with a new private key and spits out an X509 certificate. That avoids having to add any new code to the kernel, but it means that there would have to be someone to run that service and it means that their public key would have to be trusted by the kernel by default.
Who would that third party be? The logical choice might be the Linux Foundation, but since we have members of the Linux Foundation Technical Advisory Board saying that they think module signing is unnecessary and that there's no real risk of revocation, it doesn't seem likely that they'll be enthusiastic. A distribution could do it, but there'd be arguments about putting one distribution in a more privileged position than others. So far, nobody's stood up to do this.
A possible outcome is that the distributions who care about signed modules will all just carry this patchset anyway, and the ones who don't won't. That's probably going to be interpreted by many as giving too much responsibility to Microsoft, but it's worth emphasising that these patches change nothing in that respect - if your firmware trusts Microsoft, you already trust Microsoft. If your firmware doesn't trust Microsoft, these patches will not cause your kernel to trust Microsoft. If you've set up your own chain of trust instead, anything signed by Microsoft will be rejected.
What's next? It wouldn't surprise me too much if nothing happens until someone demonstrates how to use a signed Linux system to attack Windows. Microsoft's response to that will probably determine whether anyone ends up caring.
But what about if you're a distribution that cares about booting without the user having to install keys? There's several reasons to want that (convenience for naive users, ability to netboot, that kind of thing), but it has the downside that your system can now be used as an attack vector against other operating systems. Do you care about that? It depends how you weigh the risks. First, someone would have to use your system to attack another. Second, Microsoft would have to care enough to revoke your signature. The first hasn't happened yet, so we have no real idea how likely the second is. However, it doesn't seem awfully unlikely that Microsoft would be willing to revoke a distribution signature if that distribution were being used to attack Windows.
How do you avoid that scenario? There's various bits of security work you need to do, but one of them is to require that all your kernel modules be signed. That's easy for the modules in the distribution, since you just sign them all before shipping them. But how about third party modules? There's three main options here:
- Don't support third party modules on Secure Boot systems
- Have the distribution sign the modules
- Have the vendor sign the modules
The first option is easy, but not likely to please users. Or hardware vendors. Not ideal.
The second option is irritating for a bunch of reasons, and a pretty significant one is license-related. If you sign a module, does that mean you're endorsing it in some way? Does signing the nvidia driver mean that you think there's no license concerns? Even ignoring that, how do you decide whose drivers to sign? We can probably assume that companies like AMD and nvidia are fairly reputable, but how about Honest John's Driver Emporium? Verifying someone's identity is astonishingly expensive to do a good job of yourself, and not hugely cheaper if you farm it out to a third party. It's also irritating for the driver vendor, who needs a separate signature for every distribution they support. So, while possible, this isn't an attractive solution.
The third option pushes the responsibility out to other people, and it's always nice to get other people to do work instead of you. The problem then is deciding whose keys you trust. You can push that off to the user, but it's not the friendliest solution. The alternative is to trust any keys that are signed with a trusted key. But what is a trusted key? Having the distribution sign keys just pushes us back to option (2) - you need to verify everyone's identity, and they need a separate signing key for every distribution they support. In an ideal world, there'd be a key that we already trust and which is owned by someone willing to sign things with it.
The good news is that such a key exists. The bad news is that it's owned by Microsoft.
The recent discussion on LKML was about a patchset that allowed the kernel to install new keys if they were inside a PE/COFF binary signed by a trusted key. It's worth emphasising that this patchset doesn't change the set of keys that the kernel trusts - the kernel trusts keys that are installed in your system firmware, so if your system firmware trusts the Microsoft key then your kernel already trusts the Microsoft key. The reasoning here is pretty straightforward. If your firmware trusts things signed by Microsoft, and if a bad person can get things signed by Microsoft, the bad person can already give you a package containing a backdoored bootloader. Letting them sign kernel modules doesn't alter the power they already have over your system. Microsoft will sign PE/COFF binaries, so a vendor would just have to sign up with Microsoft, pay $99 to Symantec to get their ID verified, wrap their key in a PE/COFF binary and then get it signed by Microsoft. The kernel would see that this object was signed by a trusted key and extract and install the key.
Linus is, to put it mildly, unenthusiastic about this idea. It adds some extra complexity to the kernel in the form of a binary parser that would only be used to load keys from userspace, and the kernel already has an interface for that in the form of X509 certificates. The problem we have is that Microsoft won't sign X509 certificates, and there's no way to turn a PE/COFF signature into an X509 signature. Someone would have to re-sign the keys, which starts getting us back to option (2). One way around this would be to have an automated service that accepts PE/COFF objects, verifies that they're signed by Microsoft, extracts the key, re-signs it with a new private key and spits out an X509 certificate. That avoids having to add any new code to the kernel, but it means that there would have to be someone to run that service and it means that their public key would have to be trusted by the kernel by default.
Who would that third party be? The logical choice might be the Linux Foundation, but since we have members of the Linux Foundation Technical Advisory Board saying that they think module signing is unnecessary and that there's no real risk of revocation, it doesn't seem likely that they'll be enthusiastic. A distribution could do it, but there'd be arguments about putting one distribution in a more privileged position than others. So far, nobody's stood up to do this.
A possible outcome is that the distributions who care about signed modules will all just carry this patchset anyway, and the ones who don't won't. That's probably going to be interpreted by many as giving too much responsibility to Microsoft, but it's worth emphasising that these patches change nothing in that respect - if your firmware trusts Microsoft, you already trust Microsoft. If your firmware doesn't trust Microsoft, these patches will not cause your kernel to trust Microsoft. If you've set up your own chain of trust instead, anything signed by Microsoft will be rejected.
What's next? It wouldn't surprise me too much if nothing happens until someone demonstrates how to use a signed Linux system to attack Windows. Microsoft's response to that will probably determine whether anyone ends up caring.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2013-02-27 03:28 pm (UTC)FSF via wikipedia:
Freedom 0: The freedom to run the program for any purpose.
Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
Freedom 2: The freedom to redistribute copies so you can help your neighbor.
Freedom 3: The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefit)
I would argue that if the user cannot modify the kernel and run it, or load their own modifications in the normal way, that violates "Freedom 3", and if we want to be really pedantic then preventing an "attack on Windows" violates Freedom 0.
(Admittedly I disagree with this argument when it's made about the Raspberry Pi GPU, but that's the strange world we're now in; a "computer" contains many different processors and state machines, some of which are user accessible and some of which aren't. This particular "secure" business is a software boundary rather than a hardware one; on one side the user can run any program they want, and on the other they can't.)
no subject
Date: 2013-02-27 03:32 pm (UTC)CA
Date: 2013-02-27 05:29 pm (UTC)What would be so terribly hard about a coalition of large distros outsourcing identity verification to an existing CA? We already trust the CAs to do this verification for a wide range of uses, and their charges for those other uses isn't terribly excessive. Certainly for huge corporations like nvidia and AMD it would be less than a rounding error, especially if they only had to be verified once for many distros. It doesn't seem to me like a Distro Coalition would in any way be endorsing the modules signed this way—all they'd be claiming is "if this is exploited, we can revoke the key", which is clearly true.
I'm sure I must be overlooking something, so what's the problem with this solution?
Cheers!
Re: CA
Date: 2013-02-27 05:40 pm (UTC)Attack vector example?
Date: 2013-02-27 06:06 pm (UTC)Re: Attack vector example?
Date: 2013-02-27 06:10 pm (UTC)Re: Attack vector example?
Date: 2013-02-27 07:16 pm (UTC)Re: Attack vector example?
From: (Anonymous) - Date: 2013-02-27 07:42 pm (UTC) - ExpandRe: Attack vector example?
From:you can detect when running virtualized
From: (Anonymous) - Date: 2013-02-28 08:22 pm (UTC) - ExpandRe: you can detect when running virtualized
From:Re: Attack vector example?
Date: 2013-02-27 09:10 pm (UTC)Re: Attack vector example?
From:So tired...
Date: 2013-02-27 11:14 pm (UTC)What I want is the ability to buy the hardware I want and install the distribution I want without being bothered to mess around with keys, yada, yada, yada.
What I want is the ability to use Linux and enable Secure Boot if I want to, without messing around with keys, yada, yada, yada.
If we end up in a situation that sees many Linux users running with secure boot disabled, *and* then we see some of those Linux machines being used in successful, widespread, and well-publicized attacks, no distinction will be made between Linux with secure boot enabled and Linux with secure boot disabled. Linux will take the fall in grandiose fashion and be branded as the OS of choice for criminals.
Finally, I cannot even begin to tell you how tired I am of being told, in so many words, that I should just put up with one or another Linux inadequacy or annoyance because we are all one big happy community out to defeat the Microsoft dragon.
secure boot has implications
Date: 2013-02-28 08:26 pm (UTC)In a secure-boot environment you either need to prevent people from doing those things, or else you need to make sure that they do them in a way that preserves the chain of security--which means messing with keys.
On Microsoft systems the problem is simplified--you can't do kexec, period. And if you want to load your own custom modules onto a secure system you need to mess with keys.
Wow, what a lot of dissembling!
Date: 2013-02-28 02:25 am (UTC)I guess religion must be something like this.
When are you going do a post about the other changes that need to be made in kernel - hibernation and kexec - in order to satisfy your overlords at Redmond?
Sam Varghese
Re: Wow, what a lot of dissembling!
Date: 2013-02-28 02:44 am (UTC)Re: Wow, what a lot of dissembling!
Date: 2013-02-28 05:55 am (UTC)http://www.itwire.com/opinion-and-analysis/open-sauce/58875-torvalds-blasts-howells-garrett-over-secure-boot
http://www.itwire.com/opinion-and-analysis/open-sauce/58903-secure-boot-microsoft-can-revoke-distro-keys
Re: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 06:21 am (UTC) - ExpandRe: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 07:17 am (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 08:47 am (UTC) - ExpandRe: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-03-01 03:26 am (UTC) - ExpandRe: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-03-01 06:14 am (UTC) - ExpandRe: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 12:17 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 03:42 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From:Re: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 11:24 am (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 12:15 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 04:23 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 04:44 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 08:12 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 10:49 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 10:58 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-02-28 11:02 pm (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-03-01 03:29 am (UTC) - ExpandRe: Wow, what a lot of dissembling!
From: (Anonymous) - Date: 2013-03-01 04:03 pm (UTC) - ExpandReputation
From:Re: Reputation
From: (Anonymous) - Date: 2013-03-02 01:41 pm (UTC) - Expandisn't the shim already breaking security
Date: 2013-02-28 03:14 am (UTC)Re: isn't the shim already breaking security
Date: 2013-02-28 03:24 am (UTC)Re: isn't the shim already breaking security
Date: 2013-02-28 06:41 pm (UTC)I think the physical access bit is where it gets confusing. I've tried to follow this and I'm still confused about how things fit together (so I just disable secure boot).
Excluding ARM because it is configured differently, and focussing on x86 my understanding is:
Physical access is complete control either by:
a) disabling secure boot
b) adding ones own keys
c) having bootable media present at boot time that is signed with a pre-existing key (ie MSFTs)
The only attack secure boot is designed to prevent on x86 is a remotely delivered virus that exploits a vulnerability to reach priviliged mode and tries to modify the kernel to setup a rootkit. Such a virus would not have the requisite signature to be able to inject code or keys into the secure boot infrastructure, and the subsequent boot would fail.
The shim bootloader is not capable of attacking the system without physical access because it only executes and installs keys at boot time and only with physical access. MSFT is happy to sign it because they don't care what happens at boot time with physical access, they care about what happens after boot time and where physical access cannot be demonstrated to the hardware.
Is that a correct characterization?
Re: isn't the shim already breaking security
From:no subject
Date: 2013-02-28 08:49 am (UTC)I don't know whether or not Linux is about choice. But I really appreciate being able to choose between booting Linux with secure boot enabled or disabled. And your work ensures that that will just work, not just now but also in the future.
A possible 4th solution...
Date: 2013-02-28 11:54 am (UTC)On the other hand, maybe we should just go with (1) and let the vendors choose between pressuring MSFT to sign X509 certs or submitting their drivers to mainline.
Another thought
Date: 2013-02-28 12:03 pm (UTC)That being said, some of the people involved in the discussion (on both sides, but particularly notable was Greg KH insisting that signed modules don't matter) seem utterly disingenuous and that nothing will be done until a POC attack is demonstrated and MSFT starts the revocation process.
PE/COFF?
Date: 2013-02-28 05:35 pm (UTC)Can't be done? Dell/HP would be highly agreeable.
Key management is inconvenient for users? These are Linux users we're talking about. If they need to be protected from themselves, they shouldn't be exposed to it. If they're advanced users they can simply disable secure boot and carry on.
Re: PE/COFF?
Date: 2013-02-28 05:44 pm (UTC)Re: PE/COFF?
Date: 2013-02-28 06:45 pm (UTC)Remember, HP and Dell are members of the Linux Foundation, so if they really wanted the Linux Foundation to do such a thing, the LF would.
greg k-h
Re: PE/COFF?
Date: 2013-03-01 03:04 pm (UTC)Was Google / Canonical / Valve involved in cheerleading for the discussion? They should be. A second approach to the topic would be a good idea.
Re: PE/COFF?
From: (Anonymous) - Date: 2013-03-03 04:44 am (UTC) - ExpandWhat about the case I have taken the Platform key.
Date: 2013-03-01 12:00 am (UTC)Here is a nice stupid question.
"The problem we have is that Microsoft won't sign X509 certificates, and there's no way to turn a PE/COFF signature into an X509 signature."
So you are not allowed to place a X509 certificate with X509 self signed signature and in a extra section in the PE/COFF that Microsoft is going to sign. Of course be creative that its the the extra X509 certificate and signature is to prevent MS tampering in the signing process. You can check against vendor if the certificate is correct.
That would provide a solution. To turn to Linux binary cut of MS signing. This also allows a key per vendor. Now If I have a Nvidia video card I don't need to load ATI drivers. Currently with the Microsoft signing solution its possible for me to load ATI drivers. Nice if ATI releases a buggy driver that gets past MS signing. Now the reverse could be true.
--if a bad person can get things signed by Microsoft, the bad person can already give you a package containing a backdoored bootloader.--
Matthew Garrett this is why the current mono culture of signing cannot remain. If I have taken the platform key and the KEK and removed the Microsoft keys. A Microsoft back doored bootloader is not going to work.
The reality here is you should be providing two bootloaders from redhat. One Signed by Microsoft. The Other signed by Redhat. Both binary identical other than the signing. Or you work out someway to get both signatures in 1 binary. Vendor signature and validators signature are required to prevent tampering.
Mattew Garrett how would we confirm that the Microsoft key is breached if you don't self sign something. Reason for doing this is then two keys would have to be breached not one.
Next for module loading should the Linux kernel trust the KEK most likely not. Multi OS install the keys in KEK are most likely too allowing.
Reality is most like the Linux kernel should for module signing only accept keys in the MOK that owns to the distribution. Like something signed by redhat for the redhat kernel really should not load in the Ubuntu kernel and vice verse. Normal API barriers currently prevent this but if you start making universal binary interfaces this is going to fail.
Next as you should remember Matthew Garrett from when Fedora changed the block size of memory. Distributions need to be able to blacklist modules Microsoft has approved. Reason Microsoft is only checking against will it work with Microsoft Windows not will not not do something stupid to a Linux install.
Re: What about the case I have taken the Platform key.
Date: 2013-03-01 12:05 am (UTC)The bootloader shipped in Fedora is actually already signed by a Fedora key as well as the Microsoft key. Most firmware implementations will ignore the second signature, but that's being fixed in the spec. You can post-process the file to remove the first signature and just have a Fedora-signed bootloader.
Re: What about the case I have taken the Platform key.
From: (Anonymous) - Date: 2013-03-01 01:51 pm (UTC) - Expand