Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

[Mimi Zohar]

On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
> Here's a set of patches that changes how keys are determined to be trusted
> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
> indicates that only keys with this flag set may be added to that keyring.
> 
> Further, any time an X.509 certificate is instantiated without this flag
> set, the certificate is judged against the contents of the system trusted
> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
> 
> With these patches, KEY_FLAG_TRUSTED is removed.  The kernel may add
> implicitly trusted keys to a trusted-only keyring by asserting
> KEY_ALLOC_TRUSTED when the key is created, 

Ok, but only the x509 certificates built into the kernel image should be
automatically trusted and can be added to a trusted keyring, because the
kernel itself was signed (and verified).  These certificates extend the
(UEFI) certificate chain of trust that is rooted in hardware to the OS.

Other keys that the kernel reads and loads should not automatically be
trusted (eg. ima_load_x509).  They need to be validated against a
trusted key.

> but otherwise the key will only
> be allowed to be added to the keyring if it can be verified by a key
> already in that keyring.  The system trusted keyring is not then special in
> this sense and other trusted keyrings can be set up that are wholly
> independent of it.

We already went down this path of "transitive trust" back when we first
introduced the concept of trusted keys and keyrings.   Just because a
key is on a trusted keyring, doesn't imply that it should be permitted
to load other keys on the same trusted keyring.  In the case of
IMA-appraisal, the key should only be used to verify the file data
signature, not other keys.

The trusted keys used for verifying other certificates should be stored
on a separate keyring, not the target keyring.   Petko's patches define
a new IMA keyring named .ima_mok for this purpose.

Mimi

> To make this work, we have to retain sufficient data from the X.509
> certificate that we can then verify the signature at need.
> 
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-trust
> 
> and are tagged with:
> 
>   keys-trust-20151021
> 


--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

[Josh Boyer]

On Wed, Oct 21, 2015 at 1:02 PM, Mimi Zohar  wrote:
> On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
>> Here's a set of patches that changes how keys are determined to be trusted
>> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
>> it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
>> indicates that only keys with this flag set may be added to that keyring.
>>
>> Further, any time an X.509 certificate is instantiated without this flag
>> set, the certificate is judged against the contents of the system trusted
>> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
>>
>> With these patches, KEY_FLAG_TRUSTED is removed.  The kernel may add
>> implicitly trusted keys to a trusted-only keyring by asserting
>> KEY_ALLOC_TRUSTED when the key is created,
>
> Ok, but only the x509 certificates built into the kernel image should be
> automatically trusted and can be added to a trusted keyring, because the
> kernel itself was signed (and verified).  These certificates extend the
> (UEFI) certificate chain of trust that is rooted in hardware to the OS.

That doesn't sound accurate to me.  The cert built into the kernel
image doesn't extend the UEFI certificates.  In most cases, it is a
ephemeral cert that is automatically generated at kernel build time
and then discarded.  It is not chained to or derived from any of the
UEFI certs stored in the db (or mok) variables.  The built-in cert is
used for module loading verification.  I agree that it should be
trusted, but not really for the reason you list.  Perhaps you meant
the key that the PE image of the kernel is signed with?  If so, the
kernel doesn't load that.  Only shim (and grub2 via shim) read that
key.

However, that does bring up the UEFI db/mok certs and how to deal with
those.  The out-of-tree patches we have add them to the system keyring
as trusted keys.  We can modify the patches to use KEY_ALLOC_TRUSTED
to preserve that functionality I suppose.

josh
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

[Josh Boyer]

On Wed, Oct 21, 2015 at 2:11 PM, Mimi Zohar  wrote:
> On Wed, 2015-10-21 at 13:21 -0400, Josh Boyer wrote:
>> On Wed, Oct 21, 2015 at 1:02 PM, Mimi Zohar  wrote:
>> > On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
>> >> Here's a set of patches that changes how keys are determined to be trusted
>> >> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
>> >> it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
>> >> indicates that only keys with this flag set may be added to that keyring.
>> >>
>> >> Further, any time an X.509 certificate is instantiated without this flag
>> >> set, the certificate is judged against the contents of the system trusted
>> >> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
>> >>
>> >> With these patches, KEY_FLAG_TRUSTED is removed.  The kernel may add
>> >> implicitly trusted keys to a trusted-only keyring by asserting
>> >> KEY_ALLOC_TRUSTED when the key is created,
>> >
>> > Ok, but only the x509 certificates built into the kernel image should be
>> > automatically trusted and can be added to a trusted keyring, because the
>> > kernel itself was signed (and verified).  These certificates extend the
>> > (UEFI) certificate chain of trust that is rooted in hardware to the OS.
>>
>> That doesn't sound accurate to me.  The cert built into the kernel
>> image doesn't extend the UEFI certificates.  In most cases, it is a
>> ephemeral cert that is automatically generated at kernel build time
>> and then discarded.  It is not chained to or derived from any of the
>> UEFI certs stored in the db (or mok) variables.  The built-in cert is
>> used for module loading verification.  I agree that it should be
>> trusted, but not really for the reason you list.  Perhaps you meant
>> the key that the PE image of the kernel is signed with?  If so, the
>> kernel doesn't load that.  Only shim (and grub2 via shim) read that
>> key.
>
> This is similar to the concept of the MoK DB.  Keys added to the MoK
> aren't signed by a UEFI key, yet they extend the UEFI secure boot
> certificate chain of trust.  Similarly, the certificates built into the

Right, because UEFI is verifying shim, which verifies grub2, which
verifies the kernel.  I get that.  However, it's irrelevant.

> kernel image don't need to be signed by a UEFI/MoK key for it to extend
> the certificate chain of trust.

The certificates built _into_ the kernel need to be trusted in all
cases.  It is how module signing is done.  So a user not using Secure
Boot, or even not using UEFI, still needs those embedded certs trusted
so that they can load modules.  It has nothing to do with UEFI or some
single-root-of-trust.

At any rate, I believe we are both saying the embedded cert needs to
be trusted so there's little point in debating further.  I just wanted
to point out that this need has nothing to do with UEFI.

josh
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

[Petko Manolov]

On 15-10-21 13:02:48, Mimi Zohar wrote:
> On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
> > Here's a set of patches that changes how keys are determined to be trusted
> > - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> > it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
> > indicates that only keys with this flag set may be added to that keyring.
> > 
> > Further, any time an X.509 certificate is instantiated without this flag
> > set, the certificate is judged against the contents of the system trusted
> > keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
> > 
> > With these patches, KEY_FLAG_TRUSTED is removed.  The kernel may add
> > implicitly trusted keys to a trusted-only keyring by asserting
> > KEY_ALLOC_TRUSTED when the key is created, 
> 
> Ok, but only the x509 certificates built into the kernel image should be
> automatically trusted and can be added to a trusted keyring, because the
> kernel itself was signed (and verified).  These certificates extend the
> (UEFI) certificate chain of trust that is rooted in hardware to the OS.
> 
> Other keys that the kernel reads and loads should not automatically be
> trusted (eg. ima_load_x509).  They need to be validated against a
> trusted key.
> 
> > but otherwise the key will only
> > be allowed to be added to the keyring if it can be verified by a key
> > already in that keyring.  The system trusted keyring is not then special in
> > this sense and other trusted keyrings can be set up that are wholly
> > independent of it.
> 
> We already went down this path of "transitive trust" back when we first 
> introduced the concept of trusted keys and keyrings.  Just because a key is 
> on 
> a trusted keyring, doesn't imply that it should be permitted to load other 
> keys on the same trusted keyring.  In the case of IMA-appraisal, the key 
> should only be used to verify the file data signature, not other keys.
> 
> The trusted keys used for verifying other certificates should be stored on a 
> separate keyring, not the target keyring.  Petko's patches define a new IMA 
> keyring named .ima_mok for this purpose.

The concept is not new.  Some embedded applications are multi-tenant and 
typically have uptime measured in years.  The current CA hierarchy model of the 
kernel is somewhat limited in terms of dynamically adding trusted certificates 
and trusted keys.

.ima_mok was introduced as an intermediate keyring storing CAs that are 
themselves signed by CAs in the system keyring, which is trusted by default.  
Only keys that have been signed by certificate in .system or .ima_mok may land 
in .ima keyring.  This:

.system ---> .ima_mok ---> .ima ---> actual.key

gives us the ability to extend the chain of trust and also cover the above 
criteria.  That said, .ima_mok may be used for a whole bunch of other cases.

Think of a kernel module that comes from one of the tenants or even the machine 
owner.  They obviously don't have access to the Manufacturer's signing key 
(CA-M), but do have certificate (CA-O) that has been signed by it (CA-M).

This certificate (CA-O) can now go to .ima_mok (or whatever the name) and 
successfully verify the kernel's module signature.  CA-O may even sign another 
certificate, CA-O2, and by the above rules it may also go into .ima_mok.  And 
so 
on...

I think that in general having an intermediate CA keyring adds a lot of 
flexibility to the kernel's key management, although it's typical use does not 
make this mandatory.


cheers,
Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

[Mimi Zohar]

On Wed, 2015-10-21 at 13:21 -0400, Josh Boyer wrote:
> On Wed, Oct 21, 2015 at 1:02 PM, Mimi Zohar  wrote:
> > On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
> >> Here's a set of patches that changes how keys are determined to be trusted
> >> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> >> it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
> >> indicates that only keys with this flag set may be added to that keyring.
> >>
> >> Further, any time an X.509 certificate is instantiated without this flag
> >> set, the certificate is judged against the contents of the system trusted
> >> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
> >>
> >> With these patches, KEY_FLAG_TRUSTED is removed.  The kernel may add
> >> implicitly trusted keys to a trusted-only keyring by asserting
> >> KEY_ALLOC_TRUSTED when the key is created,
> >
> > Ok, but only the x509 certificates built into the kernel image should be
> > automatically trusted and can be added to a trusted keyring, because the
> > kernel itself was signed (and verified).  These certificates extend the
> > (UEFI) certificate chain of trust that is rooted in hardware to the OS.
> 
> That doesn't sound accurate to me.  The cert built into the kernel
> image doesn't extend the UEFI certificates.  In most cases, it is a
> ephemeral cert that is automatically generated at kernel build time
> and then discarded.  It is not chained to or derived from any of the
> UEFI certs stored in the db (or mok) variables.  The built-in cert is
> used for module loading verification.  I agree that it should be
> trusted, but not really for the reason you list.  Perhaps you meant
> the key that the PE image of the kernel is signed with?  If so, the
> kernel doesn't load that.  Only shim (and grub2 via shim) read that
> key.

This is similar to the concept of the MoK DB.  Keys added to the MoK
aren't signed by a UEFI key, yet they extend the UEFI secure boot
certificate chain of trust.  Similarly, the certificates built into the
kernel image don't need to be signed by a UEFI/MoK key for it to extend
the certificate chain of trust.

> However, that does bring up the UEFI db/mok certs and how to deal with
> those.  The out-of-tree patches we have add them to the system keyring
> as trusted keys.  We can modify the patches to use KEY_ALLOC_TRUSTED
> to preserve that functionality I suppose.

Certificates are use case specific.  Just because a key was trusted at
the UEFI layer doesn't mean it should be trusted by the kernel (eg.
Microsoft key).  To illustrate this point, David Howells/David Woodhouse
recently posted/upstreamed patches to differentiate how keys loaded onto
the system keyring may be used. (Reference needed.)

Mimi

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

[Mimi Zohar]

On Wed, 2015-10-21 at 14:21 -0400, Josh Boyer wrote:
> On Wed, Oct 21, 2015 at 2:11 PM, Mimi Zohar  wrote:
> > On Wed, 2015-10-21 at 13:21 -0400, Josh Boyer wrote:
> >> On Wed, Oct 21, 2015 at 1:02 PM, Mimi Zohar  
> >> wrote:
> >> > On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
> >> >> Here's a set of patches that changes how keys are determined to be 
> >> >> trusted
> >> >> - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set 
> >> >> upon
> >> >> it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
> >> >> indicates that only keys with this flag set may be added to that 
> >> >> keyring.
> >> >>
> >> >> Further, any time an X.509 certificate is instantiated without this flag
> >> >> set, the certificate is judged against the contents of the system 
> >> >> trusted
> >> >> keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
> >> >>
> >> >> With these patches, KEY_FLAG_TRUSTED is removed.  The kernel may add
> >> >> implicitly trusted keys to a trusted-only keyring by asserting
> >> >> KEY_ALLOC_TRUSTED when the key is created,
> >> >
> >> > Ok, but only the x509 certificates built into the kernel image should be
> >> > automatically trusted and can be added to a trusted keyring, because the
> >> > kernel itself was signed (and verified).  These certificates extend the
> >> > (UEFI) certificate chain of trust that is rooted in hardware to the OS.
> >>
> >> That doesn't sound accurate to me.  The cert built into the kernel
> >> image doesn't extend the UEFI certificates.  In most cases, it is a
> >> ephemeral cert that is automatically generated at kernel build time
> >> and then discarded.  It is not chained to or derived from any of the
> >> UEFI certs stored in the db (or mok) variables.  The built-in cert is
> >> used for module loading verification.  I agree that it should be
> >> trusted, but not really for the reason you list.  Perhaps you meant
> >> the key that the PE image of the kernel is signed with?  If so, the
> >> kernel doesn't load that.  Only shim (and grub2 via shim) read that
> >> key.
> >
> > This is similar to the concept of the MoK DB.  Keys added to the MoK
> > aren't signed by a UEFI key, yet they extend the UEFI secure boot
> > certificate chain of trust.  Similarly, the certificates built into the
> 
> Right, because UEFI is verifying shim, which verifies grub2, which
> verifies the kernel.  I get that.  However, it's irrelevant.
> 
> > kernel image don't need to be signed by a UEFI/MoK key for it to extend
> > the certificate chain of trust.
> 
> The certificates built _into_ the kernel need to be trusted in all
> cases.  It is how module signing is done.  So a user not using Secure
> Boot, or even not using UEFI, still needs those embedded certs trusted
> so that they can load modules.  It has nothing to do with UEFI or some
> single-root-of-trust.
> 
> At any rate, I believe we are both saying the embedded cert needs to
> be trusted so there's little point in debating further.  I just wanted
> to point out that this need has nothing to do with UEFI.

Right, the embedded certs need to trusted.  But that trust needs to be
based on something.  One method of establishing that trust is (UEFI)
secure boot, which verifies the kernel image signature, including the
embedded certs.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html