| Message ID | 20210819002109.534600-1-eric.snowberg@oracle.com |
|---|---|
| Headers | show |
| Series | Enroll kernel keys thru MOK | expand |
On Thu, 2021-08-19 at 09:10 -0400, Mimi Zohar wrote: > On Thu, 2021-08-19 at 14:38 +0300, Jarkko Sakkinen wrote: > > On Wed, 2021-08-18 at 20:20 -0400, Eric Snowberg wrote: > > > Many UEFI Linux distributions boot using shim. The UEFI shim provides > > > what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure > > > Boot DB and MOK keys to validate the next step in the boot chain. The > > > MOK facility can be used to import user generated keys. These keys can > > > be used to sign an end-user development kernel build. When Linux boots, > > > pre-boot keys (both UEFI Secure Boot DB and MOK keys) get loaded in the > > > Linux .platform keyring. > > > > > > Currently, pre-boot keys are not trusted within the Linux trust boundary > > > [1]. These platform keys can only be used for kexec. If an end-user > > > wants to use their own key within the Linux trust boundary, they must > > > either compile it into the kernel themselves or use the insert-sys-cert > > > script. Both options present a problem. Many end-users do not want to > > > compile their own kernels. With the insert-sys-cert option, there are > > > missing upstream changes [2]. Also, with the insert-sys-cert option, > > > the end-user must re-sign their kernel again with their own key, and > > > then insert that key into the MOK db. Another problem with > > > insert-sys-cert is that only a single key can be inserted into a > > > compressed kernel. > > > > > > Having the ability to insert a key into the Linux trust boundary opens > > > up various possibilities. The end-user can use a pre-built kernel and > > > sign their own kernel modules. It also opens up the ability for an > > > end-user to more easily use digital signature based IMA-appraisal. To > > > get a key into the ima keyring, it must be signed by a key within the > > > Linux trust boundary. > > > > As of today, I can use a prebuilt kernel, crate my own MOK key and sign > > modules. What will be different? > > The UEFI db and MOK keys are being loaded onto the .platform keyring, > which is suppose to be limited to verifying the kexec kernel image > signature. With a downstream patch, kernel modules are being verified > as well. > > Initially Patrick Uiterwijk's "[PATCH 0/3] Load keys from TPM2 NV Index > on IMA keyring" patch set attempted to define a new root of trust based > on a key stored in the TPM. This patch set is similarly attempting to > define a new root of trust based on CA keys stored in the MOK db. > > The purpose of this patch set is to define a new, safe trust source > parallel to the builtin keyring, without relying on a downstream patch. > With the new root of trust, the end user could sign his own kernel > modules, sign third party keys, and load keys onto the IMA keyring, > which can be used for signing the IMA policy and other files. I can, as of today, generate my own mok key and sign my LKM's, and kernel will verify my LKM's. What is different? /Jarkko
On Thu, 2021-08-19 at 09:23 -0600, Eric Snowberg wrote: > > On Aug 19, 2021, at 7:10 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Thu, 2021-08-19 at 14:38 +0300, Jarkko Sakkinen wrote: > > > On Wed, 2021-08-18 at 20:20 -0400, Eric Snowberg wrote: > > > > Downstream Linux distros try to have a single signed kernel for each > > > > architecture. Each end-user may use this kernel in entirely different > > > > ways. Some downstream kernels have chosen to always trust platform keys > > > > within the Linux trust boundary for kernel module signing. These > > > > kernels have no way of using digital signature base IMA appraisal. > > > > > > > > This series introduces a new Linux kernel keyring containing the Machine > > > > Owner Keys (MOK) called .mok. It also adds a new MOK variable to shim. > > > > > > I would name it as ".machine" because it is more "re-usable" name, e.g. > > > could be used for similar things as MOK. ".mok" is a bad name because > > > it binds directly to a single piece of user space software. > > > > Nayna previously said, > > "I believe the underlying source from where CA keys are loaded might vary > > based on the architecture (".mok" is UEFI specific.). The key part is > > that this new keyring should contain only CA keys which can be later > > used to vouch for user keys loaded onto IMA or secondary keyring at > > runtime. It would be good to have a "ca" in the name, like .xxxx-ca, > > where xxxx can be machine, owner, or system. I prefer .system-ca." > > > > The CA keys on the MOK db is simply the first root of trust being > > defined, but other roots of trust are sure to follow. For this reason, > > I agree naming the new keyring "mok" should be avoided. > > As I said previously, I’m open to renaming, I just would like to have an > agreement on the new name before changing everything. The current proposed > names I have heard are “.machine" and ".system-ca". Is there a preference > the maintainers feel is appropriate? If so, please let me know and I’ll > rename it. Thanks. Just ".system" would be good. It's informative enough. /Jarkko
> On Aug 23, 2021, at 11:35 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Thu, 2021-08-19 at 09:10 -0400, Mimi Zohar wrote: >> On Thu, 2021-08-19 at 14:38 +0300, Jarkko Sakkinen wrote: >>> On Wed, 2021-08-18 at 20:20 -0400, Eric Snowberg wrote: >>>> Many UEFI Linux distributions boot using shim. The UEFI shim provides >>>> what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure >>>> Boot DB and MOK keys to validate the next step in the boot chain. The >>>> MOK facility can be used to import user generated keys. These keys can >>>> be used to sign an end-user development kernel build. When Linux boots, >>>> pre-boot keys (both UEFI Secure Boot DB and MOK keys) get loaded in the >>>> Linux .platform keyring. >>>> >>>> Currently, pre-boot keys are not trusted within the Linux trust boundary >>>> [1]. These platform keys can only be used for kexec. If an end-user >>>> wants to use their own key within the Linux trust boundary, they must >>>> either compile it into the kernel themselves or use the insert-sys-cert >>>> script. Both options present a problem. Many end-users do not want to >>>> compile their own kernels. With the insert-sys-cert option, there are >>>> missing upstream changes [2]. Also, with the insert-sys-cert option, >>>> the end-user must re-sign their kernel again with their own key, and >>>> then insert that key into the MOK db. Another problem with >>>> insert-sys-cert is that only a single key can be inserted into a >>>> compressed kernel. >>>> >>>> Having the ability to insert a key into the Linux trust boundary opens >>>> up various possibilities. The end-user can use a pre-built kernel and >>>> sign their own kernel modules. It also opens up the ability for an >>>> end-user to more easily use digital signature based IMA-appraisal. To >>>> get a key into the ima keyring, it must be signed by a key within the >>>> Linux trust boundary. >>> >>> As of today, I can use a prebuilt kernel, crate my own MOK key and sign >>> modules. What will be different? >> >> The UEFI db and MOK keys are being loaded onto the .platform keyring, >> which is suppose to be limited to verifying the kexec kernel image >> signature. With a downstream patch, kernel modules are being verified >> as well. >> >> Initially Patrick Uiterwijk's "[PATCH 0/3] Load keys from TPM2 NV Index >> on IMA keyring" patch set attempted to define a new root of trust based >> on a key stored in the TPM. This patch set is similarly attempting to >> define a new root of trust based on CA keys stored in the MOK db. >> >> The purpose of this patch set is to define a new, safe trust source >> parallel to the builtin keyring, without relying on a downstream patch. >> With the new root of trust, the end user could sign his own kernel >> modules, sign third party keys, and load keys onto the IMA keyring, >> which can be used for signing the IMA policy and other files. > > I can, as of today, generate my own mok key and sign my LKM's, and > kernel will verify my LKM's. > > What is different? Are you sure your kernel doesn’t contain some version of the rejected patch referenced in the cover letter [1]? https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
On Thu, 2021-08-19 at 13:32 -0400, Mimi Zohar wrote: > On Thu, 2021-08-19 at 09:23 -0600, Eric Snowberg wrote: > > > On Aug 19, 2021, at 7:10 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > On Thu, 2021-08-19 at 14:38 +0300, Jarkko Sakkinen wrote: > > > > On Wed, 2021-08-18 at 20:20 -0400, Eric Snowberg wrote: > > > > > Downstream Linux distros try to have a single signed kernel for each > > > > > architecture. Each end-user may use this kernel in entirely different > > > > > ways. Some downstream kernels have chosen to always trust platform keys > > > > > within the Linux trust boundary for kernel module signing. These > > > > > kernels have no way of using digital signature base IMA appraisal. > > > > > > > > > > This series introduces a new Linux kernel keyring containing the Machine > > > > > Owner Keys (MOK) called .mok. It also adds a new MOK variable to shim. > > > > > > > > I would name it as ".machine" because it is more "re-usable" name, e.g. > > > > could be used for similar things as MOK. ".mok" is a bad name because > > > > it binds directly to a single piece of user space software. > > > > > > Nayna previously said, > > > "I believe the underlying source from where CA keys are loaded might vary > > > based on the architecture (".mok" is UEFI specific.). The key part is > > > that this new keyring should contain only CA keys which can be later > > > used to vouch for user keys loaded onto IMA or secondary keyring at > > > runtime. It would be good to have a "ca" in the name, like .xxxx-ca, > > > where xxxx can be machine, owner, or system. I prefer .system-ca." > > > > > > The CA keys on the MOK db is simply the first root of trust being > > > defined, but other roots of trust are sure to follow. For this reason, > > > I agree naming the new keyring "mok" should be avoided. > > > > As I said previously, I’m open to renaming, I just would like to have an > > agreement on the new name before changing everything. The current proposed > > names I have heard are “.machine" and ".system-ca". Is there a preference > > the maintainers feel is appropriate? If so, please let me know and I’ll > > rename it. Thanks. > > > > Jarkko, I think the emphasis should not be on "machine" from Machine > Owner Key (MOK), but on "owner". Whereas Nayna is focusing more on the > "_ca" aspect of the name. Perhaps consider naming it > "system_owner_ca" or something along those lines. What do you gain such overly long identifier? Makes no sense. What is "ca aspect of the name" anyway? /Jarkko
On 8/23/21 1:51 PM, Jarkko Sakkinen wrote: > On Thu, 2021-08-19 at 13:32 -0400, Mimi Zohar wrote: >> On Thu, 2021-08-19 at 09:23 -0600, Eric Snowberg wrote: >>>> On Aug 19, 2021, at 7:10 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>>> >>>> On Thu, 2021-08-19 at 14:38 +0300, Jarkko Sakkinen wrote: >>>>> On Wed, 2021-08-18 at 20:20 -0400, Eric Snowberg wrote: >>>>>> Downstream Linux distros try to have a single signed kernel for each >>>>>> architecture. Each end-user may use this kernel in entirely different >>>>>> ways. Some downstream kernels have chosen to always trust platform keys >>>>>> within the Linux trust boundary for kernel module signing. These >>>>>> kernels have no way of using digital signature base IMA appraisal. >>>>>> >>>>>> This series introduces a new Linux kernel keyring containing the Machine >>>>>> Owner Keys (MOK) called .mok. It also adds a new MOK variable to shim. >>>>> I would name it as ".machine" because it is more "re-usable" name, e.g. >>>>> could be used for similar things as MOK. ".mok" is a bad name because >>>>> it binds directly to a single piece of user space software. >>>> Nayna previously said, >>>> "I believe the underlying source from where CA keys are loaded might vary >>>> based on the architecture (".mok" is UEFI specific.). The key part is >>>> that this new keyring should contain only CA keys which can be later >>>> used to vouch for user keys loaded onto IMA or secondary keyring at >>>> runtime. It would be good to have a "ca" in the name, like .xxxx-ca, >>>> where xxxx can be machine, owner, or system. I prefer .system-ca." >>>> >>>> The CA keys on the MOK db is simply the first root of trust being >>>> defined, but other roots of trust are sure to follow. For this reason, >>>> I agree naming the new keyring "mok" should be avoided. >>> As I said previously, I’m open to renaming, I just would like to have an >>> agreement on the new name before changing everything. The current proposed >>> names I have heard are “.machine" and ".system-ca". Is there a preference >>> the maintainers feel is appropriate? If so, please let me know and I’ll >>> rename it. Thanks. >>> >> Jarkko, I think the emphasis should not be on "machine" from Machine >> Owner Key (MOK), but on "owner". Whereas Nayna is focusing more on the >> "_ca" aspect of the name. Perhaps consider naming it >> "system_owner_ca" or something along those lines. > What do you gain such overly long identifier? Makes no sense. What > is "ca aspect of the name" anyway? As I mentioned previously, the main usage of this new keyring is that it should contain only CA keys which can be later used to vouch for user keys loaded onto secondary or IMA keyring at runtime. Having ca in the name like .xxxx_ca, would make the keyring name self-describing. Since you preferred .system, we can call it .system_ca. Thanks & Regards, - Nayna
> >> Jarkko, I think the emphasis should not be on "machine" from Machine > >> Owner Key (MOK), but on "owner". Whereas Nayna is focusing more on the > >> "_ca" aspect of the name. Perhaps consider naming it > >> "system_owner_ca" or something along those lines. > > What do you gain such overly long identifier? Makes no sense. What > > is "ca aspect of the name" anyway? > > As I mentioned previously, the main usage of this new keyring is that it > should contain only CA keys which can be later used to vouch for user > keys loaded onto secondary or IMA keyring at runtime. Having ca in the > name like .xxxx_ca, would make the keyring name self-describing. Since > you preferred .system, we can call it .system_ca. Sounds good to me. Jarkko? thanks, Mimi
On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote: > > > > Jarkko, I think the emphasis should not be on "machine" from Machine > > > > Owner Key (MOK), but on "owner". Whereas Nayna is focusing more on the > > > > "_ca" aspect of the name. Perhaps consider naming it > > > > "system_owner_ca" or something along those lines. > > > What do you gain such overly long identifier? Makes no sense. What > > > is "ca aspect of the name" anyway? > > > > As I mentioned previously, the main usage of this new keyring is that it > > should contain only CA keys which can be later used to vouch for user > > keys loaded onto secondary or IMA keyring at runtime. Having ca in the > > name like .xxxx_ca, would make the keyring name self-describing. Since > > you preferred .system, we can call it .system_ca. > > Sounds good to me. Jarkko? > > thanks, > > Mimi I just wonder what you exactly gain with "_ca"? /Jarkko
On Thu, 2021-08-26 at 01:21 +0300, Jarkko Sakkinen wrote: > On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote: > > > > > Jarkko, I think the emphasis should not be on "machine" from > > > > > Machine Owner Key (MOK), but on "owner". Whereas Nayna is > > > > > focusing more on the "_ca" aspect of the name. Perhaps > > > > > consider naming it "system_owner_ca" or something along those > > > > > lines. > > > > What do you gain such overly long identifier? Makes no sense. > > > > What is "ca aspect of the name" anyway? > > > > > > As I mentioned previously, the main usage of this new keyring is > > > that it should contain only CA keys which can be later used to > > > vouch for user keys loaded onto secondary or IMA keyring at > > > runtime. Having ca in the name like .xxxx_ca, would make the > > > keyring name self-describing. Since you preferred .system, we can > > > call it .system_ca. > > > > Sounds good to me. Jarkko? > > > > thanks, > > > > Mimi > > I just wonder what you exactly gain with "_ca"? Remember, a CA cert is a self signed cert with the CA:TRUE basic constraint. Pretty much no secure boot key satisfies this (secure boot chose deliberately NOT to use CA certificates, so they're all some type of intermediate or leaf), so the design seems to be only to pick out the CA certificates you put in the MOK keyring. Adding the _ca suffix may deflect some of the "why aren't all my MOK certificates in the keyring" emails ... James
On 8/25/21 6:27 PM, James Bottomley wrote: > On Thu, 2021-08-26 at 01:21 +0300, Jarkko Sakkinen wrote: >> On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote: >>>>>> Jarkko, I think the emphasis should not be on "machine" from >>>>>> Machine Owner Key (MOK), but on "owner". Whereas Nayna is >>>>>> focusing more on the "_ca" aspect of the name. Perhaps >>>>>> consider naming it "system_owner_ca" or something along those >>>>>> lines. >>>>> What do you gain such overly long identifier? Makes no sense. >>>>> What is "ca aspect of the name" anyway? >>>> As I mentioned previously, the main usage of this new keyring is >>>> that it should contain only CA keys which can be later used to >>>> vouch for user keys loaded onto secondary or IMA keyring at >>>> runtime. Having ca in the name like .xxxx_ca, would make the >>>> keyring name self-describing. Since you preferred .system, we can >>>> call it .system_ca. >>> Sounds good to me. Jarkko? >>> >>> thanks, >>> >>> Mimi >> I just wonder what you exactly gain with "_ca"? > Remember, a CA cert is a self signed cert with the CA:TRUE basic > constraint. Pretty much no secure boot key satisfies this (secure boot > chose deliberately NOT to use CA certificates, so they're all some type > of intermediate or leaf), so the design seems to be only to pick out > the CA certificates you put in the MOK keyring. Adding the _ca suffix > may deflect some of the "why aren't all my MOK certificates in the > keyring" emails ... My understanding is the .system_ca keyring should not be restricted only to self-signed CAs (Root CA). Any cert that can qualify as Root or Intermediate CA with Basic Constraints CA:TRUE should be allowed. In fact, the intermediate CA certificates closest to the leaf nodes would be best. Thanks for bringing up that adding the _ca suffix may deflect some of the "why aren't all my MOK certificates in the keyring" emails. Thanks & Regards, - Nayna
> On Aug 27, 2021, at 2:44 PM, Nayna <nayna@linux.vnet.ibm.com> wrote: > On 8/25/21 6:27 PM, James Bottomley wrote: >> >> Remember, a CA cert is a self signed cert with the CA:TRUE basic >> constraint. Pretty much no secure boot key satisfies this (secure boot >> chose deliberately NOT to use CA certificates, so they're all some type >> of intermediate or leaf), so the design seems to be only to pick out >> the CA certificates you put in the MOK keyring. Adding the _ca suffix >> may deflect some of the "why aren't all my MOK certificates in the >> keyring" emails ... > > > My understanding is the .system_ca keyring should not be restricted only > to self-signed CAs (Root CA). Any cert that can qualify as Root or > Intermediate CA with Basic Constraints CA:TRUE should be allowed. In > fact, the intermediate CA certificates closest to the leaf nodes would be > best. With an intermediate containing CA:TRUE, the intermediate cert would not be self signed. Just for my clarification, does this mean I should remove the check that validates if it is self signed and instead somehow check if the CA flag is set? Wouldn’t this potentially allow improperly signed certs into this new keyring?
On 8/30/21 1:39 PM, Eric Snowberg wrote: >> On Aug 27, 2021, at 2:44 PM, Nayna <nayna@linux.vnet.ibm.com> wrote: >> On 8/25/21 6:27 PM, James Bottomley wrote: >>> Remember, a CA cert is a self signed cert with the CA:TRUE basic >>> constraint. Pretty much no secure boot key satisfies this (secure boot >>> chose deliberately NOT to use CA certificates, so they're all some type >>> of intermediate or leaf), so the design seems to be only to pick out >>> the CA certificates you put in the MOK keyring. Adding the _ca suffix >>> may deflect some of the "why aren't all my MOK certificates in the >>> keyring" emails ... >> >> My understanding is the .system_ca keyring should not be restricted only >> to self-signed CAs (Root CA). Any cert that can qualify as Root or >> Intermediate CA with Basic Constraints CA:TRUE should be allowed. In >> fact, the intermediate CA certificates closest to the leaf nodes would be >> best. > With an intermediate containing CA:TRUE, the intermediate cert would not > be self signed. Just for my clarification, does this mean I should remove > the check that validates if it is self signed and instead somehow check if > the CA flag is set? Wouldn’t this potentially allow improperly signed certs > into this new keyring? > In this model, we are relying on the admin to ensure the authenticity of the certificate(s) being loaded onto the new keyring. It is similar to trusting the admin to enable the variable and add keys to MOK. Following are the checks that must pass before adding it to .system_ca keyring. 1. Check against revocation_list. 2. Check Basic Constraints: CA=TRUE. 3. Check keyUsage = keyCertSign. Thanks & Regards, - Nayna
> On Aug 31, 2021, at 6:52 PM, Nayna <nayna@linux.vnet.ibm.com> wrote: > > > On 8/30/21 1:39 PM, Eric Snowberg wrote: >>> On Aug 27, 2021, at 2:44 PM, Nayna <nayna@linux.vnet.ibm.com> wrote: >>> On 8/25/21 6:27 PM, James Bottomley wrote: >>>> Remember, a CA cert is a self signed cert with the CA:TRUE basic >>>> constraint. Pretty much no secure boot key satisfies this (secure boot >>>> chose deliberately NOT to use CA certificates, so they're all some type >>>> of intermediate or leaf), so the design seems to be only to pick out >>>> the CA certificates you put in the MOK keyring. Adding the _ca suffix >>>> may deflect some of the "why aren't all my MOK certificates in the >>>> keyring" emails ... >>> >>> My understanding is the .system_ca keyring should not be restricted only >>> to self-signed CAs (Root CA). Any cert that can qualify as Root or >>> Intermediate CA with Basic Constraints CA:TRUE should be allowed. In >>> fact, the intermediate CA certificates closest to the leaf nodes would be >>> best. >> With an intermediate containing CA:TRUE, the intermediate cert would not >> be self signed. Just for my clarification, does this mean I should remove >> the check that validates if it is self signed and instead somehow check if >> the CA flag is set? Wouldn’t this potentially allow improperly signed certs >> into this new keyring? >> > In this model, we are relying on the admin to ensure the authenticity of the certificate(s) being loaded onto the new keyring. It is similar to trusting the admin to enable the variable and add keys to MOK. Following are the checks that must pass before adding it to .system_ca keyring. > > 1. Check against revocation_list. > 2. Check Basic Constraints: CA=TRUE. > 3. Check keyUsage = keyCertSign. Originally I thought the request to only load CA certs into this new keyring was so root of trust could be validated for the entire chain. If a portion of the model now relies on the admin to ensure authenticity, and the complete chain is not needed, why not have the admin also check for #2 and #3? Meaning, when the Kconfig option is enabled and the new MokListTrustedRT UEFI is set, whatever the admin has placed in the MOKList goes into this new keyring.
On Fri, 2021-08-27 at 16:44 -0400, Nayna wrote: > On 8/25/21 6:27 PM, James Bottomley wrote: > > On Thu, 2021-08-26 at 01:21 +0300, Jarkko Sakkinen wrote: > > > On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote: > > > > > > > Jarkko, I think the emphasis should not be on "machine" from > > > > > > > Machine Owner Key (MOK), but on "owner". Whereas Nayna is > > > > > > > focusing more on the "_ca" aspect of the name. Perhaps > > > > > > > consider naming it "system_owner_ca" or something along those > > > > > > > lines. > > > > > > What do you gain such overly long identifier? Makes no sense. > > > > > > What is "ca aspect of the name" anyway? > > > > > As I mentioned previously, the main usage of this new keyring is > > > > > that it should contain only CA keys which can be later used to > > > > > vouch for user keys loaded onto secondary or IMA keyring at > > > > > runtime. Having ca in the name like .xxxx_ca, would make the > > > > > keyring name self-describing. Since you preferred .system, we can > > > > > call it .system_ca. > > > > Sounds good to me. Jarkko? > > > > > > > > thanks, > > > > > > > > Mimi > > > I just wonder what you exactly gain with "_ca"? > > Remember, a CA cert is a self signed cert with the CA:TRUE basic > > constraint. Pretty much no secure boot key satisfies this (secure boot > > chose deliberately NOT to use CA certificates, so they're all some type > > of intermediate or leaf), so the design seems to be only to pick out > > the CA certificates you put in the MOK keyring. Adding the _ca suffix > > may deflect some of the "why aren't all my MOK certificates in the > > keyring" emails ... > > My understanding is the .system_ca keyring should not be restricted only > to self-signed CAs (Root CA). Any cert that can qualify as Root or > Intermediate CA with Basic Constraints CA:TRUE should be allowed. In > fact, the intermediate CA certificates closest to the leaf nodes would > be best. > > Thanks for bringing up that adding the _ca suffix may deflect some of > the "why aren't all my MOK certificates in the keyring" emails. What the heck is the pragamatic gain of adding such a suffix? Makes zero sense. /Jarkko
On Wed, 2021-09-01 at 07:34 +0300, Jarkko Sakkinen wrote: > On Fri, 2021-08-27 at 16:44 -0400, Nayna wrote: > > On 8/25/21 6:27 PM, James Bottomley wrote: > > > On Thu, 2021-08-26 at 01:21 +0300, Jarkko Sakkinen wrote: > > > > On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote: > > > > > > > > Jarkko, I think the emphasis should not be on "machine" from > > > > > > > > Machine Owner Key (MOK), but on "owner". Whereas Nayna is > > > > > > > > focusing more on the "_ca" aspect of the name. Perhaps > > > > > > > > consider naming it "system_owner_ca" or something along those > > > > > > > > lines. > > > > > > > What do you gain such overly long identifier? Makes no sense. > > > > > > > What is "ca aspect of the name" anyway? > > > > > > As I mentioned previously, the main usage of this new keyring is > > > > > > that it should contain only CA keys which can be later used to > > > > > > vouch for user keys loaded onto secondary or IMA keyring at > > > > > > runtime. Having ca in the name like .xxxx_ca, would make the > > > > > > keyring name self-describing. Since you preferred .system, we can > > > > > > call it .system_ca. > > > > > Sounds good to me. Jarkko? > > > > > > > > > > thanks, > > > > > > > > > > Mimi > > > > I just wonder what you exactly gain with "_ca"? > > > Remember, a CA cert is a self signed cert with the CA:TRUE basic > > > constraint. Pretty much no secure boot key satisfies this (secure boot > > > chose deliberately NOT to use CA certificates, so they're all some type > > > of intermediate or leaf), so the design seems to be only to pick out > > > the CA certificates you put in the MOK keyring. Adding the _ca suffix > > > may deflect some of the "why aren't all my MOK certificates in the > > > keyring" emails ... > > > > My understanding is the .system_ca keyring should not be restricted only > > to self-signed CAs (Root CA). Any cert that can qualify as Root or > > Intermediate CA with Basic Constraints CA:TRUE should be allowed. In > > fact, the intermediate CA certificates closest to the leaf nodes would > > be best. > > > > Thanks for bringing up that adding the _ca suffix may deflect some of > > the "why aren't all my MOK certificates in the keyring" emails. > > What the heck is the pragamatic gain of adding such a suffix? Makes > zero sense If this series needs both "system" and "system_ca" keyrings, then there would be some sanity in this. Also, I still *fully* lack understanding of the use of word system. Why MOK is not SOK then?? /Jarkko
On Wed, 2021-09-01 at 07:36 +0300, Jarkko Sakkinen wrote: > On Wed, 2021-09-01 at 07:34 +0300, Jarkko Sakkinen wrote: > > On Fri, 2021-08-27 at 16:44 -0400, Nayna wrote: > > > On 8/25/21 6:27 PM, James Bottomley wrote: > > > > On Thu, 2021-08-26 at 01:21 +0300, Jarkko Sakkinen wrote: > > > > > On Tue, 2021-08-24 at 10:34 -0400, Mimi Zohar wrote: > > > > > > > > > Jarkko, I think the emphasis should not be on "machine" from > > > > > > > > > Machine Owner Key (MOK), but on "owner". Whereas Nayna is > > > > > > > > > focusing more on the "_ca" aspect of the name. Perhaps > > > > > > > > > consider naming it "system_owner_ca" or something along those > > > > > > > > > lines. > > > > > > > > What do you gain such overly long identifier? Makes no sense. > > > > > > > > What is "ca aspect of the name" anyway? > > > > > > > As I mentioned previously, the main usage of this new keyring is > > > > > > > that it should contain only CA keys which can be later used to > > > > > > > vouch for user keys loaded onto secondary or IMA keyring at > > > > > > > runtime. Having ca in the name like .xxxx_ca, would make the > > > > > > > keyring name self-describing. Since you preferred .system, we can > > > > > > > call it .system_ca. > > > > > > Sounds good to me. Jarkko? > > > > > > > > > > > > thanks, > > > > > > > > > > > > Mimi > > > > > I just wonder what you exactly gain with "_ca"? > > > > Remember, a CA cert is a self signed cert with the CA:TRUE basic > > > > constraint. Pretty much no secure boot key satisfies this (secure boot > > > > chose deliberately NOT to use CA certificates, so they're all some type > > > > of intermediate or leaf), so the design seems to be only to pick out > > > > the CA certificates you put in the MOK keyring. Adding the _ca suffix > > > > may deflect some of the "why aren't all my MOK certificates in the > > > > keyring" emails ... > > > > > > My understanding is the .system_ca keyring should not be restricted only > > > to self-signed CAs (Root CA). Any cert that can qualify as Root or > > > Intermediate CA with Basic Constraints CA:TRUE should be allowed. In > > > fact, the intermediate CA certificates closest to the leaf nodes would > > > be best. > > > > > > Thanks for bringing up that adding the _ca suffix may deflect some of > > > the "why aren't all my MOK certificates in the keyring" emails. > > > > What the heck is the pragamatic gain of adding such a suffix? Makes > > zero sense > > If this series needs both "system" and "system_ca" keyrings, then > there would be some sanity in this. > > Also, I still *fully* lack understanding of the use of word system. > > Why MOK is not SOK then?? Please just call it "machine". You have machines that hold the keyring. "system" does not mean anything concrete. I don't know what a "system" is. /Jarkko
On Tue, 2021-08-31 at 19:51 -0600, Eric Snowberg wrote: > > On Aug 31, 2021, at 6:52 PM, Nayna <nayna@linux.vnet.ibm.com> wrote: > > On 8/30/21 1:39 PM, Eric Snowberg wrote: > >>> On Aug 27, 2021, at 2:44 PM, Nayna <nayna@linux.vnet.ibm.com> wrote: > >>> On 8/25/21 6:27 PM, James Bottomley wrote: > >>>> Remember, a CA cert is a self signed cert with the CA:TRUE basic > >>>> constraint. Pretty much no secure boot key satisfies this (secure boot > >>>> chose deliberately NOT to use CA certificates, so they're all some type > >>>> of intermediate or leaf), so the design seems to be only to pick out > >>>> the CA certificates you put in the MOK keyring. Adding the _ca suffix > >>>> may deflect some of the "why aren't all my MOK certificates in the > >>>> keyring" emails ... > >>> > >>> My understanding is the .system_ca keyring should not be restricted only > >>> to self-signed CAs (Root CA). Any cert that can qualify as Root or > >>> Intermediate CA with Basic Constraints CA:TRUE should be allowed. In > >>> fact, the intermediate CA certificates closest to the leaf nodes would be > >>> best. > >> With an intermediate containing CA:TRUE, the intermediate cert would not > >> be self signed. Just for my clarification, does this mean I should remove > >> the check that validates if it is self signed and instead somehow check if > >> the CA flag is set? Wouldn’t this potentially allow improperly signed certs > >> into this new keyring? > >> > > In this model, we are relying on the admin to ensure the authenticity of the certificate(s) being loaded onto the new keyring. It is similar to trusting the admin to enable the variable and add keys to MOK. Following are the checks that must pass before adding it to .system_ca keyring. > > > > 1. Check against revocation_list. > > 2. Check Basic Constraints: CA=TRUE. > > 3. Check keyUsage = keyCertSign. > > Originally I thought the request to only load CA certs into this new keyring > was so root of trust could be validated for the entire chain. If a portion > of the model now relies on the admin to ensure authenticity, and the complete > chain is not needed, why not have the admin also check for #2 and #3? Meaning, > when the Kconfig option is enabled and the new MokListTrustedRT UEFI is set, > whatever the admin has placed in the MOKList goes into this new keyring. The root of trust for the new "machine" keyring, at least in the UEFI use case, is registering keys in the MOK db, which requires physical presence. So we're trusting the MOK db, which means we're really trusting both the admin and UEFI to do the right things. There is no harm in verifying the CA assumption when loading the certs onto the "machine" keyring. From an IMA perspective, all that is needed to sign an IMA custom policy and local code is the ability to load a single self-signed CA certificate. So the self-signed CA restriction is fine. Obviously other use cases are being discussed here. If the other use cases want to relax the self-signed CA restriction to allow intermediary CA's, it should be explicitly called out in a separate patch, with its own patch description, providing the motivation. thanks, Mimi
Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boot DB and MOK keys to validate the next step in the boot chain. The MOK facility can be used to import user generated keys. These keys can be used to sign an end-user development kernel build. When Linux boots, pre-boot keys (both UEFI Secure Boot DB and MOK keys) get loaded in the Linux .platform keyring. Currently, pre-boot keys are not trusted within the Linux trust boundary [1]. These platform keys can only be used for kexec. If an end-user wants to use their own key within the Linux trust boundary, they must either compile it into the kernel themselves or use the insert-sys-cert script. Both options present a problem. Many end-users do not want to compile their own kernels. With the insert-sys-cert option, there are missing upstream changes [2]. Also, with the insert-sys-cert option, the end-user must re-sign their kernel again with their own key, and then insert that key into the MOK db. Another problem with insert-sys-cert is that only a single key can be inserted into a compressed kernel. Having the ability to insert a key into the Linux trust boundary opens up various possibilities. The end-user can use a pre-built kernel and sign their own kernel modules. It also opens up the ability for an end-user to more easily use digital signature based IMA-appraisal. To get a key into the ima keyring, it must be signed by a key within the Linux trust boundary. Downstream Linux distros try to have a single signed kernel for each architecture. Each end-user may use this kernel in entirely different ways. Some downstream kernels have chosen to always trust platform keys within the Linux trust boundary for kernel module signing. These kernels have no way of using digital signature base IMA appraisal. This series introduces a new Linux kernel keyring containing the Machine Owner Keys (MOK) called .mok. It also adds a new MOK variable to shim. This variable allows the end-user to decide if they want to trust keys enrolled in the MOK within the Linux trust boundary. By default, nothing changes; MOK keys are not trusted within the Linux kernel. They are only trusted after the end-user makes the decision themselves. The end-user would set this through mokutil using a new --trust-mok option [3]. This would work similar to how the kernel uses MOK variables to enable/disable signature validation as well as use/ignore the db. When shim boots, it mirrors the new MokTML Boot Services variable to a new MokListTrustedRT Runtime Services variable and extends PCR14. MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set, preventing an end-user from setting it after booting and doing a kexec. When the kernel boots, if MokListTrustedRT is set and EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the mok keyring instead of the platform keyring. Mimi has suggested that only CA keys be loaded into this keyring. All other certs will load into the platform keyring instead. The .mok keyring contains a new keyring permission that only allows CA keys to be loaded. If the permission fails, the key is later loaded into the platform keyring. After all keys are added into the .mok keyring, they are linked to the secondary trusted keyring. After the link is created, keys contained in the .mok keyring will automatically be searched when searching the secondary trusted keys. Secure Boot keys will never be trusted. They will always be loaded into the platform keyring. If an end-user wanted to trust one, they would need to enroll it into the MOK. I have included links to both the mokutil [3] and shim [4] changes I have made to support this new functionality. V2 changes: - The .mok keyring persists past boot - Removed the unrestricted move into the secondary keyring - Removed the keyring move bypass patch - Added restrictions to allow the .mok to be linked to either the builtin or secondary keyrings - Secondary keyring dependency has been removed V3 changes: - Only CA keys contained in the MOKList are loaded, nothing else - Support for kernels built without the secondary trusted keyring has been dropped. V4 changes: - Add new Kconfig INTEGRITY_MOK_KEYRING and move all mok keyring code behind it - Changed patch series ordering - Consolidated a few patches [1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/ [2] https://lore.kernel.org/patchwork/cover/902768/ [3] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars-v2 [4] https://github.com/esnowberg/shim/tree/mokvars-v2 Eric Snowberg (12): integrity: Introduce a Linux keyring for the Machine Owner Key (MOK) integrity: Do not allow mok keyring updates following init KEYS: CA link restriction integrity: restrict INTEGRITY_KEYRING_MOK to restrict_link_by_ca integrity: add new keyring handler for mok keys KEYS: add a reference to mok keyring KEYS: Introduce link restriction to include builtin, secondary and mok keys KEYS: integrity: change link restriction to trust the mok keyring KEYS: link secondary_trusted_keys to mok trusted keys integrity: store reference to mok keyring integrity: Trust MOK keys if MokListTrustedRT found integrity: Only use mok keyring when uefi_check_trust_mok_keys is true certs/system_keyring.c | 40 ++++++++- crypto/asymmetric_keys/restrict.c | 40 +++++++++ include/crypto/public_key.h | 5 ++ include/keys/system_keyring.h | 14 +++ security/integrity/Kconfig | 11 +++ security/integrity/Makefile | 1 + security/integrity/digsig.c | 18 +++- security/integrity/integrity.h | 17 +++- .../platform_certs/keyring_handler.c | 17 +++- .../platform_certs/keyring_handler.h | 5 ++ security/integrity/platform_certs/load_uefi.c | 4 +- .../integrity/platform_certs/mok_keyring.c | 85 +++++++++++++++++++ 12 files changed, 249 insertions(+), 8 deletions(-) create mode 100644 security/integrity/platform_certs/mok_keyring.c base-commit: 7c60610d476766e128cc4284bb6349732cbd6606