On 06/01/2012 09:46 AM, Alan Cox wrote:
Out of support releases are also an interesting problem. If a hole is
found they need to revoke the key. If they do that the users machine is
crippled. It's potentially a criminal matter in many EU states as well so
whoever issues the revocation could end up in jail. Nobody is really too
sure. This is all untested waters.
If we're talking about the kernel, one can always make the boot loader
prompt the user whether it wants to continue without the assurance of a
safe boot, possibly launching the (unsafe) kernel in some sort of locked
down mode (filtering connections and whatnot) to try to avoid compromise
in case the system isn't yet infected. All the system has to do is
fetch a new kernel and install it somehow, and if it does, even if it
*is* infected, it would work, since the bootloader is assumed to be secure.
If it's the bootloader that doesn't match, the shim could do the same.
The thing is, if machines are compromised, the first thing the malware
will do will be to block the revocations coming from the network. As
such, I think that for real-world end-users who don't go fetch
revocations frequently via secure back-channels, the only real advantage
of secure boot will be to stop the spread of malware, not cure it. For
that, you would still need the usual detection and removal techniques.
Don't get me wrong, containing malware infections is still a huge win,
especially when we consider the number of active botnets today, but to
me I don't think OS developers should worry too much about locking down
infected machines. If it's infected, the fight is already lost.
Or I maybe I totally missed something; is the firmware able to go fetch
revocations itself? Not sure I'd like that anyway.
Correct - and you need to lock it down way more than that. Also I can't
see Red Hat directly signing third party binary blobs. If it does that it
implicitly believes they are lawful and also acquires some liability for
them in they malfuction.
That's a good point, but a little disclaimer would do, wouldn't it? I
mean even today Red Hat shouldn't explicitly support them when it comes
to security. I hope they don't.
But you're right, it would seem weird to sign a blob and drop all
responsibility for it at the same time. I guess there's no use in
secure boot if you execute software you don't trust anyway, so users of
third-party binary blobs probably would naturally disable secure boot.
It will be up to the Fedora Board to stop Red Hat corrupting the goals of
the Fedora project in this way - or if they won't for people who dislike
it to dump Fedora - particularly package maintainers.
That would be, well, extreme. Say if legally OEMs are bound to empower
the user to manage the keys in the firmware, would you still advocate
against the use of the technology?
I mean, right now there's no real issue, OEMs will most certainly
include *at least* the keys for the operating systems they pre-install,
and that includes Red Hat (if not then there's something terribly wrong
with the OEMs' common sense). With a law that states that you must be
able to manage your keys, I believe freedom is untouched. I don't think
any hardware vendor stated they would retract that freedom from users.
Now, users who buy machines with Windows pre-installed should expect
their firmware to include Microsoft's key, and should be aware that they
can add theirs legally. If they don't want to use Windows and don't
want the trouble of setting up keys they should either:
(a) Buy from an OEM which builds machines with their OS of choice
pre-installed, including a secure boot key for it,
(b) Ask an OEM for a machine without any OS (if you install the OS
yourself then you should be responsible for installing the key as well),
(c) Fight an OEM which pre-installs Windows to add a new key, possibly a
set of keys from unbiased trust brokers that can distribute certificates
(bootloader shims) to your OS of choice to make it more realistic.
Now that seems a little harsh for OEMs, but given Windows little
monopoly*, I think everyone is OK with that - there is famously good
precedent with users who got their money back on the license for the
pre-installed Windows copies they got with their computers (even though
their arguably knew that it was explicitly bundled as one product), so
I'm pretty sure we'll make it work this time too since the situation is
even more extreme.
* We can justify it by stating how hard solutions (a) and (b) actually
are, but these kinds of OEMs do exist. They're just too rare.
--
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
