Need more info: UEFI Secure Boot in Fedora [Long]

Thibault NĂ©lis thib at stammed.net
Thu May 31 16:15:59 UTC 2012


On 05/31/2012 02:38 PM, Alan Cox wrote:
> It's of course all a bit of a joke because it's then a simple matter of
> using virtualisation to fake the "secure" environment and running the
> "secure" OS in that 8)

The distributions can review the hypervisor code (then sign it as a 
symbol of trust) and the kernel can then verify its integrity at runtime 
(just like the firmware verifies the bootloader's integrity, and the 
bootloader the kernel's). The hypervisor can then emulate secure boot 
for the virtual machines and continue the chain. Note that you're 
already half-way there with KVM, since most of its code runs in the 
kernel itself.

Other hypervisors wouldn't be any different from any other package 
offered by the distribution, at least if the maintainers provide 
security support for all of them (as is the case for most serious 
distros). It would be pointless to sign and verify every binary, library 
and script on the system if the code isn't trusted.

Mature infrastructure for integrity checking already exists: most IDS do 
file change tracking (they would need to be explicitely supported by the 
kernel though), but see the Linux Integrity Subsystem (in the form of 
the Integrity Measurement Architecture and the Extended Verification 
Module).

(Repost: http://mjg59.dreamwidth.org/12368.html?thread=399184#cmt399184)

>> No. I would assume the Fedora project pays the $99, and then distrubtes
>> the signed bootloader component, with the fedora keys built in.
>
> I don't believe that would be compliant with the Fedora Project
> definitions of freedom.

[Reply not directed at anyone in particular, I'm just rambling from now on]

Let's just see it from another perspective.  The obvious alternative is 
for Fedora and every other distribution to ask every single hardware 
vendor to include their own key in their firmwares.  It's impossible, 
plain and simple.  The communications channels would have to be 
super-efficient (they never are with such bureaucracy), the policies 
extra-clear, and the upgrade processes absolutely smooth (to accommodate 
with new software distributions, key expiration and thefts).  I almost 
see an entire stack of protocols there, a long standardization process, 
and we still exclude offline or rarely connected users who won't be able 
to keep up with slower channels.

So, as always in this kind of situation, we add another level of 
indirection, in the form of a trust broker.  Hardware vendors trust a 
few big brokers in the software industry (more than a dozen would be 
ideal), and these brokers in turn place their trust in software 
distributors and make it their job to see that these distributors don't 
abuse that trust, blacklisting those who do.  Not all communities would 
have the resources to do that (although I think the Linux Foundation 
should act as a broker).  Companies in the software industry can, and 
they already have the contacts with the OEMs, let them do it.

If anything, $100 for such a service with no apparent human verification 
is probably too low.  Many attackers would probably pay-up to have their 
malware compromise as many machines as possible before they get 
blacklisted.  Infected machines can certainly be stopped from receiving 
updates, so the revocations will only stop the spreading of the botnets, 
not shut them down.  If they can spare $100 every few months (they 
probably make way more from their botnet business) to get a new key, 
they might just be alright.  The system may stop the weakest players though.

Another big point for making people pay to have their components signed, 
aside from financing the operation properly (necessary to keep the root 
key really secure and push the revocations in time) and discouraging 
small attackers, is that it's increasingly difficult to pay 
electronically anonymously, at least as long as no broker trusted by the 
vendors starts issuing signed components for anonymous money (BTC for 
example).  Obviously, and just like the PKI for X509 CA hierarchy, the 
weakest link of the chain can fail the whole system (which is why there 
shouldn't be too many brokers, see the current web browsers struggle and 
last year f*-ups).

Now, we only have Microsoft, but hopefully this is only the beginning. 
Aside from all the obvious potential abuses (blocking free software 
arbitrarily), the technology is actually quite sound if we can control 
it.  And the good news is, we can.


We can and we must.  Even though this all looks relatively good(-ish), 
in reality it's merely good enough (a) for the average user who doesn't 
care too much about having to trust big corporations to more or less 
know what they want and to act in their favor and (b) for the average 
big distribution which doesn't care too much about giving away contact 
information and a little bit of money.  (BTW, if you insist you don't 
fit that user description yet don't use something like Monkeysphere for 
your web browsing, then you're a hypocrite.)

The good we get out of it is that we can automate every step of the 
verification process;  we all know that security has to be traded for 
convenience, so here we pay for completely transparent security simply 
by using a sub-optimal trust model that is still way better than nothing 
(even though HTTPS w/ X509 PKI is so horribly broken, it still 
undeniably prevented an extraordinary amount of real attacks).

But for the more concerned users (this doesn't only include technical 
people), good enough doesn't cut it.  The bad we get is too inconvenient 
by itself and so we figure that while we're at it, we might as well 
trade that inconvenience for actual security, rather than worries and 
doubts.  For now, I think most power-users will generate their own keys 
and verify each organization by hand (entrusting them via boot loader 
shims or signing components directly), taking over the role of the big 
corporations, but with only one easy customer:  themselves.

In the (far, but not too far) future, I see value for a completely 
decentralized model for signing components by individuals and small 
organizations, with fancy algorithms to determine if you should or 
should not run certain pieces of software, based on what people you 
trust think about them (with configurable criteria such has "the code 
must have been reviewed by at least two trustworthy people in the last X 
weeks).  And not just for boot loaders and kernels, but for all software 
packages, as I already explained.  (Untrusted software could 
automatically be run in a sandbox of some appropriate level, for example 
with SELinux or LXC.)

Well, we're most certainly not there yet, but I really do see potential 
in that tech.  I guess it's up to us, as always;  I just hope we're not 
gonna make the same mistakes as we did with the web again.

...

Or maybe everybody's gonna disable it, what do I know anyway ;).
-- 
t


More information about the users mailing list