On 06/01/2012 02:33 PM, Sam Varshavchik wrote:
Because that makes the entire concept of a trusted boot, into a trusted
operating system, moot.
They are not that dumb.
This will enable a piece of PC hardware to boot an operating system,
then run virus code that boots Windows' bootloader, infecting it, and
bypassing the protection benefits that a trusted bootloader chain
allegedly offers.
We agree on that. You're just inverting cause and effect here.
At some point, they have to trust the people developing the software,
and not the software itself. In essence, the shim is like a
certificate (since it's signed by Fedora implicitly via the package
management system).
If the shim enables anyone to execute any code they wish, "on bare
metal", it makes the entire concept of trusted boot completely and
totally moot.
Not anyone, just Fedora. If Fedora starts to fuck up and many Windows
users report being infected, and it turns out that hackers are using
vulnerable Fedora kernels to host malware and chainload to Windows, then
they will blacklist the shim. Since Fedora doesn't want that, the
kernel maintainers, the boot loader maintainers, and the shim
maintainers will make sure that nothing is vulnerable on their end, and
keep the key secure.
If Windows is as good as it pretends to be, it would also blacklist any
boot loader shim it signed if attacks were reported on other OSes as
well and if the shim's owners are not willing to address the issues /
aren't able to / disappear. But yeah, it's doubtful, which is why we
need unbiased trust brokers.
Sure, I can sign it. Except that Fedora will refuse to run it, because
it's not signed by their key.
And, if there's a process by which my own signing key acquires the
magical pixie dust, that does not involve, in any way whatsoever, any
outside party giving their stamp of approval, that blows the entire boot
loader trust chain wide open.
Yes there is a process, indeed it doesn't require any third-party, and
no it doesn't blow anything up. Managing the keys will be done via a
trusted UEFI interface, much like the BIOS SETUP interfaces we have
today, at boot time. An attacker would need physical access to the
machine, and a password for the key store (and possibly even to access
this interface).
This is the pie in the sky.
This part, is not going to happen. Microsoft will make sure of that.
Another bet? As Alan Cox said, the public outrage if it doesn't happen
will be immense, and even without it there probably will be regulations.
There is precedent for far less than what's happening right now, and
for once we can use the governments to do something good. Just be sure
to be heard (but again, I don't think that's gonna be a problem, people
are already boiling up).
You should, perhaps, spend a few minutes actually thinking it logically
through.
I'm normally the paranoid one in the back, so don't worry I had. Maybe
I have too much faith in our regulators and the people to voice their
concerns, but I'm not going to start talking like it's the end even if
I'm wrong.
Nothing is lost yet, and awareness is raising even before the release of
the technology. I know the fight isn't won yet either, but if everyone
does its part we won't even have to lift a fist, and judging by what
Microsoft is doing offering $100 signatures via Verisign (which isn't
very expansive for one-time deals targeted at OS developers), I think
they don't want to fight. They could just leave it be, use their OEM
contacts for themselves, and tell the world other OS developers just
have to get their own deals. But they don't, probably because they've
been screwed for that kind of thing in the past. Monopoly isn't legal
everywhere.
If Microsoft will sign the key that enables loading a free and open
operating system, this will defeat their own trust boost chain, by
side-stepping it.
Which is why they won't.
They will only sign a bootloader that loads a closed OS kernel. Fedora
will never get a signed bootloader, this is for RHEL.
[Already covered that]
Now, from all the reading I've done on the subject, the only thing I
found was a kill switch that OEMs must install to completely disable
trusted bootloading.
Hmm I get a lot of noise from Windows 8's killswitch articles. Care to
share for reference? If that's the story, that's still alarming, but I
don't see how firmwares would be able to receive revocations by themselves.
If they do somehow, then that's a problem and is unacceptable (unwanted
traffic). If they don't, then fine, just let your trusty OS either
ignore them as noise packets or treat them as cool alerts that your
machine is infected. Typically the OS would have to poll for the
revocations anyway (because of the many users behind NATs and firewalls
defaulting to blocking all inbounds), so Linux can always decide what to do.
I'm going to throw in another 1,000 quatloos on a different bet.
Microsoft will also require OEM's boot firmware to be signed by
Microsoft's key, in order for a Microsoft OS to boot off it. Otherwise,
the user will be greeted with a nicely-rendered message that their
hardware is incompatible.
You're going meta. Who's gonna check the integrity of the firmware?
Can you read the bits off your RAM modules? ;)
So um, can I take that bet too or?
--
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
