Recent Features
| |||||||||||||
UEFI secure boot kernel restrictionsUEFI secure boot kernel restrictionsPosted Nov 8, 2012 13:16 UTC (Thu) by Trou.fr (subscriber, #26289)Parent article: UEFI secure boot kernel restrictions
I find it weird that all the discussion is going around Microsoft. Secure boot can be a very cool thing to have even in a pure-Linux world : making sure even root cannot compromise the kernel (as in executing arbitrary code using features) is a good security property.
Sure, there is a lot of work required to reach such a goal and kernel vulnerabilities will still exists (ah no, sorry, bugs...) but seccomp-bpf and others mechanisms are here to help. So why not focus on the benefits and stop refering to Windows all the time ?
(Log in to post comments)
UEFI secure boot kernel restrictions Posted Nov 8, 2012 13:54 UTC (Thu) by pjones (subscriber, #31722) [Link] The discussion often involves Windows simply because the Windows 8 logo certification rules are the carrot that's forcing us to move forward on this. You're right that there are numerous benefits, and we're trying to take advantage of them - see this blog post for example.We're not myopically focusing on MS and Windows, but since they are the de facto CA in charge of revocation, we do need to make sure that they are satisfied that our implementation isn't a danger to Windows security as well.
UEFI secure boot kernel restrictions Posted Nov 8, 2012 13:54 UTC (Thu) by etienne (subscriber, #25256) [Link]
> making sure even root cannot compromise the kernel
Shall root be able to modify the restore image, so that at least root can check that this modified image is not restored because the "boot time protections" works?
UEFI secure boot kernel restrictions Posted Nov 8, 2012 17:49 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
> Shall root be able to modify the restore image, so that at least root can check that this modified image is not restored because the "boot time protections" works?
>If not, how are you proposing to test things? Create a super-root?
If you needed to modify a restore image, or kernel, or bootloader, you would need to disable the security mechanism. (In a dream world, by a hardware switch, but more likely through some BIOS setting.)
Presumably you'd need to do such dramatic things only infrequently, so the security would be worth the inconvenience.
UEFI secure boot kernel restrictions Posted Nov 9, 2012 7:54 UTC (Fri) by ekj (guest, #1524) [Link]
But if that's all, then what is the benefit of this scheme over simply having a small area of storage that has a hardware-read-only switch, and booting from that ?
SD-cards already have hardware-write-protect switches on them, why not just put your kernel there, and set the bios to boot from the SD-card ?
UEFI secure boot kernel restrictions Posted Nov 9, 2012 12:05 UTC (Fri) by anselm (subscriber, #2796) [Link] AFAIK the switch on an SD card doesn't actually physically prevent writing to the card; if engaged it's really more like a suggestion to the kernel to not allow writing to the card, so it wouldn't gain you additional security.
UEFI secure boot kernel restrictions Posted Nov 9, 2012 12:28 UTC (Fri) by ekj (guest, #1524) [Link]
Yeah okay, in that case secure boot is as useful as making a sd-card where the write-protect physical switch actually physically prevents writing to the card. I can't imagine that is difficult to do.
No changes to hardware or software beyond the SD-card itself needed.
So what is the point of secure boot ? Why make something so simple (and so useless) so complicated ? What's the point of the crypto and the checksums and all the mumble-jumble ?
UEFI secure boot kernel restrictions Posted Nov 9, 2012 15:45 UTC (Fri) by apoelstra (subscriber, #75205) [Link]
> AFAIK the switch on an SD card doesn't actually physically prevent writing to the card; if engaged it's really more like a suggestion to the kernel to not allow writing to the card, so it wouldn't gain you additional security.
This is correct, unfortunately. I don't know of any consumer media with hardware write protection (other than compact discs, which can be written only once..).
UEFI secure boot kernel restrictions Posted Nov 9, 2012 23:45 UTC (Fri) by nix (subscriber, #2304) [Link]
Floppy disks!
(You didn't say the consumer media couldn't be decades obsolete...)
UEFI secure boot kernel restrictions Posted Nov 10, 2012 1:56 UTC (Sat) by ABCD (subscriber, #53650) [Link]
There are USB thumb drives out there with write-protect switches that (at least supposedly) prevent the computer from writing to the drive. I don't know what would happen if the OS decided to ignore the write-protect switch and write anyway, though.
UEFI secure boot kernel restrictions Posted Nov 10, 2012 0:32 UTC (Sat) by bjencks (subscriber, #80303) [Link]
This allows you to have a trusted source of updates, and easily install new kernels signed by that source without having to jump through the physical presence proof hoops every time.
UEFI secure boot kernel restrictions Posted Nov 10, 2012 1:36 UTC (Sat) by hummassa (subscriber, #307) [Link]
IOW: trust Microsoft, they know what they're doing.
HAAHAHAHAHAHAHA
UEFI secure boot kernel restrictions Posted Nov 11, 2012 20:50 UTC (Sun) by bjencks (subscriber, #80303) [Link]
I was actually thinking of trusting Red Hat or Canonical, or maybe (hypothetically) my own internal trust anchor installed in my desktop or server fleet.
And if you do use Windows (which several hundred million people do), trusting Microsoft is pretty sensible.
UEFI secure boot kernel restrictions Posted Nov 8, 2012 15:10 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I too find it weird, is there something going on behind the scenes that I'm not aware of that would make sense? As far as I can see our obligations for microsoft end at the shim, making sure it can't transparently load unsigned or modified code and interjected into the boot process by malware. As far as I can see that obligation has been met so there is nothing more to discuss with Microsoft.
|
|||||||||||||