Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

Thibault Nélis thib at stammed.net
Fri Jun 1 08:47:43 UTC 2012


NOTE/PS  Yes, I was brave and did read myself back (now I feel pain for 
you).  Doing that, I realized we badly need a very visible FAQ 
somewhere.  Does it exist already?  Can we point people to it?  Should 
we write it?  Anyway, here goes:

On 06/01/2012 05:34 AM, Sam Varshavchik wrote:
>>> positive and confident that this entire kit-and-kaboodle has no
>>> choice but require a closed, hood-welded-shut OS, booted up with a
>>> signed chain, in order for it to work.
>>
>>      Oracle Solaris?
>
> Yes, I think that would qualify.

No it isn't necessary.  You're looking at it the wrong way;  basically 
only the things able to boot kernels and kernels themselves have to be 
signed and trusted to ensure the integrity of the kernels.  This is 
because an untrusted piece of software could execute an otherwise 
trusted kernel and do bad things behind its back.

For the rest, we trust these kernels to arbitrate our programs and 
allocate the resources of our machines correctly as they've been doing 
for decades, with no doubt that they've been compromised themselves 
thanks to secure boot.  Whether the security services offered by the 
kernels include checking the integrity of all binaries on the machine[0] 
or not (or the use of many other security features) is irrelevant to 
secure boot, and only depends on how much security you want your kernel 
to provide.

> We're told that Fedora's bootloader is going to get signed – and by
> that, that must mean "grub", right?

No, too many updates, it would be unreasonable to get it signed by a 
third party at each release.  The obvious solution would have been to 
use a certificate store that the firmware could use and get a 
certificate from a trust broker (here, Microsoft).  I'm told this 
solution didn't make it to the UEFI spec (didn't read it myself), so 
we're using a technical hack around this:  a shim bootloader that will 
get signed and won't change often (hopefully never).  Its sole purpose 
will be to chainload to the actual bootloader (GRUB2 for example).

Technically this delegates trust just as a certificate would (implicitly 
this is sort of like a certificate since all packages, including the 
shim, are signed by Fedora release keys), so the ability for Microsoft 
to review that shim code has little value.  Some people say they won't 
sign the shims of all the distros (well, those who target average users 
anyway), I say they get $100 per signature, and duh, it's Micro$oft. 
They can't review all the components that can execute kernels (all 
bootloaders and all versions of all kernels) so they have to delegate 
trust at some point anyway, so might as well make it at the lowest level 
to make the process smooth.

Plus, if a FOSS kernel or bootloader is used as malware to boot their 
Windows operating system, it will affect their users, so they do care, 
and they have to sign as much shims from as many trusted open source 
distros as possible.  The alternative is a big PR and legal storm 
because users of alternative operating systems won't be able to use 
their hardware.  If we were able to force them to give us a choice of 
web browsers on their own OS, we will be able to force them to give us a 
choice of OS on our own machines (we can never own their software, but 
we own our hardware, so the argument is ten times more powerful this 
time).  They know this, and they already publicly announced they were 
gonna play ball.

Yet another reason is that if they don't the world will demand more 
trust brokers more quickly (we should in any case, but people are a 
little slow when it comes to security).  If a business model emerges 
from this and more companies start to make contracts with OEMs to 
distribute certificates (signed shims), they will lose control and 
money.  I believe this will and should happen eventually, so they will 
probably play as nice as possible to keep their customers (they only 
have a headstart).  Remember that they are a lot more of potential 
customers as we usually think of as desktop users (mobile systems, 
server systems, custom embedded systems for all kinds of applications 
and industries).  Well, should these potential customers want to boot 
their systems securely on a wide range of third-party hardware out of 
the box, that is (and Fedora does).

We really shouldn't see it as Red Hat selling out to Microsoft.  As a 
customer, Red Hat owns Microsoft and will be able to chose another trust 
broker as soon as other organizations doing this start to appear, should 
they be dissatisfied with Microsoft's services.  Hell, as you state at 
the end of your post, Red Hat has the infrastructure, the resources, the 
money and the OEM contacts to provide that service itself for itself and 
for many other FOSS players.  It probably just didn't think about it yet 
(or not enough, this isn't an easy business, and should be thought 
through).  Note that even Fedora could be able to do it, as many 
hardware vendors apparently agreed to put Fedora keys in their 
firmwares.  Read the Matthew Garrett's article[2] for the reasons why 
they didn't want to take the responsibility and ultimately didn't go 
with that solution.

Now I know that $100 doesn't seem like much to lose from this 
perspective, and I tend to agree globally.  Maybe the prices will go up 
as some people have predicted, and in a certainly paradoxical way, that 
would be for the best.  The important thing is that trust brokers should 
value their customers enough that they will want to provide a good 
service to them.  Usually that value comes from money.

> And, grub can boot an arbitrary Linux kernel, right?
>
> So, a virus that wants to compromise a signed, secure bootload chain,
> can't it simply install Fedora's signed grub, configured to boot a
> bare-bones Linux kernel, nothing will prevent that, right?

Fedora's signed shim bootloader will check the integrity of GRUB2. 
GRUB2 itself will check the integrity of the kernel.  So no, it's not 
that simple, and yes, it works -- it's the one use-case it's been 
designed for, you'd hope they got it right.

> And, Fedora can load any kernel module, right? Hence, load the virus
> code onto "bare metal", right?

The kernel will check the integrity of the modules.

BTW, if you're wondering about loading your own modules or building your 
own kernel, it wouldn't make sense to ask Fedora to trust your piece of 
software, since it would have nothing to do with Fedora and won't even 
be in their repos.  So you have to do the logical thing, generate a 
personal key and sign your own stuff with it.  That is if you trust 
yourself in case you wrote the code (some people shouldn't ;)) or if you 
trust those who wrote the custom stuff you built/plugged in case you didn't.

If the modules you want are of enough value for all Fedora users, you 
can ask the kernel maintainers (I guess) to review them, sign them and 
bundle them in the Fedora repositories.  This feels natural.

> Then, can't the loaded virus code simply reboot back into the original,
> Windows bootloader, that's now infected, and simply do what the virus
> would've done originally, in the absence of a signed bootloader, right?
>
> If so, then what the FSCK did having an option for a signed bootloader
> accomplish, here???

This would only be possible if the infected bootloader is signed by 
Fedora, since the shim won't load it otherwise.  Fedora will review the 
bootloaders for security breaches (as it does for all its packages as 
standard QA), so that's not an option.

An alternative would be for the attacker to get its bootloader signed by 
a trust broker (Microsoft), and thus replace the shim.  Hopefully, 
Microsoft won't just sign anything and review the code, but this is 
still a real problem IMHO (as I stated already, reviewing shims has 
little value anyway, the real issue is in delegating trust to good 
people only).

That and the fact that every hacker in the world will probably make it a 
fun game of Who's Gonna Get To The Microsoft Root Key First.  I'm sure 
it's locked away Hollywood-style somewhere safe, but Big Corp keys are 
known to be compromised (especially these last few years).

Note that if they do sign a shim owned by a bad guy, they can blacklist 
them.  As I stated in another thread[1], $100 might not be enough to 
prevent them from reacquiring a new signed shim, but that's still better 
than nothing (difficulty to hide financial traces, necessity to come up 
with a good story with the trust broker [Microsoft] everytime, etc).

The real solution is to load your own key in the firmware and sign 
Fedora's shim, hence stating that YOU trust Fedora explicitly (and not 
because Microsoft trusts it), and remove Microsoft's key, stating that 
you don't implicitly trust all that Microsoft trusts.

And that's what everybody should and will do.  The thing is, you can't 
do it automatically, obviously, since that would defeat the entire 
purpose of the system (malware could simply store its own keys).  So 
you, as a user, have to go into the UEFI firmware setup UI when booting 
your machine, and install your key.  I don't know how streamlined the 
process will be (ask people who have prototypes around), but I suspect 
many "average" users won't bother / will be afraid to do it.  They would 
be wrong, but forcing people to care about security is known to be 
fruitless.

IMHO, it should be possible for operating systems to popup a simple 
dialog asking the user if it trusts the current bootloader, and then 
automatically generate a key, generate a personal shim (signed with the 
key) that will verify the integrity of the current bootloader (that the 
user trusts), install the shim, and then, via the magic of an as of yet 
non-existent interface, install the key in the firmware securely.

=== SNIP a few ideas for that magic interface ===

1.  Close to impossible to put in place, no technical restrictions, very 
easy to use:

It should be technically possible to for example place a special button 
on the hardware, along with a LED.  When the operating system asks to 
store the key, the LED lights up, and the way the user would approve the 
move would be to press that button (a bit like how new household routers 
work to setup Wifi security).  Obviously, standardizing on the button 
and how it is connected to motherboards would be incredibly hard, and 
that solution would need to be backed up by many big players.  Probably 
not worth all the trouble, but usable for any kind of device (including 
headless servers, etc).

2.  Very hard to put in place, unusable for headless machines, very easy 
to use (but special care taken to address phishing-like techniques):

Another solution that would be to have UEFI traps so that the firmware 
itself can grab input and screen to prompt the user for confirmation via 
a trusted interface with a cool recognizable logo and maybe a crypto QR 
code or anything that can satisfy the most paranoid users that they're 
really talking to their firmware and not a phishing program (kind of 
like what PolicyKit and Microsoft's whateverthatscalled thingie do).  I 
don't know how capable UEFI software is of this, and we're certainly not 
there yet, but I expect that some community projects will develop 
alternative open-source UEFI firmwares, who may or may not able to 
demonstrate if this scheme works, then propose standard interfaces and 
maybe push hardware vendors to implement them.  That kind of thing 
doesn't happen too often, but it happened in the past.

3.  Still hard to implement, but doesn't go all the way to make internal 
things easier to put in place, unusable for headless machines, a bit 
less practical to use but still very easy for the average user (same 
attention to phishing-like techniques however):

A third, more reasonable solution that is still practical would be for 
the operating system to ask the UEFI firmware to prompt the user on the 
next reboot, so that she can explicitly state that she trusts the key 
generated by the operating system.  It still needs a new API between the 
OS and the UEFI firmware, but at least it's only software.  The 
disadvantage is that the user has to reboot, but that's OK, you 
typically will only renew your keys every few years;  I don't think 
Fedora users in particular still play the uptime games.

4.  Actually not too hard to implement, just hard to put in place in the 
UEFI spec, exact same restrictions and ease of use as idea #3:

To expand on that last solution, a scheme where no direct interface 
between the OS and the firmware is possible:  the firmware could look 
for a certain file on the disk (there is a special partition for UEFI I 
believe) at boot.  This file can be written by the OS and contain the 
key and maybe some information about when it was generated, by whom, in 
what context, and what it was used for (which components were signed) -- 
essentially, a certificate, signed itself.  The firmware can then prompt 
the user before running the bootloader and display all this information 
(as well as a fingerprint of the key, of course) so that she can make a 
safe choice.  This solution still requires some changes to the UEFI 
firmware, but these are I think the less intrusive / most doable.


Note that I didn't give much thought about these ideas yet, they may be 
fundamentally flawed.

=== / SNIP ===

> I don't have any answers to these questions (like I said, I'm feeling a
> bit stupid today), but I do know one thing for sure. If everything that
> what's been publicly said on this subject, so far, is true, then:
>
> Someone around here is a bloomin' idiot of the first degree. An
> absolute, total, clueless moron. Complete, and total, brain damage. That
> could be either myself – a possibility that I am perfectly willing to
> admit – or Microsoft; or whoever's pushing this.

It's not an easy thing to grasp at first, so don't worry when I say 
Microsoft isn't being too stupid on this one.  Not necessarily nice 
either (time will tell, but as I said already there's hope), but overall 
the system works.

> The other possibility, of course, is that most of what's been publicly
> stated about this subject, has either been a complete lie or a
> fabrication; or certain crucial, fundamental details about this process,
> have been omitted. It just /cannot/ work the way it's been publicly
> announced.

I already rambled a bit about the less technical aspects of it here[1], 
so I won't go through it again (I should write a blog or something, 
shouldn't I?), but I hope I cleared things up a bit.  I can't say I'm an 
expert in the matter though, so don't quote me on anything.

> Now, let me make a prediction of what I think is /really/ going to
> happen. After thinking about this, oh, for maybe five minutes, tops, I
> think I have up with the only answer that makes any logical sense, given
> everything that's been publicly said. With apologies to Sir Arthur Conan
> Doyle, whose literary masterpiece I'm about to butcher: when you exclude
> all possibilities that are logically impossible, whatever's left, no
> matter how highly improbable or bizarre, must be true.
>
> What I'm convinced that this is all about, is that Red Hat will simply
> get Microsoft to sign a bootloader that will boot a kernel that's signed
> with Red Hat's private key. The kernel will be configured to load only
> kernel modules that are also signed by Red Hat's private key. OEMs that
> supply OEM binary blobs, for stuff like RAID cards, etc, that are
> certified with RHEL, will get Red Hat to sign their kernel modules for
> them, also for a token certification key. That's the hood, welded shut,
> that's absolutely mandatory for a secured bootloader to have any logical
> purpose, whatsoever.

I believe that's the plan yes.  The binary blob issue is still a bit 
foggy from what I hear, but as you said in other words, there's not much 
alternatives.  Note that as I mentioned already, I really think Red Hat 
would make a good trust broker between OEMs and community distros.  As 
would the Linux Foundation, the FSF, the OSI, Debian, Canonical, SUSE, 
and all the other big ones.

> Based on publicly known information to me, this is the only situation
> that makes any sense. Nothing else could possibly work, in any logical
> fashion.
>
> Fedora is not going to be a part of this. In order to boot Fedora, it
> will be necessary to disable the secure bootload, on the hardware.

I think it would be a shame to pass on that tech, I think it has 
potential[1] if we do it right, but that's just me.  The potential 
problems with an initial Microsoft monopoly on the signing services will 
only affect the users who don't care, the rest will install their own 
keys, and hopefully the whole FOSS community will come up with solutions 
to streamline the process as well as build a web of trust to help people 
know who and what to trust and automate as many steps as possible with 
fancy algorithms and (personal) policies.

> I welcome anyone to explain what part of the above is logically false,
> and why.

Hope that helped, sorry for the length.

[0] http://linux-ima.sourceforge.net/
[1] https://lists.fedoraproject.org/pipermail/users/2012-May/418934.html
[2] http://mjg59.dreamwidth.org/12368.html

PS  Should anyone want to reply to this fat blob, please feel free to 
branch the thread.  I think I've made a big mess.
-- 
t


More information about the users mailing list