KMP for openSUSE Leap on OBS may need to include openSUSE key
Hi all, In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE. For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel. Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key. Any idea? Thanks a lot! Joey Lee
On Tue, Jan 19, 2021 at 05:36:34PM +0800, Joey Lee wrote:
Hi all,
In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE.
For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel. ^^^^^^^^^^^^ Leap's public key
Sorry for my typo.
Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key.
Any idea?
Regards Joey Lee
On Tue, 19 Jan 2021 10:36:34 +0100, joeyli wrote:
Hi all,
In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE.
For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel.
Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key.
Any idea?
This has been discussed in the past, too, and an alternative is to embed the Leap cert in SLE kernel. It'd be the most user-friendly way, as user doesn't has to do anything new. And since it's a public key, it's fine to put the key even statically in the git branch. The kernel spec file has already an infrastructure to embed other keys. Of course, the obvious question is whether SUSE side accepts / prefers this. Other than that, the deployment via MOK would be the most feasible option, I guess, too. Maybe we can install a certain package containing the vert that is selected by install pattern or such. Or KMP may have dependency on a cert package as well. The biggest drawback of MOK approach is that it's quite non-intuitive; the dialog at shim is cryptic and novice users won't understand what to do. OTOH, we don't want (must not?) the unattended deployment. For avoiding misunderstanding, can YaST show the dialog at the end of the installer procedure, explaining what user has to do at the next step at the boot (at best with some pictures)? Or would it be just annoying / useless for most users? thanks, Takashi
Hi Takashi, On Tue, Jan 19, 2021 at 12:20:19PM +0100, Takashi Iwai wrote:
On Tue, 19 Jan 2021 10:36:34 +0100, joeyli wrote:
Hi all,
In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE.
For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel.
Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key.
Any idea?
This has been discussed in the past, too, and an alternative is to embed the Leap cert in SLE kernel. It'd be the most user-friendly way, as user doesn't has to do anything new. And since it's a public key, it's fine to put the key even statically in the git branch. The kernel spec file has already an infrastructure to embed other keys. Of course, the obvious question is whether SUSE side accepts / prefers this.
Yes, this is the most user-friendly way. And this approach is also benefit to no-EFI/MOK machines. As you said, SUSE side should accepts. I believe that SLE product manager and security team should accept at least. In a conversation in labs conf, I raised an idea to embed PTF or PLDP cert to SLE kernel. But a SLE partner disagrees because end user should awares and accepts which key they will trust. If Leap key be embedded in SLE kernel, it means that SLE user also trusts Leap key by default. To SLE user, this is a unnecessary risk.
Other than that, the deployment via MOK would be the most feasible option, I guess, too. Maybe we can install a certain package containing the vert that is selected by install pattern or such. Or KMP may have dependency on a cert package as well.
Yes.
The biggest drawback of MOK approach is that it's quite non-intuitive; the dialog at shim is cryptic and novice users won't understand what to do. OTOH, we don't want (must not?) the unattended deployment.
For avoiding misunderstanding, can YaST show the dialog at the end of the installer procedure, explaining what user has to do at the next step at the boot (at best with some pictures)? Or would it be just annoying / useless for most users?
I am not sure how many effort on YaST team, but I think that's a good idea. Comparing with EFI text UI, a YaST step with picture can bring more detail to user. Thanks a lot! Joey Lee
On Wed, Jan 20, 2021 at 04:27:00PM +0800, joeyli wrote:
Hi Takashi,
On Tue, Jan 19, 2021 at 12:20:19PM +0100, Takashi Iwai wrote:
On Tue, 19 Jan 2021 10:36:34 +0100, joeyli wrote:
Hi all,
In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE.
For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel.
Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key.
Any idea?
This has been discussed in the past, too, and an alternative is to embed the Leap cert in SLE kernel. It'd be the most user-friendly way, as user doesn't has to do anything new. And since it's a public key, it's fine to put the key even statically in the git branch. The kernel spec file has already an infrastructure to embed other keys. Of course, the obvious question is whether SUSE side accepts / prefers this.
Yes, this is the most user-friendly way. And this approach is also benefit to no-EFI/MOK machines.
As you said, SUSE side should accepts. I believe that SLE product manager and security team should accept at least.
In a conversation in labs conf, I raised an idea to embed PTF or PLDP cert to SLE kernel. But a SLE partner disagrees because end user should awares and accepts which key they will trust.
If Leap key be embedded in SLE kernel, it means that SLE user also trusts Leap key by default. To SLE user, this is a unnecessary risk.
No, Security does NOT accept embedding openSUSE certs by default in SLE kernels. This would break our primary security certification Common Criteria and also other assurance, especially as also non-SUSE employees are now able to work directly on Leap. Some other form of enrollment needs to be considered or e.g. that all KMPs are built in SLES. Ciao, Marcus
On Wed, 20 Jan 2021 09:32:06 +0100, Marcus Meissner wrote:
On Wed, Jan 20, 2021 at 04:27:00PM +0800, joeyli wrote:
Hi Takashi,
On Tue, Jan 19, 2021 at 12:20:19PM +0100, Takashi Iwai wrote:
On Tue, 19 Jan 2021 10:36:34 +0100, joeyli wrote:
Hi all,
In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE.
For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel.
Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key.
Any idea?
This has been discussed in the past, too, and an alternative is to embed the Leap cert in SLE kernel. It'd be the most user-friendly way, as user doesn't has to do anything new. And since it's a public key, it's fine to put the key even statically in the git branch. The kernel spec file has already an infrastructure to embed other keys. Of course, the obvious question is whether SUSE side accepts / prefers this.
Yes, this is the most user-friendly way. And this approach is also benefit to no-EFI/MOK machines.
As you said, SUSE side should accepts. I believe that SLE product manager and security team should accept at least.
In a conversation in labs conf, I raised an idea to embed PTF or PLDP cert to SLE kernel. But a SLE partner disagrees because end user should awares and accepts which key they will trust.
If Leap key be embedded in SLE kernel, it means that SLE user also trusts Leap key by default. To SLE user, this is a unnecessary risk.
No, Security does NOT accept embedding openSUSE certs by default in SLE kernels.
This would break our primary security certification Common Criteria and also other assurance, especially as also non-SUSE employees are now able to work directly on Leap.
Thank you for clarification. It's more or less expected, but we had to discuss this publicly once, in anyway.
Some other form of enrollment needs to be considered or e.g. that all KMPs are built in SLES.
Hmm, I don't think it's a good idea. It doesn't scale, and would just bring more burden to both SUSE and openSUSE contributors. The MOK enrollment itself is an easy action, and once after we have some automatic cert installation via a package chain, the only remaining problem is the UI, IMO. We need to improve the dialog in shim itself and/or provide more guidance at installation. thanks, Takashi
On Wed, Jan 20, 2021 at 10:22:47AM +0100, Takashi Iwai wrote:
On Wed, 20 Jan 2021 09:32:06 +0100, Marcus Meissner wrote:
On Wed, Jan 20, 2021 at 04:27:00PM +0800, joeyli wrote:
Hi Takashi,
On Tue, Jan 19, 2021 at 12:20:19PM +0100, Takashi Iwai wrote:
On Tue, 19 Jan 2021 10:36:34 +0100, joeyli wrote:
Hi all,
In a discussion with Max Lin, he has mentioned that the KMP on OBS (e.g. virtual box) can not be loaded by closing-gap kernel. That makes sense because the kernel binary is from SLE.
For those KMP from SLE repo, the driver be signed by SLE key. It doesn't have problem to work with closing-gap kernel. But for those drivers from openSUSE Leap repo, they are signed by openSUSE key. The closing-gap kernel doesn't embed Leap kernel.
Maybe the openSUSE Leap pubic key must be included in all KMPs in Leap repo? or at least all KMPs in Leap repo must depend on a openSUSE Leap sign key RPM. After KMP be installed and reboot, user can follow MOK manager's UI to enroll openSUSE Leap key.
Any idea?
This has been discussed in the past, too, and an alternative is to embed the Leap cert in SLE kernel. It'd be the most user-friendly way, as user doesn't has to do anything new. And since it's a public key, it's fine to put the key even statically in the git branch. The kernel spec file has already an infrastructure to embed other keys. Of course, the obvious question is whether SUSE side accepts / prefers this.
Yes, this is the most user-friendly way. And this approach is also benefit to no-EFI/MOK machines.
As you said, SUSE side should accepts. I believe that SLE product manager and security team should accept at least.
In a conversation in labs conf, I raised an idea to embed PTF or PLDP cert to SLE kernel. But a SLE partner disagrees because end user should awares and accepts which key they will trust.
If Leap key be embedded in SLE kernel, it means that SLE user also trusts Leap key by default. To SLE user, this is a unnecessary risk.
No, Security does NOT accept embedding openSUSE certs by default in SLE kernels.
This would break our primary security certification Common Criteria and also other assurance, especially as also non-SUSE employees are now able to work directly on Leap.
Thank you for clarification. It's more or less expected, but we had to discuss this publicly once, in anyway.
Some other form of enrollment needs to be considered or e.g. that all KMPs are built in SLES.
Hmm, I don't think it's a good idea. It doesn't scale, and would just bring more burden to both SUSE and openSUSE contributors.
The MOK enrollment itself is an easy action, and once after we have some automatic cert installation via a package chain, the only
We will submit a certificate package for enrolling Leap public key to MOK. Maybe the name is opensuse-leap-kmp-key.rpm or something like this. Then all KMPs depend on this key package.
remaining problem is the UI, IMO. We need to improve the dialog in shim itself and/or provide more guidance at installation.
YaST step is a idea. Another idea is that we can try to put a description string when using mokutil, then shim UI shows the description string. e.g. mokutil --root-pw --import public-256.der --desc "openSUSE Leap KMP key" Then shim UI shows "openSUSE Leap KMP key" when guiding user. Thanks Joey Lee
On Fri, 22 Jan 2021 06:05:28 +0100, joeyli wrote:
On Wed, Jan 20, 2021 at 10:22:47AM +0100, Takashi Iwai wrote:
On Wed, 20 Jan 2021 09:32:06 +0100, Marcus Meissner wrote:
Some other form of enrollment needs to be considered or e.g. that all KMPs are built in SLES.
Hmm, I don't think it's a good idea. It doesn't scale, and would just bring more burden to both SUSE and openSUSE contributors.
The MOK enrollment itself is an easy action, and once after we have some automatic cert installation via a package chain, the only
We will submit a certificate package for enrolling Leap public key to MOK. Maybe the name is opensuse-leap-kmp-key.rpm or something like this. Then all KMPs depend on this key package.
The package name may need more consideration, but I think putting the dependency in KMP is no good way (although I myself suggested in the above). Think of building a KMP in a devel project or other wild OBS project: bringing the opensuse-leap-kmp-key makes no sense for such a KMP. Also, imaging that you'd need to promote the Leap package to an official SLE sometime later. The dependency on opensuse-leap-kmp-key is rather harmful. So, IMO, it should be enough to let the cert package install once via patterns. (Or somehow automatically when the secure boot is detected? -- maybe it's too complex and error-prone.)
remaining problem is the UI, IMO. We need to improve the dialog in shim itself and/or provide more guidance at installation.
YaST step is a idea. Another idea is that we can try to put a description string when using mokutil, then shim UI shows the description string. e.g. mokutil --root-pw --import public-256.der --desc "openSUSE Leap KMP key"
Then shim UI shows "openSUSE Leap KMP key" when guiding user.
Well, giving a more descriptive name is certainly an improvement, and it'd be a nice change, but the basic problem remains: who would understand what next to do if you look at a dialog showing "openSUSE Leap KMP key"? :) The MOK enrollment procedure itself is non-intuitive, and this must be guided better for novice users. (Admittedly, the procedure is confusing even for experienced users!) thanks, Takashi
Hi all, On Fri, Jan 22, 2021 at 10:15:23AM +0100, Takashi Iwai wrote:
On Fri, 22 Jan 2021 06:05:28 +0100, joeyli wrote:
On Wed, Jan 20, 2021 at 10:22:47AM +0100, Takashi Iwai wrote:
On Wed, 20 Jan 2021 09:32:06 +0100, Marcus Meissner wrote:
Some other form of enrollment needs to be considered or e.g. that all KMPs are built in SLES.
Hmm, I don't think it's a good idea. It doesn't scale, and would just bring more burden to both SUSE and openSUSE contributors.
The MOK enrollment itself is an easy action, and once after we have some automatic cert installation via a package chain, the only
We will submit a certificate package for enrolling Leap public key to MOK. Maybe the name is opensuse-leap-kmp-key.rpm or something like this. Then all KMPs depend on this key package.
The package name may need more consideration, but I think putting the dependency in KMP is no good way (although I myself suggested in the above). Think of building a KMP in a devel project or other wild OBS project: bringing the opensuse-leap-kmp-key makes no sense for such a KMP. Also, imaging that you'd need to promote the Leap package to an official SLE sometime later. The dependency on opensuse-leap-kmp-key is rather harmful.
So, IMO, it should be enough to let the cert package install once via patterns. (Or somehow automatically when the secure boot is detected? -- maybe it's too complex and error-prone.)
I found that I can not create a openSUSE Jira against this requirement. So I still create a bsc#1182641 to note this change. Thanks Joey Lee
participants (3)
-
joeyli -
Marcus Meissner -
Takashi Iwai