Re: [opensuse-factory] Secure Boot for openSUSE - a proposal
plain text this time
On Fri, Aug 10, 2012 at 9:08 AM, Greg Freemyer
On Fri, Aug 10, 2012 at 6:40 AM, Andreas Jaeger
wrote: As a followup to discussions on opensuse-project and here on opensuse-factory about secure boot, here's a proposal:
Vojtech Pavlik and Olaf Kirch have written three blog posts explaing SUSE's approach to secure boot:
http://www.suse.com/blogs/uefi-secure-boot-overview/ http://www.suse.com/blogs/uefi-secure-boot-plan/ http://www.suse.com/blogs/uefi-secure-boot-details/
They basically propose to enhance Fedora's solution with a way that Matthew Garrett - the Red Hat developer working on this - summarized at http://mjg59.dreamwidth.org/15818.html with
"There's a post here describing SUSE's approach to implementing Secure Boot support. In summary, it's pretty similar to the approach we're taking in Fedora - a first stage shim loader is signed with a key in db, it loads a second stage bootloader (grub 2) that's signed with a key that's in shim, the second stage bootloader loads a signed kernel. The main difference between the approaches is the use of a separate key database in shim, whereas we are currently planning on using a built-in key and the contents of the firmware key database. ... "It's a wonderfully elegant solution. We've been planning on supporting user keys by trusting the contents of db, and the Windows 8 requirements specify that it must be possible for a physically present user to add keys to it. The problem there has been that different vendors offer different UI for this, in some cases even requiring that the keys be in different formats. Using an entirely separate database and offering support for enrolment in the early boot phase means that the UI and formats can be kept consistent, which makes it much easier for users to manage their own keys.
I suspect that we'll adopt this approach in Fedora as well - it doesn't allow anything that our solution wouldn't have, but it does make some of them easier. Full marks to SUSE on this."
What shall we do for openSUSE? Vojtech and Olaf make the proposal to use the proposed SUSE solution for openSUSE as well.
Do you see any problems or enhancements for the proposal?
I would love to tell them the openSUSE community looks forward to the SUSE implementation for the next release (12.3). May I?
Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I think there are 2 questions. 1) Is the SUSE approach with a standalone database of MOKs necessary for openSUSE. I argue it is. 2) Is the functionality defined for using that database of MOKs sufficient for openSUSE needs. I argue it is not. The prime examples relate to OBS and SuseStudio. If each of those is provisioned with a unique MOK key and the validation key is made well known, then the SUSE approach will I'm sure include a relatively simple way for a user to install the validation key into the MOK database. But what if OBS and/or SuseStudio is used to create a kernel that gets designated as malware. I would like to see the openSUSE solution provide a way to black ball that kernel. === Thus I think openSUSE should use the SUSE UEFI approach as a foundation, but should add a black ball mechanism to it somehow. I admit that I don't have a methodology in mind to accomplish that. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Greg, On Friday 10 August 2012 15:15:15 Greg Freemyer wrote:
2) Is the functionality defined for using that database of MOKs sufficient for openSUSE needs.
I argue it is not.
The prime examples relate to OBS and SuseStudio. If each of those is provisioned with a unique MOK key and the validation key is made well known, then the SUSE approach will I'm sure include a relatively simple way for a user to install the validation key into the MOK database.
SuseStudio doesn't need keys; it doesn't build its own kernels or grub packages - it just pulls them from "somewhere" and puts them into the image. And just like we don't sign packages in any random build service project with the openSUSE key, we wouldn't be signing kernels from random OBS projects - only the openSUSE kernel would receive this signature. So in order to build a "malware" kernel and get it signed, you would have to submit that change to the openSUSE project and conceal it sufficiently to pass the review at package check-in.
But what if OBS and/or SuseStudio is used to create a kernel that gets designated as malware. I would like to see the openSUSE solution provide a way to black ball that kernel.
That's a good point. The only alternative would be to revoke the key in that case; and that's not attractive either. Olaf -- Neo didn't bring down the Matrix. SOA did. (soafacts.com) -------------------------------------------- Olaf Kirch - Director SUSE Linux Enterprise; R&D (okir@suse.com) SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Aug 10, 2012 at 03:45:38PM +0200, Olaf Kirch wrote:
SuseStudio doesn't need keys; it doesn't build its own kernels or grub packages - it just pulls them from "somewhere" and puts them into the image.
And just like we don't sign packages in any random build service project with the openSUSE key, we wouldn't be signing kernels from random OBS projects - only the openSUSE kernel would receive this signature.
So in order to build a "malware" kernel and get it signed, you would have to submit that change to the openSUSE project and conceal it sufficiently to pass the review at package check-in.
But what if OBS and/or SuseStudio is used to create a kernel that gets designated as malware. I would like to see the openSUSE solution provide a way to black ball that kernel.
That's a good point. The only alternative would be to revoke the key in that case; and that's not attractive either.
Revocation of keys is something we'll need to discuss. It's not a large problem with keys in the MOK database, but it is a problem for the default SUSE key embedded in the shim. On the other hand, this is a well solved problem, using authenticated UEFI variables, so we may just well use that. The only drawback is that it makes the solution more complex. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Greg Freemyer
-
Olaf Kirch
-
Vojtech Pavlik