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
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
