LSS: Secure Boot
LSS: Secure Boot
Posted Sep 21, 2012 4:11 UTC (Fri) by cyanit (guest, #86671)Parent article: LSS: Secure Boot
As far as I can tell, you can just run Windows in a fullscreen qemu instance with full access to the hard disk, and the user will think it's the legitimate version of Windows...
Is access to Windows partitions on disk somehow blocked by the kernel?
If so, why not just have the BIOS and SATA controller cooperate to do that (i.e. irrevocably disable access to a disk range until reboot), thus allowing arbitrary software to run without issues?
Then, what's the point of having all this for Linux, when root can just add something in /etc/init.d that takes over the system silently, and any user can do the same using autostart?
Also, do you REALLY expect all Linux code (esp. in drivers) to not contain a ton of security holes exploitable by a root user, considering this was never thought to be a problem?!?
Have you spent the millions (or billions) of man hours needed to do a thorough review of the Linux code and mathematically prove that there are no holes?
Is this all just for show because otherwise Microsoft wouldn't sign the bootloader?
Because the way it is described, it provides no real security whatsoever, at all.
Posted Sep 21, 2012 4:49 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Sep 21, 2012 5:18 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (3 responses)
Posted Sep 21, 2012 5:24 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Sep 21, 2012 13:18 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
Posted Sep 21, 2012 23:08 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Sep 21, 2012 5:13 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (22 responses)
The threat model that Secure Boot is intended to help thwart is fairly simple, it makes no claims about OS security or vulnerabilities in the kernel or rootkits in the running system, it's only claim is that you can boot into the kernel without the possibility of a rootkit already having been planted in the firmware or bootloader. The rest is whatever scheme you dream up for the OS.
What people are using this tool for is to implement integrity checking in the kenrel that can't be easily and persistently subverted. It didn't make a lot of sense to invest heavily in integrity checking before when the underlying layers were so easy to subvert. Since you can't subvert any of the persistant storage without breaking the signatures then your malware has to be started using normal OS means and you can use standard OS tools and anti-malware to detect and clean it out before it runs. The anti-malware can have its own integrity checking on updates so that a compromised system can be cleaned just by rebooting it. The malware can't subvert the anti-malware but it can potentially block updates although this can be easily detected.
The concern with the security of the boot loader is that there are going to be a number of signed boot loaders from various vendors out in the wild that will all be trusted by every machine by default. If those boot loaders can be configured to run arbitrary code then any one of them could be used as a shim to load malware before the kernel and anti-malware has a chance of loading which drives a particular design where the boot loader does some sort of authorization checking as to what kernel image it is booting.
None of this protects an OS which is running in a VM from the hypervisor although it still has the same protections from malware inside the OS. As far as I know the threat model of Secure Boot can't handle the case where you Secure Boot into a legitimate bootloader and legitimate kernel which then boots the OS as a guest in a VM. It'd be an interesting proof of concept to see how one would modify a compromised running system to include booting a hypervisor without breaking the system in some way. Maybe someone who knows more than me can help answer this question, mjg59?
Posted Sep 21, 2012 14:56 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (21 responses)
Posted Sep 21, 2012 15:14 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
This is just a fancier way to make the statement "Linux rulez and MS droolz" which isn't a useful statement.
Posted Sep 21, 2012 18:33 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (19 responses)
Posted Sep 21, 2012 23:12 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Shame if it decides to blacklist the Fedora key. All of a sudden every single secure-booted instance of one of its competitors that is dual-booted with Windows has stopped working! And there is, as far as I can see, no easy way to recover. (Maybe Fedora could make a boot CD image available that would update the bootloader, splash it in big letters all over fedoraproject.org, and hope that everyone affected thinks to look there. *shiver*.)
(I have 'secure boot' on this new system of mine. I have, of course, turned it off. The last thing I need is a way of rendering my system magically unbootable. I have enough of those as it is!)
Posted Sep 22, 2012 22:14 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Sep 23, 2012 14:22 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link]
Posted Sep 22, 2012 15:55 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (15 responses)
Posted Sep 22, 2012 16:05 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (14 responses)
No.
Posted Sep 23, 2012 21:21 UTC (Sun)
by nix (subscriber, #2304)
[Link] (13 responses)
Posted Sep 23, 2012 21:37 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (4 responses)
Posted Sep 23, 2012 22:32 UTC (Sun)
by nix (subscriber, #2304)
[Link] (3 responses)
(Remember, the attackers only have to be lucky once.)
Posted Sep 23, 2012 22:46 UTC (Sun)
by hummassa (subscriber, #307)
[Link] (2 responses)
People imagining these schemes forget that crypto keys are leaked and recovered all the time IRL. And that if you are not a government, you can always use the wrench method. https://xkcd.com/538/
Posted Sep 24, 2012 3:50 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Sep 24, 2012 8:41 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Sep 24, 2012 0:36 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Sep 24, 2012 8:41 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Sep 24, 2012 9:07 UTC (Mon)
by hummassa (subscriber, #307)
[Link]
No, that's not "part of that". s/part of //. The security process stops at the easier way to the threat to get what he wants. Threats can and will leak keys from Microsoft (remember NT4/XP source code?) if that's the easier way of signing device drivers. As vendor keys are currently easier to get hold of, and they do the job just fine (because there are a lot of vendors and IIRC once the keys were revoked another version of Stuxnet signed with another key popped up) the threats don't need to go after MS.
Security = you don't have to outrun the beast, you have to outrun the friend beside you.
Posted Sep 24, 2012 1:04 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Sep 24, 2012 8:42 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Sep 24, 2012 18:24 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Sep 25, 2012 8:20 UTC (Tue)
by alonz (subscriber, #815)
[Link] (1 responses)
Have you, perhaps, seen this? Or this (as applied to HSM's, considering the incompetence apparent from the first link)? I don't think HSM's are as magic as people expect them to be…
Posted Sep 25, 2012 8:29 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
LSS: Secure Boot
Yeah, that sure is reassuring. </sarcasm>LSS: Secure Boot
LSS: Secure Boot