Posted Sep 13, 2012 19:10 UTC (Thu) by iabervon (subscriber, #722)
Parent article: LSS: Secure Boot
It seems to me that, if a user can install their own key in the shim, they could run all sorts of malware, like Windows 8 (once Windows 9 comes out), simply by signing it. So the assumption has to be that, if the user has put their key in the shim, the shim is off the hook as far as anything that further that gets run is concerned, so long as it is, in fact, signed by the user's key. As such, all of the kernel changes aren't actually important for Secure Boot itself, but rather that, if you buy Secure Boot's premise and want to enforce those policies, you'll want to have a kernel that doesn't violate them, and you probably want a configuration option that keeps you from accidentally enabling something that isn't trying to enforce them.
Posted Sep 13, 2012 19:58 UTC (Thu) by mjg59 (subscriber, #23239)
[Link]
How would you accidentally enrol a key?
LSS: Secure Boot
Posted Sep 13, 2012 21:00 UTC (Thu) by iabervon (subscriber, #722)
[Link]
You wouldn't accidentally enroll a key, but Microsoft might not like what you signed and were able to boot using a key you'd enrolled. The existence of a shim like this means that it will be possible to use Windows versions on Secure Boot hardware after Microsoft wants to EOL them. From the point of view of the CA evaluating the trustworthiness of the shim, there's not really any difference between a user signing a kexec-enabled kernel and using it to run Windows XP and a user signing Windows XP and booting it from the shim.
LSS: Secure Boot
Posted Sep 13, 2012 21:06 UTC (Thu) by mjg59 (subscriber, #23239)
[Link]
It's a Microsoft requirement that a physically present end-user be able to enrol arbitrary keys, so they're not going to object.
LSS: Secure Boot
Posted Sep 16, 2012 15:45 UTC (Sun) by mathstuf (subscriber, #69389)
[Link]