[PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Eric Snowberg]

Currently root can dynamically update the blacklist keyring if the hash
being added is signed and vouched for by the builtin trusted keyring.
Currently keys in the secondary trusted keyring can not be used.

Keys within the secondary trusted keyring carry the same capabilities as
the builtin trusted keyring.  Relax the current restriction for updating
the .blacklist keyring and allow the secondary to also be referenced as
a trust source.  Since the machine keyring is linked to the secondary
trusted keyring, any key within it may also be used.

An example use case for this is IMA appraisal.  Now that IMA both
references the blacklist keyring and allows the machine owner to add
custom IMA CA certs via the machine keyring, this adds the additional
capability for the machine owner to also do revocations on a running
system.

IMA appraisal usage example to add a revocation for /usr/foo:

sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt

openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
       -signer machine-certificate.pem -noattr -binary -outform DER \
       -out hash.p7s

keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 certs/Kconfig     | 2 +-
 certs/blacklist.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/certs/Kconfig b/certs/Kconfig
index 1f109b070877..23dc87c52aff 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -134,7 +134,7 @@ config SYSTEM_BLACKLIST_AUTH_UPDATE
 	depends on SYSTEM_DATA_VERIFICATION
 	help
 	  If set, provide the ability to load new blacklist keys at run time if
-	  they are signed and vouched by a certificate from the builtin trusted
+	  they are signed and vouched by a certificate from the secondary trusted
 	  keyring.  The PKCS#7 signature of the description is set in the key
 	  payload.  Blacklist keys cannot be removed.
 
diff --git a/certs/blacklist.c b/certs/blacklist.c
index 675dd7a8f07a..0b346048ae2d 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -102,12 +102,12 @@ static int blacklist_key_instantiate(struct key *key,
 
 #ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE
 	/*
-	 * Verifies the description's PKCS#7 signature against the builtin
+	 * Verifies the description's PKCS#7 signature against the secondary
 	 * trusted keyring.
 	 */
 	err = verify_pkcs7_signature(key->description,
 			strlen(key->description), prep->data, prep->datalen,
-			NULL, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
+			VERIFY_USE_SECONDARY_KEYRING, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
 	if (err)
 		return err;
 #else
-- 
2.39.3

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Mimi Zohar]

Hi Eric,

On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> Currently root can dynamically update the blacklist keyring if the hash
> being added is signed and vouched for by the builtin trusted keyring.
> Currently keys in the secondary trusted keyring can not be used.
> 
> Keys within the secondary trusted keyring carry the same capabilities as
> the builtin trusted keyring.  Relax the current restriction for updating
> the .blacklist keyring and allow the secondary to also be referenced as
> a trust source.  Since the machine keyring is linked to the secondary
> trusted keyring, any key within it may also be used.
> 
> An example use case for this is IMA appraisal.  Now that IMA both
> references the blacklist keyring and allows the machine owner to add
> custom IMA CA certs via the machine keyring, this adds the additional
> capability for the machine owner to also do revocations on a running
> system.
> 
> IMA appraisal usage example to add a revocation for /usr/foo:
> 
> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> 
> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>        -signer machine-certificate.pem -noattr -binary -outform DER \
>        -out hash.p7s
> 
> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

The secondary keyring may include both CA and code signing keys.  With
this change any key loaded onto the secondary keyring may blacklist a
hash.  Wouldn't it make more sense to limit blacklisting
certificates/hashes to at least CA keys? 

> ---
>  certs/Kconfig     | 2 +-
>  certs/blacklist.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/certs/Kconfig b/certs/Kconfig
> index 1f109b070877..23dc87c52aff 100644
> --- a/certs/Kconfig
> +++ b/certs/Kconfig
> @@ -134,7 +134,7 @@ config SYSTEM_BLACKLIST_AUTH_UPDATE
>  	depends on SYSTEM_DATA_VERIFICATION
>  	help
>  	  If set, provide the ability to load new blacklist keys at run time if
> -	  they are signed and vouched by a certificate from the builtin trusted
> +	  they are signed and vouched by a certificate from the secondary trusted

If CONFIG_SECONDARY_TRUSTED_KEYRING is not enabled, it falls back to
the builtin keyring.  Please update the comment accordingly.

>  	  keyring.  The PKCS#7 signature of the description is set in the key
>  	  payload.  Blacklist keys cannot be removed.
>  
> diff --git a/certs/blacklist.c b/certs/blacklist.c
> index 675dd7a8f07a..0b346048ae2d 100644
> --- a/certs/blacklist.c
> +++ b/certs/blacklist.c
> @@ -102,12 +102,12 @@ static int blacklist_key_instantiate(struct key *key,
>  
>  #ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE
>  	/*
> -	 * Verifies the description's PKCS#7 signature against the builtin
> +	 * Verifies the description's PKCS#7 signature against the secondary
>  	 * trusted keyring.
>  	 */

And similarly here ...

>  	err = verify_pkcs7_signature(key->description,
>  			strlen(key->description), prep->data, prep->datalen,
> -			NULL, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
> +			VERIFY_USE_SECONDARY_KEYRING, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
>  	if (err)
>  		return err;
>  #else

-- 
thanks,

Mimi

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Mickaël Salaün]

On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
> Hi Eric,
> 
> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> > Currently root can dynamically update the blacklist keyring if the hash
> > being added is signed and vouched for by the builtin trusted keyring.
> > Currently keys in the secondary trusted keyring can not be used.
> > 
> > Keys within the secondary trusted keyring carry the same capabilities as
> > the builtin trusted keyring.  Relax the current restriction for updating
> > the .blacklist keyring and allow the secondary to also be referenced as
> > a trust source.  Since the machine keyring is linked to the secondary
> > trusted keyring, any key within it may also be used.
> > 
> > An example use case for this is IMA appraisal.  Now that IMA both
> > references the blacklist keyring and allows the machine owner to add
> > custom IMA CA certs via the machine keyring, this adds the additional
> > capability for the machine owner to also do revocations on a running
> > system.
> > 
> > IMA appraisal usage example to add a revocation for /usr/foo:
> > 
> > sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> > 
> > openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> >        -signer machine-certificate.pem -noattr -binary -outform DER \
> >        -out hash.p7s
> > 
> > keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> > 
> > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> 
> The secondary keyring may include both CA and code signing keys.  With
> this change any key loaded onto the secondary keyring may blacklist a
> hash.  Wouldn't it make more sense to limit blacklisting
> certificates/hashes to at least CA keys? 

Some operational constraints may limit what a CA can sign.

This change is critical and should be tied to a dedicated kernel config
(disabled by default), otherwise existing systems using this feature
will have their threat model automatically changed without notice.

> 
> > ---
> >  certs/Kconfig     | 2 +-
> >  certs/blacklist.c | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/certs/Kconfig b/certs/Kconfig
> > index 1f109b070877..23dc87c52aff 100644
> > --- a/certs/Kconfig
> > +++ b/certs/Kconfig
> > @@ -134,7 +134,7 @@ config SYSTEM_BLACKLIST_AUTH_UPDATE
> >  	depends on SYSTEM_DATA_VERIFICATION
> >  	help
> >  	  If set, provide the ability to load new blacklist keys at run time if
> > -	  they are signed and vouched by a certificate from the builtin trusted
> > +	  they are signed and vouched by a certificate from the secondary trusted
> 
> If CONFIG_SECONDARY_TRUSTED_KEYRING is not enabled, it falls back to
> the builtin keyring.  Please update the comment accordingly.
> 
> >  	  keyring.  The PKCS#7 signature of the description is set in the key
> >  	  payload.  Blacklist keys cannot be removed.
> >  
> > diff --git a/certs/blacklist.c b/certs/blacklist.c
> > index 675dd7a8f07a..0b346048ae2d 100644
> > --- a/certs/blacklist.c
> > +++ b/certs/blacklist.c
> > @@ -102,12 +102,12 @@ static int blacklist_key_instantiate(struct key *key,
> >  
> >  #ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE
> >  	/*
> > -	 * Verifies the description's PKCS#7 signature against the builtin
> > +	 * Verifies the description's PKCS#7 signature against the secondary
> >  	 * trusted keyring.
> >  	 */
> 
> And similarly here ...
> 
> >  	err = verify_pkcs7_signature(key->description,
> >  			strlen(key->description), prep->data, prep->datalen,
> > -			NULL, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
> > +			VERIFY_USE_SECONDARY_KEYRING, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
> >  	if (err)
> >  		return err;
> >  #else
> 
> -- 
> thanks,
> 
> Mimi
> 

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Jarkko Sakkinen]

On Sat Sep 9, 2023 at 12:34 AM EEST, Eric Snowberg wrote:
> Currently root can dynamically update the blacklist keyring if the hash
> being added is signed and vouched for by the builtin trusted keyring.
> Currently keys in the secondary trusted keyring can not be used.
>
> Keys within the secondary trusted keyring carry the same capabilities as
> the builtin trusted keyring.  Relax the current restriction for updating
> the .blacklist keyring and allow the secondary to also be referenced as
> a trust source.  Since the machine keyring is linked to the secondary
> trusted keyring, any key within it may also be used.
>
> An example use case for this is IMA appraisal.  Now that IMA both
> references the blacklist keyring and allows the machine owner to add
> custom IMA CA certs via the machine keyring, this adds the additional
> capability for the machine owner to also do revocations on a running
> system.
>
> IMA appraisal usage example to add a revocation for /usr/foo:
>
> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
>
> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>        -signer machine-certificate.pem -noattr -binary -outform DER \
>        -out hash.p7s
>
> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
>
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
>  certs/Kconfig     | 2 +-
>  certs/blacklist.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/certs/Kconfig b/certs/Kconfig
> index 1f109b070877..23dc87c52aff 100644
> --- a/certs/Kconfig
> +++ b/certs/Kconfig
> @@ -134,7 +134,7 @@ config SYSTEM_BLACKLIST_AUTH_UPDATE
>  	depends on SYSTEM_DATA_VERIFICATION
>  	help
>  	  If set, provide the ability to load new blacklist keys at run time if
> -	  they are signed and vouched by a certificate from the builtin trusted
> +	  they are signed and vouched by a certificate from the secondary trusted
>  	  keyring.  The PKCS#7 signature of the description is set in the key
>  	  payload.  Blacklist keys cannot be removed.
>  
> diff --git a/certs/blacklist.c b/certs/blacklist.c
> index 675dd7a8f07a..0b346048ae2d 100644
> --- a/certs/blacklist.c
> +++ b/certs/blacklist.c
> @@ -102,12 +102,12 @@ static int blacklist_key_instantiate(struct key *key,
>  
>  #ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE
>  	/*
> -	 * Verifies the description's PKCS#7 signature against the builtin
> +	 * Verifies the description's PKCS#7 signature against the secondary
>  	 * trusted keyring.
>  	 */
>  	err = verify_pkcs7_signature(key->description,
>  			strlen(key->description), prep->data, prep->datalen,
> -			NULL, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
> +			VERIFY_USE_SECONDARY_KEYRING, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL);
>  	if (err)
>  		return err;
>  #else
> -- 
> 2.39.3

What if a live system in the wild assumes the old policy? I feel that
this is "sort of" breaking backwards compatibility but please prove me
wrong.

BR, Jarkko

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Jarkko Sakkinen]

On Mon Sep 11, 2023 at 4:29 PM EEST, Mimi Zohar wrote:
> Hi Eric,
>
> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> > Currently root can dynamically update the blacklist keyring if the hash
> > being added is signed and vouched for by the builtin trusted keyring.
> > Currently keys in the secondary trusted keyring can not be used.
> > 
> > Keys within the secondary trusted keyring carry the same capabilities as
> > the builtin trusted keyring.  Relax the current restriction for updating
> > the .blacklist keyring and allow the secondary to also be referenced as
> > a trust source.  Since the machine keyring is linked to the secondary
> > trusted keyring, any key within it may also be used.
> > 
> > An example use case for this is IMA appraisal.  Now that IMA both
> > references the blacklist keyring and allows the machine owner to add
> > custom IMA CA certs via the machine keyring, this adds the additional
> > capability for the machine owner to also do revocations on a running
> > system.
> > 
> > IMA appraisal usage example to add a revocation for /usr/foo:
> > 
> > sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> > 
> > openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> >        -signer machine-certificate.pem -noattr -binary -outform DER \
> >        -out hash.p7s
> > 
> > keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> > 
> > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>
> The secondary keyring may include both CA and code signing keys.  With
> this change any key loaded onto the secondary keyring may blacklist a
> hash.  Wouldn't it make more sense to limit blacklisting
> certificates/hashes to at least CA keys? 

I think a bigger issue is that if a kernel is updated with this patch
it will change the behavior. It is nothing to do whether the "old" or
"new" is better but more like kind of backwards compatibility issue.

BR, Jarkko

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Eric Snowberg]

> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
> 
> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>> Hi Eric,
>> 
>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>> Currently root can dynamically update the blacklist keyring if the hash
>>> being added is signed and vouched for by the builtin trusted keyring.
>>> Currently keys in the secondary trusted keyring can not be used.
>>> 
>>> Keys within the secondary trusted keyring carry the same capabilities as
>>> the builtin trusted keyring.  Relax the current restriction for updating
>>> the .blacklist keyring and allow the secondary to also be referenced as
>>> a trust source.  Since the machine keyring is linked to the secondary
>>> trusted keyring, any key within it may also be used.
>>> 
>>> An example use case for this is IMA appraisal.  Now that IMA both
>>> references the blacklist keyring and allows the machine owner to add
>>> custom IMA CA certs via the machine keyring, this adds the additional
>>> capability for the machine owner to also do revocations on a running
>>> system.
>>> 
>>> IMA appraisal usage example to add a revocation for /usr/foo:
>>> 
>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
>>> 
>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>>>       -signer machine-certificate.pem -noattr -binary -outform DER \
>>>       -out hash.p7s
>>> 
>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
>>> 
>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> 
>> The secondary keyring may include both CA and code signing keys.  With
>> this change any key loaded onto the secondary keyring may blacklist a
>> hash.  Wouldn't it make more sense to limit blacklisting
>> certificates/hashes to at least CA keys? 
> 
> Some operational constraints may limit what a CA can sign.

Agreed.  

Is there precedents for requiring this S/MIME to be signed by a CA? 

> This change is critical and should be tied to a dedicated kernel config
> (disabled by default), otherwise existing systems using this feature
> will have their threat model automatically changed without notice.

Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
this be a suitable solution for what you are after?

I suppose root could add another key to the secondary keyring if it was 
signed by a key in the machine keyring.  But then we are getting into an 
area of key usage enforcement which really only exists for things added 
to the .ima keyring. 

>>> ---
>>> certs/Kconfig     | 2 +-
>>> certs/blacklist.c | 4 ++--
>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/certs/Kconfig b/certs/Kconfig
>>> index 1f109b070877..23dc87c52aff 100644
>>> --- a/certs/Kconfig
>>> +++ b/certs/Kconfig
>>> @@ -134,7 +134,7 @@ config SYSTEM_BLACKLIST_AUTH_UPDATE
>>> 	depends on SYSTEM_DATA_VERIFICATION
>>> 	help
>>> 	  If set, provide the ability to load new blacklist keys at run time if
>>> -	  they are signed and vouched by a certificate from the builtin trusted
>>> +	  they are signed and vouched by a certificate from the secondary trusted
>> 
>> If CONFIG_SECONDARY_TRUSTED_KEYRING is not enabled, it falls back to
>> the builtin keyring.  Please update the comment accordingly.

I’ll fix these in the next round, thanks.

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Eric Snowberg]

> On Sep 11, 2023, at 4:04 PM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> On Mon Sep 11, 2023 at 4:29 PM EEST, Mimi Zohar wrote:
>> Hi Eric,
>> 
>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>> Currently root can dynamically update the blacklist keyring if the hash
>>> being added is signed and vouched for by the builtin trusted keyring.
>>> Currently keys in the secondary trusted keyring can not be used.
>>> 
>>> Keys within the secondary trusted keyring carry the same capabilities as
>>> the builtin trusted keyring.  Relax the current restriction for updating
>>> the .blacklist keyring and allow the secondary to also be referenced as
>>> a trust source.  Since the machine keyring is linked to the secondary
>>> trusted keyring, any key within it may also be used.
>>> 
>>> An example use case for this is IMA appraisal.  Now that IMA both
>>> references the blacklist keyring and allows the machine owner to add
>>> custom IMA CA certs via the machine keyring, this adds the additional
>>> capability for the machine owner to also do revocations on a running
>>> system.
>>> 
>>> IMA appraisal usage example to add a revocation for /usr/foo:
>>> 
>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
>>> 
>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>>>       -signer machine-certificate.pem -noattr -binary -outform DER \
>>>       -out hash.p7s
>>> 
>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
>>> 
>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> 
>> The secondary keyring may include both CA and code signing keys.  With
>> this change any key loaded onto the secondary keyring may blacklist a
>> hash.  Wouldn't it make more sense to limit blacklisting
>> certificates/hashes to at least CA keys? 
> 
> I think a bigger issue is that if a kernel is updated with this patch
> it will change the behavior. It is nothing to do whether the "old" or
> "new" is better but more like kind of backwards compatibility issue.

For a kernel built without the secondary trusted keyring defined, there is 
no change to their security posture. For a kernel built with the secondary 
trusted keyring defined,  I would view the system as being more secure 
with this patch.   For any system using the secondary trusted keyring, 
root can add trusted keys.  However without this patch, root can not 
mitigate a security problem on a live system and do any type of revocation
for keys it owns.  Without the ability to do a revocation, we really only have 
authenticity, not integrity.

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Mimi Zohar]

On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
> 
> > On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > 
> > On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
> >> Hi Eric,
> >> 
> >> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> >>> Currently root can dynamically update the blacklist keyring if the hash
> >>> being added is signed and vouched for by the builtin trusted keyring.
> >>> Currently keys in the secondary trusted keyring can not be used.
> >>> 
> >>> Keys within the secondary trusted keyring carry the same capabilities as
> >>> the builtin trusted keyring.  Relax the current restriction for updating
> >>> the .blacklist keyring and allow the secondary to also be referenced as
> >>> a trust source.  Since the machine keyring is linked to the secondary
> >>> trusted keyring, any key within it may also be used.
> >>> 
> >>> An example use case for this is IMA appraisal.  Now that IMA both
> >>> references the blacklist keyring and allows the machine owner to add
> >>> custom IMA CA certs via the machine keyring, this adds the additional
> >>> capability for the machine owner to also do revocations on a running
> >>> system.
> >>> 
> >>> IMA appraisal usage example to add a revocation for /usr/foo:
> >>> 
> >>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> >>> 
> >>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> >>>       -signer machine-certificate.pem -noattr -binary -outform DER \
> >>>       -out hash.p7s
> >>> 
> >>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> >>> 
> >>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> >> 
> >> The secondary keyring may include both CA and code signing keys.  With
> >> this change any key loaded onto the secondary keyring may blacklist a
> >> hash.  Wouldn't it make more sense to limit blacklisting
> >> certificates/hashes to at least CA keys? 
> > 
> > Some operational constraints may limit what a CA can sign.
> 
> Agreed.  
> 
> Is there precedents for requiring this S/MIME to be signed by a CA? 
> 
> > This change is critical and should be tied to a dedicated kernel config
> > (disabled by default), otherwise existing systems using this feature
> > will have their threat model automatically changed without notice.
> 
> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
> this be a suitable solution for what you are after?

There needs to be some correlation between the file hashes being added
to the blacklist and the certificate that signed them.  Without that
correlation, any key on the secondary trusted keyring could add any
file hashes it wants to the blacklist.

Mimi

> 
> I suppose root could add another key to the secondary keyring if it was 
> signed by a key in the machine keyring.  But then we are getting into an 
> area of key usage enforcement which really only exists for things added 
> to the .ima keyring.
> 
> >>> ---
> >>> certs/Kconfig     | 2 +-
> >>> certs/blacklist.c | 4 ++--
> >>> 2 files changed, 3 insertions(+), 3 deletions(-)
> >>> 
> >>> diff --git a/certs/Kconfig b/certs/Kconfig
> >>> index 1f109b070877..23dc87c52aff 100644
> >>> --- a/certs/Kconfig
> >>> +++ b/certs/Kconfig
> >>> @@ -134,7 +134,7 @@ config SYSTEM_BLACKLIST_AUTH_UPDATE
> >>> 	depends on SYSTEM_DATA_VERIFICATION
> >>> 	help
> >>> 	  If set, provide the ability to load new blacklist keys at run time if
> >>> -	  they are signed and vouched by a certificate from the builtin trusted
> >>> +	  they are signed and vouched by a certificate from the secondary trusted
> >> 
> >> If CONFIG_SECONDARY_TRUSTED_KEYRING is not enabled, it falls back to
> >> the builtin keyring.  Please update the comment accordingly.
> 
> I’ll fix these in the next round, thanks.
> 

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Eric Snowberg]

> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
>> 
>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>> 
>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>>>> Hi Eric,
>>>> 
>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>>>> Currently root can dynamically update the blacklist keyring if the hash
>>>>> being added is signed and vouched for by the builtin trusted keyring.
>>>>> Currently keys in the secondary trusted keyring can not be used.
>>>>> 
>>>>> Keys within the secondary trusted keyring carry the same capabilities as
>>>>> the builtin trusted keyring.  Relax the current restriction for updating
>>>>> the .blacklist keyring and allow the secondary to also be referenced as
>>>>> a trust source.  Since the machine keyring is linked to the secondary
>>>>> trusted keyring, any key within it may also be used.
>>>>> 
>>>>> An example use case for this is IMA appraisal.  Now that IMA both
>>>>> references the blacklist keyring and allows the machine owner to add
>>>>> custom IMA CA certs via the machine keyring, this adds the additional
>>>>> capability for the machine owner to also do revocations on a running
>>>>> system.
>>>>> 
>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
>>>>> 
>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
>>>>> 
>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>>>>>      -signer machine-certificate.pem -noattr -binary -outform DER \
>>>>>      -out hash.p7s
>>>>> 
>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
>>>>> 
>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>>>> 
>>>> The secondary keyring may include both CA and code signing keys.  With
>>>> this change any key loaded onto the secondary keyring may blacklist a
>>>> hash.  Wouldn't it make more sense to limit blacklisting
>>>> certificates/hashes to at least CA keys? 
>>> 
>>> Some operational constraints may limit what a CA can sign.
>> 
>> Agreed.  
>> 
>> Is there precedents for requiring this S/MIME to be signed by a CA? 
>> 
>>> This change is critical and should be tied to a dedicated kernel config
>>> (disabled by default), otherwise existing systems using this feature
>>> will have their threat model automatically changed without notice.
>> 
>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
>> this be a suitable solution for what you are after?
> 
> There needs to be some correlation between the file hashes being added
> to the blacklist and the certificate that signed them.  Without that
> correlation, any key on the secondary trusted keyring could add any
> file hashes it wants to the blacklist.

Today any key in the secondary trusted keyring can be used to validate a 
signed kernel module.  At a later time, if a new hash is added to the blacklist 
keyring to revoke loading a signed kernel module,  the ability to do the 
revocation with this additional change would be more restrictive than loading 
the original module.

But, if you think it would be appropriate, I could add a new Kconfig (disabled 
by default) that validates the key being used to vouch the S/MIME encoded 
hash is a CA.  That would certainly make this more complicated.   With this 
addition, would  the key usage field need to be referenced too?

Another idea I had was changing this patch to reference only the builtin and 
the machine keyring (if configured), not the secondary keyring.   Then with
INTEGRITY_CA_MACHINE_KEYRING_MAX, only CA keys could be 
used. Let me know your thoughts on this approach.  Thanks.

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Mimi Zohar]

On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
> 
> > On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
> >> 
> >>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
> >>> 
> >>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
> >>>> Hi Eric,
> >>>> 
> >>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> >>>>> Currently root can dynamically update the blacklist keyring if the hash
> >>>>> being added is signed and vouched for by the builtin trusted keyring.
> >>>>> Currently keys in the secondary trusted keyring can not be used.
> >>>>> 
> >>>>> Keys within the secondary trusted keyring carry the same capabilities as
> >>>>> the builtin trusted keyring.  Relax the current restriction for updating
> >>>>> the .blacklist keyring and allow the secondary to also be referenced as
> >>>>> a trust source.  Since the machine keyring is linked to the secondary
> >>>>> trusted keyring, any key within it may also be used.
> >>>>> 
> >>>>> An example use case for this is IMA appraisal.  Now that IMA both
> >>>>> references the blacklist keyring and allows the machine owner to add
> >>>>> custom IMA CA certs via the machine keyring, this adds the additional
> >>>>> capability for the machine owner to also do revocations on a running
> >>>>> system.
> >>>>> 
> >>>>> IMA appraisal usage example to add a revocation for /usr/foo:
> >>>>> 
> >>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> >>>>> 
> >>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> >>>>>      -signer machine-certificate.pem -noattr -binary -outform DER \
> >>>>>      -out hash.p7s
> >>>>> 
> >>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> >>>>> 
> >>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> >>>> 
> >>>> The secondary keyring may include both CA and code signing keys.  With
> >>>> this change any key loaded onto the secondary keyring may blacklist a
> >>>> hash.  Wouldn't it make more sense to limit blacklisting
> >>>> certificates/hashes to at least CA keys? 
> >>> 
> >>> Some operational constraints may limit what a CA can sign.
> >> 
> >> Agreed.  
> >> 
> >> Is there precedents for requiring this S/MIME to be signed by a CA? 
> >> 
> >>> This change is critical and should be tied to a dedicated kernel config
> >>> (disabled by default), otherwise existing systems using this feature
> >>> will have their threat model automatically changed without notice.
> >> 
> >> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
> >> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
> >> this be a suitable solution for what you are after?
> > 
> > There needs to be some correlation between the file hashes being added
> > to the blacklist and the certificate that signed them.  Without that
> > correlation, any key on the secondary trusted keyring could add any
> > file hashes it wants to the blacklist.
> 
> Today any key in the secondary trusted keyring can be used to validate a 
> signed kernel module.  At a later time, if a new hash is added to the blacklist 
> keyring to revoke loading a signed kernel module,  the ability to do the 
> revocation with this additional change would be more restrictive than loading 
> the original module.

A public key on the secondary keyring is used to verify code that it
signed, but does not impact any other code. Allowing any public key on
the secondary keyring to blacklist any file hash is giving it more
privileges than it originally had.

This requirement isn't different than how Certificate Revocation List
(CRL) work.  Not any CA can revoke a certificate.

> 
> But, if you think it would be appropriate, I could add a new Kconfig (disabled 
> by default) that validates the key being used to vouch the S/MIME encoded 
> hash is a CA.  That would certainly make this more complicated.   With this 
> addition, would  the key usage field need to be referenced too?
> 
> Another idea I had was changing this patch to reference only the builtin and 
> the machine keyring (if configured), not the secondary keyring.   Then with
> INTEGRITY_CA_MACHINE_KEYRING_MAX, only CA keys could be 
> used. Let me know your thoughts on this approach.  Thanks.

Better, but it doesn't address the underlying problem.

-- 
thanks,

Mimi

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Eric Snowberg]

> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
>> 
>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>> 
>>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
>>>> 
>>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>>>> 
>>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>>>>>> Hi Eric,
>>>>>> 
>>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>>>>>> Currently root can dynamically update the blacklist keyring if the hash
>>>>>>> being added is signed and vouched for by the builtin trusted keyring.
>>>>>>> Currently keys in the secondary trusted keyring can not be used.
>>>>>>> 
>>>>>>> Keys within the secondary trusted keyring carry the same capabilities as
>>>>>>> the builtin trusted keyring.  Relax the current restriction for updating
>>>>>>> the .blacklist keyring and allow the secondary to also be referenced as
>>>>>>> a trust source.  Since the machine keyring is linked to the secondary
>>>>>>> trusted keyring, any key within it may also be used.
>>>>>>> 
>>>>>>> An example use case for this is IMA appraisal.  Now that IMA both
>>>>>>> references the blacklist keyring and allows the machine owner to add
>>>>>>> custom IMA CA certs via the machine keyring, this adds the additional
>>>>>>> capability for the machine owner to also do revocations on a running
>>>>>>> system.
>>>>>>> 
>>>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
>>>>>>> 
>>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
>>>>>>> 
>>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>>>>>>>     -signer machine-certificate.pem -noattr -binary -outform DER \
>>>>>>>     -out hash.p7s
>>>>>>> 
>>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
>>>>>>> 
>>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>>>>>> 
>>>>>> The secondary keyring may include both CA and code signing keys.  With
>>>>>> this change any key loaded onto the secondary keyring may blacklist a
>>>>>> hash.  Wouldn't it make more sense to limit blacklisting
>>>>>> certificates/hashes to at least CA keys? 
>>>>> 
>>>>> Some operational constraints may limit what a CA can sign.
>>>> 
>>>> Agreed.  
>>>> 
>>>> Is there precedents for requiring this S/MIME to be signed by a CA? 
>>>> 
>>>>> This change is critical and should be tied to a dedicated kernel config
>>>>> (disabled by default), otherwise existing systems using this feature
>>>>> will have their threat model automatically changed without notice.
>>>> 
>>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
>>>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
>>>> this be a suitable solution for what you are after?
>>> 
>>> There needs to be some correlation between the file hashes being added
>>> to the blacklist and the certificate that signed them.  Without that
>>> correlation, any key on the secondary trusted keyring could add any
>>> file hashes it wants to the blacklist.
>> 
>> Today any key in the secondary trusted keyring can be used to validate a 
>> signed kernel module.  At a later time, if a new hash is added to the blacklist 
>> keyring to revoke loading a signed kernel module,  the ability to do the 
>> revocation with this additional change would be more restrictive than loading 
>> the original module.
> 
> A public key on the secondary keyring is used to verify code that it
> signed, but does not impact any other code. Allowing any public key on
> the secondary keyring to blacklist any file hash is giving it more
> privileges than it originally had.
> 
> This requirement isn't different than how Certificate Revocation List
> (CRL) work.  Not any CA can revoke a certificate.

In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
Root can update the DBX on a host.  The requirement placed on updating 
it is the new DBX entry must be signed by any key contained within the 
KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
There is not a requirement similar to how CRL’s work here, any KEK key 
can be used.

With architectures booted through a shim there is the MOKX.  Similar to 
DBX, MOKX have the same capabilities, however they do not need to be 
signed by any key, the machine owner must show they have physical 
presence (and potentially a MOK password) for inclusion.  Again there 
is not a requirement similar to how CRL’s work here either.  The machine 
owner can decide what is included.

Today when a kernel is built, any number of keys may be included within 
the builtin trusted keyring.  The keys included in the kernel may not have 
a single usage field set or the CA bit set.  There are no requirements on 
how these keys get used later on.  Any key in the builtin trusted keyring 
can be used to sign a revocation that can be added to the blacklist keyring.  
Additionally, any key in the MOK can be used to sign this kernel and it will 
boot.  Before booting the kernel, MOK keys have more privileges than 
after the kernel is booted in some instances.

Today MOK keys can be loaded into the machine keyring.  These keys get 
linked to the secondary trusted keyring.  Currently key usage enforcement
is being applied to these keys behind some Kconfig options.  By default 
anything in the secondary has the same capabilities as the builtin trusted 
keyring.  What is challenging here with this request is the inconsistency 
between how everything else currently works. 

Root can not arbitrarily add things to the secondary trusted keyring.  These 
keys must be signed by something in either the machine or the builtin.  In 
this thread [1], Jarkko is saying CA based infrastructure should be a policy 
decision not to be enforced by the kernel. Wouldn’t this apply here as well?

1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Mimi Zohar]

On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
> 
> > On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
> >> 
> >>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>> 
> >>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
> >>>> 
> >>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
> >>>>> 
> >>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
> >>>>>> Hi Eric,
> >>>>>> 
> >>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> >>>>>>> Currently root can dynamically update the blacklist keyring if the hash
> >>>>>>> being added is signed and vouched for by the builtin trusted keyring.
> >>>>>>> Currently keys in the secondary trusted keyring can not be used.
> >>>>>>> 
> >>>>>>> Keys within the secondary trusted keyring carry the same capabilities as
> >>>>>>> the builtin trusted keyring.  Relax the current restriction for updating
> >>>>>>> the .blacklist keyring and allow the secondary to also be referenced as
> >>>>>>> a trust source.  Since the machine keyring is linked to the secondary
> >>>>>>> trusted keyring, any key within it may also be used.
> >>>>>>> 
> >>>>>>> An example use case for this is IMA appraisal.  Now that IMA both
> >>>>>>> references the blacklist keyring and allows the machine owner to add
> >>>>>>> custom IMA CA certs via the machine keyring, this adds the additional
> >>>>>>> capability for the machine owner to also do revocations on a running
> >>>>>>> system.
> >>>>>>> 
> >>>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
> >>>>>>> 
> >>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> >>>>>>> 
> >>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> >>>>>>>     -signer machine-certificate.pem -noattr -binary -outform DER \
> >>>>>>>     -out hash.p7s
> >>>>>>> 
> >>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> >>>>>>> 
> >>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> >>>>>> 
> >>>>>> The secondary keyring may include both CA and code signing keys.  With
> >>>>>> this change any key loaded onto the secondary keyring may blacklist a
> >>>>>> hash.  Wouldn't it make more sense to limit blacklisting
> >>>>>> certificates/hashes to at least CA keys? 
> >>>>> 
> >>>>> Some operational constraints may limit what a CA can sign.
> >>>> 
> >>>> Agreed.  
> >>>> 
> >>>> Is there precedents for requiring this S/MIME to be signed by a CA? 
> >>>> 
> >>>>> This change is critical and should be tied to a dedicated kernel config
> >>>>> (disabled by default), otherwise existing systems using this feature
> >>>>> will have their threat model automatically changed without notice.
> >>>> 
> >>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
> >>>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
> >>>> this be a suitable solution for what you are after?
> >>> 
> >>> There needs to be some correlation between the file hashes being added
> >>> to the blacklist and the certificate that signed them.  Without that
> >>> correlation, any key on the secondary trusted keyring could add any
> >>> file hashes it wants to the blacklist.
> >> 
> >> Today any key in the secondary trusted keyring can be used to validate a 
> >> signed kernel module.  At a later time, if a new hash is added to the blacklist 
> >> keyring to revoke loading a signed kernel module,  the ability to do the 
> >> revocation with this additional change would be more restrictive than loading 
> >> the original module.
> > 
> > A public key on the secondary keyring is used to verify code that it
> > signed, but does not impact any other code. Allowing any public key on
> > the secondary keyring to blacklist any file hash is giving it more
> > privileges than it originally had.
> > 
> > This requirement isn't different than how Certificate Revocation List
> > (CRL) work.  Not any CA can revoke a certificate.
> 
> In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
> Root can update the DBX on a host.  The requirement placed on updating 
> it is the new DBX entry must be signed by any key contained within the 
> KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
> There is not a requirement similar to how CRL’s work here, any KEK key 
> can be used.
> 
> With architectures booted through a shim there is the MOKX.  Similar to 
> DBX, MOKX have the same capabilities, however they do not need to be 
> signed by any key, the machine owner must show they have physical 
> presence (and potentially a MOK password) for inclusion.  Again there 
> is not a requirement similar to how CRL’s work here either.  The machine 
> owner can decide what is included.
> 
> Today when a kernel is built, any number of keys may be included within 
> the builtin trusted keyring.  The keys included in the kernel may not have 
> a single usage field set or the CA bit set.  There are no requirements on 
> how these keys get used later on.  Any key in the builtin trusted keyring 
> can be used to sign a revocation that can be added to the blacklist keyring.  
> Additionally, any key in the MOK can be used to sign this kernel and it will 
> boot.  Before booting the kernel, MOK keys have more privileges than 
> after the kernel is booted in some instances.
> 
> Today MOK keys can be loaded into the machine keyring.  These keys get 
> linked to the secondary trusted keyring.  Currently key usage enforcement
> is being applied to these keys behind some Kconfig options.  By default 
> anything in the secondary has the same capabilities as the builtin trusted 
> keyring.  What is challenging here with this request is the inconsistency 
> between how everything else currently works. 
> 
> Root can not arbitrarily add things to the secondary trusted keyring.  These 
> keys must be signed by something in either the machine or the builtin.  In 
> this thread [1], Jarkko is saying CA based infrastructure should be a policy 
> decision not to be enforced by the kernel. Wouldn’t this apply here as well?
> 
> 1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/

Mickaël said, "This change is critical and should be tied to a
dedicated kernel config
(disabled by default), otherwise existing systems using this feature
will have their threat model automatically changed without notice."

As a possible alternative I suggested limiting which file hashes the
certs on the secondary (or machine) keyring could blacklist.
-- 
thanks,

Mimi

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Eric Snowberg]

> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
>> 
>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>> 
>>> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
>>>> 
>>>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>> 
>>>>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
>>>>>> 
>>>>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>>>>>> 
>>>>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>>>>>>>> Hi Eric,
>>>>>>>> 
>>>>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>>>>>>>> Currently root can dynamically update the blacklist keyring if the hash
>>>>>>>>> being added is signed and vouched for by the builtin trusted keyring.
>>>>>>>>> Currently keys in the secondary trusted keyring can not be used.
>>>>>>>>> 
>>>>>>>>> Keys within the secondary trusted keyring carry the same capabilities as
>>>>>>>>> the builtin trusted keyring.  Relax the current restriction for updating
>>>>>>>>> the .blacklist keyring and allow the secondary to also be referenced as
>>>>>>>>> a trust source.  Since the machine keyring is linked to the secondary
>>>>>>>>> trusted keyring, any key within it may also be used.
>>>>>>>>> 
>>>>>>>>> An example use case for this is IMA appraisal.  Now that IMA both
>>>>>>>>> references the blacklist keyring and allows the machine owner to add
>>>>>>>>> custom IMA CA certs via the machine keyring, this adds the additional
>>>>>>>>> capability for the machine owner to also do revocations on a running
>>>>>>>>> system.
>>>>>>>>> 
>>>>>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
>>>>>>>>> 
>>>>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
>>>>>>>>> 
>>>>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>>>>>>>>>    -signer machine-certificate.pem -noattr -binary -outform DER \
>>>>>>>>>    -out hash.p7s
>>>>>>>>> 
>>>>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>>>>>>>> 
>>>>>>>> The secondary keyring may include both CA and code signing keys.  With
>>>>>>>> this change any key loaded onto the secondary keyring may blacklist a
>>>>>>>> hash.  Wouldn't it make more sense to limit blacklisting
>>>>>>>> certificates/hashes to at least CA keys? 
>>>>>>> 
>>>>>>> Some operational constraints may limit what a CA can sign.
>>>>>> 
>>>>>> Agreed.  
>>>>>> 
>>>>>> Is there precedents for requiring this S/MIME to be signed by a CA? 
>>>>>> 
>>>>>>> This change is critical and should be tied to a dedicated kernel config
>>>>>>> (disabled by default), otherwise existing systems using this feature
>>>>>>> will have their threat model automatically changed without notice.
>>>>>> 
>>>>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
>>>>>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
>>>>>> this be a suitable solution for what you are after?
>>>>> 
>>>>> There needs to be some correlation between the file hashes being added
>>>>> to the blacklist and the certificate that signed them.  Without that
>>>>> correlation, any key on the secondary trusted keyring could add any
>>>>> file hashes it wants to the blacklist.
>>>> 
>>>> Today any key in the secondary trusted keyring can be used to validate a 
>>>> signed kernel module.  At a later time, if a new hash is added to the blacklist 
>>>> keyring to revoke loading a signed kernel module,  the ability to do the 
>>>> revocation with this additional change would be more restrictive than loading 
>>>> the original module.
>>> 
>>> A public key on the secondary keyring is used to verify code that it
>>> signed, but does not impact any other code. Allowing any public key on
>>> the secondary keyring to blacklist any file hash is giving it more
>>> privileges than it originally had.
>>> 
>>> This requirement isn't different than how Certificate Revocation List
>>> (CRL) work.  Not any CA can revoke a certificate.
>> 
>> In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
>> Root can update the DBX on a host.  The requirement placed on updating 
>> it is the new DBX entry must be signed by any key contained within the 
>> KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
>> There is not a requirement similar to how CRL’s work here, any KEK key 
>> can be used.
>> 
>> With architectures booted through a shim there is the MOKX.  Similar to 
>> DBX, MOKX have the same capabilities, however they do not need to be 
>> signed by any key, the machine owner must show they have physical 
>> presence (and potentially a MOK password) for inclusion.  Again there 
>> is not a requirement similar to how CRL’s work here either.  The machine 
>> owner can decide what is included.
>> 
>> Today when a kernel is built, any number of keys may be included within 
>> the builtin trusted keyring.  The keys included in the kernel may not have 
>> a single usage field set or the CA bit set.  There are no requirements on 
>> how these keys get used later on.  Any key in the builtin trusted keyring 
>> can be used to sign a revocation that can be added to the blacklist keyring.  
>> Additionally, any key in the MOK can be used to sign this kernel and it will 
>> boot.  Before booting the kernel, MOK keys have more privileges than 
>> after the kernel is booted in some instances.
>> 
>> Today MOK keys can be loaded into the machine keyring.  These keys get 
>> linked to the secondary trusted keyring.  Currently key usage enforcement
>> is being applied to these keys behind some Kconfig options.  By default 
>> anything in the secondary has the same capabilities as the builtin trusted 
>> keyring.  What is challenging here with this request is the inconsistency 
>> between how everything else currently works. 
>> 
>> Root can not arbitrarily add things to the secondary trusted keyring.  These 
>> keys must be signed by something in either the machine or the builtin.  In 
>> this thread [1], Jarkko is saying CA based infrastructure should be a policy 
>> decision not to be enforced by the kernel. Wouldn’t this apply here as well?
>> 
>> 1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/
> 
> Mickaël said, "This change is critical and should be tied to a
> dedicated kernel config
> (disabled by default), otherwise existing systems using this feature
> will have their threat model automatically changed without notice."

I was thinking he meant it is critical not to change the current behavior
by limiting blacklisting to only CA keys.  Not that it was critical to add
CA enforcement.  Maybe Mickaël can comment?

> As a possible alternative I suggested limiting which file hashes the
> certs on the secondary (or machine) keyring could blacklist.

I’m not sure I completely understand your suggestion here.
Do you mean, verify the CA bit is set for secondary keys, but
ignore the bit for builtin?  And then only use those keys to add
hashes to the blacklist keyring?  If I have that right, what would 
be the justification for the change based on how things currently
get included in the blacklist keyring?  Thanks.

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Mickaël Salaün]

On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
> 
> 
> > On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
> >> 
> >>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>> 
> >>> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
> >>>> 
> >>>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>> 
> >>>>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
> >>>>>> 
> >>>>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
> >>>>>>> 
> >>>>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
> >>>>>>>> Hi Eric,
> >>>>>>>> 
> >>>>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> >>>>>>>>> Currently root can dynamically update the blacklist keyring if the hash
> >>>>>>>>> being added is signed and vouched for by the builtin trusted keyring.
> >>>>>>>>> Currently keys in the secondary trusted keyring can not be used.
> >>>>>>>>> 
> >>>>>>>>> Keys within the secondary trusted keyring carry the same capabilities as
> >>>>>>>>> the builtin trusted keyring.  Relax the current restriction for updating
> >>>>>>>>> the .blacklist keyring and allow the secondary to also be referenced as
> >>>>>>>>> a trust source.  Since the machine keyring is linked to the secondary
> >>>>>>>>> trusted keyring, any key within it may also be used.
> >>>>>>>>> 
> >>>>>>>>> An example use case for this is IMA appraisal.  Now that IMA both
> >>>>>>>>> references the blacklist keyring and allows the machine owner to add
> >>>>>>>>> custom IMA CA certs via the machine keyring, this adds the additional
> >>>>>>>>> capability for the machine owner to also do revocations on a running
> >>>>>>>>> system.
> >>>>>>>>> 
> >>>>>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
> >>>>>>>>> 
> >>>>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> >>>>>>>>> 
> >>>>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> >>>>>>>>>    -signer machine-certificate.pem -noattr -binary -outform DER \
> >>>>>>>>>    -out hash.p7s
> >>>>>>>>> 
> >>>>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> >>>>>>>>> 
> >>>>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> >>>>>>>> 
> >>>>>>>> The secondary keyring may include both CA and code signing keys.  With
> >>>>>>>> this change any key loaded onto the secondary keyring may blacklist a
> >>>>>>>> hash.  Wouldn't it make more sense to limit blacklisting
> >>>>>>>> certificates/hashes to at least CA keys? 
> >>>>>>> 
> >>>>>>> Some operational constraints may limit what a CA can sign.
> >>>>>> 
> >>>>>> Agreed.  
> >>>>>> 
> >>>>>> Is there precedents for requiring this S/MIME to be signed by a CA? 
> >>>>>> 
> >>>>>>> This change is critical and should be tied to a dedicated kernel config
> >>>>>>> (disabled by default), otherwise existing systems using this feature
> >>>>>>> will have their threat model automatically changed without notice.
> >>>>>> 
> >>>>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
> >>>>>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
> >>>>>> this be a suitable solution for what you are after?
> >>>>> 
> >>>>> There needs to be some correlation between the file hashes being added
> >>>>> to the blacklist and the certificate that signed them.  Without that
> >>>>> correlation, any key on the secondary trusted keyring could add any
> >>>>> file hashes it wants to the blacklist.
> >>>> 
> >>>> Today any key in the secondary trusted keyring can be used to validate a 
> >>>> signed kernel module.  At a later time, if a new hash is added to the blacklist 
> >>>> keyring to revoke loading a signed kernel module,  the ability to do the 
> >>>> revocation with this additional change would be more restrictive than loading 
> >>>> the original module.
> >>> 
> >>> A public key on the secondary keyring is used to verify code that it
> >>> signed, but does not impact any other code. Allowing any public key on
> >>> the secondary keyring to blacklist any file hash is giving it more
> >>> privileges than it originally had.
> >>> 
> >>> This requirement isn't different than how Certificate Revocation List
> >>> (CRL) work.  Not any CA can revoke a certificate.
> >> 
> >> In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
> >> Root can update the DBX on a host.  The requirement placed on updating 
> >> it is the new DBX entry must be signed by any key contained within the 
> >> KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
> >> There is not a requirement similar to how CRL’s work here, any KEK key 
> >> can be used.
> >> 
> >> With architectures booted through a shim there is the MOKX.  Similar to 
> >> DBX, MOKX have the same capabilities, however they do not need to be 
> >> signed by any key, the machine owner must show they have physical 
> >> presence (and potentially a MOK password) for inclusion.  Again there 
> >> is not a requirement similar to how CRL’s work here either.  The machine 
> >> owner can decide what is included.
> >> 
> >> Today when a kernel is built, any number of keys may be included within 
> >> the builtin trusted keyring.  The keys included in the kernel may not have 
> >> a single usage field set or the CA bit set.  There are no requirements on 
> >> how these keys get used later on.  Any key in the builtin trusted keyring 
> >> can be used to sign a revocation that can be added to the blacklist keyring.  
> >> Additionally, any key in the MOK can be used to sign this kernel and it will 
> >> boot.  Before booting the kernel, MOK keys have more privileges than 
> >> after the kernel is booted in some instances.
> >> 
> >> Today MOK keys can be loaded into the machine keyring.  These keys get 
> >> linked to the secondary trusted keyring.  Currently key usage enforcement
> >> is being applied to these keys behind some Kconfig options.  By default 
> >> anything in the secondary has the same capabilities as the builtin trusted 
> >> keyring.  What is challenging here with this request is the inconsistency 
> >> between how everything else currently works. 
> >> 
> >> Root can not arbitrarily add things to the secondary trusted keyring.  These 
> >> keys must be signed by something in either the machine or the builtin.  In 
> >> this thread [1], Jarkko is saying CA based infrastructure should be a policy 
> >> decision not to be enforced by the kernel. Wouldn’t this apply here as well?
> >> 
> >> 1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/
> > 
> > Mickaël said, "This change is critical and should be tied to a
> > dedicated kernel config
> > (disabled by default), otherwise existing systems using this feature
> > will have their threat model automatically changed without notice."
> 
> I was thinking he meant it is critical not to change the current behavior
> by limiting blacklisting to only CA keys.  Not that it was critical to add
> CA enforcement.  Maybe Mickaël can comment?

I meant that applying this patch as-is may change the threat model used
by some users. Currently, only signed hashes vouched by the builtin
trusted keyring are valid. If we extend this mechanism to the secondary
trusted keyring without notice, this means that more certificates could
vouch blacklisted hashes, which may include some certificates with an
initial different usage.

See commit 4da8f8c8a1e0 ("dm verity: Add support for signature
verification with 2nd keyring") that adds
CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING:
https://lore.kernel.org/all/20201023170512.201124-1-mic@digikod.net/

> 
> > As a possible alternative I suggested limiting which file hashes the
> > certs on the secondary (or machine) keyring could blacklist.
> 
> I’m not sure I completely understand your suggestion here.
> Do you mean, verify the CA bit is set for secondary keys, but
> ignore the bit for builtin?  And then only use those keys to add
> hashes to the blacklist keyring?  If I have that right, what would 
> be the justification for the change based on how things currently
> get included in the blacklist keyring?  Thanks.

I'd like to be able to specify which kind of certificate can vouch for
blacklisting hashes, and for other usages, but AFAIK this is not the
path Linux has followed (e.g. unlike Windows). We only have the keyring
to identify an usage, which is unfortunate. On the other side, this
approach lets users manage their certificates without constraint, which
is quite (too?) flexible. A complementary approach would be to create an
LSM (or a dedicated interface) to tie certificate properties to a set of
kernel usages, while still letting users configure these constraints.

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Eric Snowberg]

> On Sep 13, 2023, at 4:21 AM, Mickaël Salaün <mic@digikod.net> wrote:
> 
> On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
>> 
>> 
>>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>> 
>>> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
>>>> 
>>>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>> 
>>>>> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
>>>>>> 
>>>>>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>>> 
>>>>>>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
>>>>>>>> 
>>>>>>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>>>>>>>> 
>>>>>>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>>>>>>>>>> Hi Eric,
>>>>>>>>>> 
>>>>>>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>>>>>>>>>> Currently root can dynamically update the blacklist keyring if the hash
>>>>>>>>>>> being added is signed and vouched for by the builtin trusted keyring.
>>>>>>>>>>> Currently keys in the secondary trusted keyring can not be used.
>>>>>>>>>>> 
>>>>>>>>>>> Keys within the secondary trusted keyring carry the same capabilities as
>>>>>>>>>>> the builtin trusted keyring.  Relax the current restriction for updating
>>>>>>>>>>> the .blacklist keyring and allow the secondary to also be referenced as
>>>>>>>>>>> a trust source.  Since the machine keyring is linked to the secondary
>>>>>>>>>>> trusted keyring, any key within it may also be used.
>>>>>>>>>>> 
>>>>>>>>>>> An example use case for this is IMA appraisal.  Now that IMA both
>>>>>>>>>>> references the blacklist keyring and allows the machine owner to add
>>>>>>>>>>> custom IMA CA certs via the machine keyring, this adds the additional
>>>>>>>>>>> capability for the machine owner to also do revocations on a running
>>>>>>>>>>> system.
>>>>>>>>>>> 
>>>>>>>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
>>>>>>>>>>> 
>>>>>>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
>>>>>>>>>>> 
>>>>>>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
>>>>>>>>>>>   -signer machine-certificate.pem -noattr -binary -outform DER \
>>>>>>>>>>>   -out hash.p7s
>>>>>>>>>>> 
>>>>>>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
>>>>>>>>>>> 
>>>>>>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>>>>>>>>>> 
>>>>>>>>>> The secondary keyring may include both CA and code signing keys.  With
>>>>>>>>>> this change any key loaded onto the secondary keyring may blacklist a
>>>>>>>>>> hash.  Wouldn't it make more sense to limit blacklisting
>>>>>>>>>> certificates/hashes to at least CA keys? 
>>>>>>>>> 
>>>>>>>>> Some operational constraints may limit what a CA can sign.
>>>>>>>> 
>>>>>>>> Agreed.  
>>>>>>>> 
>>>>>>>> Is there precedents for requiring this S/MIME to be signed by a CA? 
>>>>>>>> 
>>>>>>>>> This change is critical and should be tied to a dedicated kernel config
>>>>>>>>> (disabled by default), otherwise existing systems using this feature
>>>>>>>>> will have their threat model automatically changed without notice.
>>>>>>>> 
>>>>>>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
>>>>>>>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
>>>>>>>> this be a suitable solution for what you are after?
>>>>>>> 
>>>>>>> There needs to be some correlation between the file hashes being added
>>>>>>> to the blacklist and the certificate that signed them.  Without that
>>>>>>> correlation, any key on the secondary trusted keyring could add any
>>>>>>> file hashes it wants to the blacklist.
>>>>>> 
>>>>>> Today any key in the secondary trusted keyring can be used to validate a 
>>>>>> signed kernel module.  At a later time, if a new hash is added to the blacklist 
>>>>>> keyring to revoke loading a signed kernel module,  the ability to do the 
>>>>>> revocation with this additional change would be more restrictive than loading 
>>>>>> the original module.
>>>>> 
>>>>> A public key on the secondary keyring is used to verify code that it
>>>>> signed, but does not impact any other code. Allowing any public key on
>>>>> the secondary keyring to blacklist any file hash is giving it more
>>>>> privileges than it originally had.
>>>>> 
>>>>> This requirement isn't different than how Certificate Revocation List
>>>>> (CRL) work.  Not any CA can revoke a certificate.
>>>> 
>>>> In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
>>>> Root can update the DBX on a host.  The requirement placed on updating 
>>>> it is the new DBX entry must be signed by any key contained within the 
>>>> KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
>>>> There is not a requirement similar to how CRL’s work here, any KEK key 
>>>> can be used.
>>>> 
>>>> With architectures booted through a shim there is the MOKX.  Similar to 
>>>> DBX, MOKX have the same capabilities, however they do not need to be 
>>>> signed by any key, the machine owner must show they have physical 
>>>> presence (and potentially a MOK password) for inclusion.  Again there 
>>>> is not a requirement similar to how CRL’s work here either.  The machine 
>>>> owner can decide what is included.
>>>> 
>>>> Today when a kernel is built, any number of keys may be included within 
>>>> the builtin trusted keyring.  The keys included in the kernel may not have 
>>>> a single usage field set or the CA bit set.  There are no requirements on 
>>>> how these keys get used later on.  Any key in the builtin trusted keyring 
>>>> can be used to sign a revocation that can be added to the blacklist keyring.  
>>>> Additionally, any key in the MOK can be used to sign this kernel and it will 
>>>> boot.  Before booting the kernel, MOK keys have more privileges than 
>>>> after the kernel is booted in some instances.
>>>> 
>>>> Today MOK keys can be loaded into the machine keyring.  These keys get 
>>>> linked to the secondary trusted keyring.  Currently key usage enforcement
>>>> is being applied to these keys behind some Kconfig options.  By default 
>>>> anything in the secondary has the same capabilities as the builtin trusted 
>>>> keyring.  What is challenging here with this request is the inconsistency 
>>>> between how everything else currently works. 
>>>> 
>>>> Root can not arbitrarily add things to the secondary trusted keyring.  These 
>>>> keys must be signed by something in either the machine or the builtin.  In 
>>>> this thread [1], Jarkko is saying CA based infrastructure should be a policy 
>>>> decision not to be enforced by the kernel. Wouldn’t this apply here as well?
>>>> 
>>>> 1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/
>>> 
>>> Mickaël said, "This change is critical and should be tied to a
>>> dedicated kernel config
>>> (disabled by default), otherwise existing systems using this feature
>>> will have their threat model automatically changed without notice."
>> 
>> I was thinking he meant it is critical not to change the current behavior
>> by limiting blacklisting to only CA keys.  Not that it was critical to add
>> CA enforcement.  Maybe Mickaël can comment?
> 
> I meant that applying this patch as-is may change the threat model used
> by some users. Currently, only signed hashes vouched by the builtin
> trusted keyring are valid. If we extend this mechanism to the secondary
> trusted keyring without notice, this means that more certificates could
> vouch blacklisted hashes, which may include some certificates with an
> initial different usage.
> 
> See commit 4da8f8c8a1e0 ("dm verity: Add support for signature
> verification with 2nd keyring") that adds
> CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING:
> https://lore.kernel.org/all/20201023170512.201124-1-mic@digikod.net/

Thanks for clarifying.  I’ll add something similar in v2.

>> 
>>> As a possible alternative I suggested limiting which file hashes the
>>> certs on the secondary (or machine) keyring could blacklist.
>> 
>> I’m not sure I completely understand your suggestion here.
>> Do you mean, verify the CA bit is set for secondary keys, but
>> ignore the bit for builtin?  And then only use those keys to add
>> hashes to the blacklist keyring?  If I have that right, what would 
>> be the justification for the change based on how things currently
>> get included in the blacklist keyring?  Thanks.
> 
> I'd like to be able to specify which kind of certificate can vouch for
> blacklisting hashes, and for other usages, but AFAIK this is not the
> path Linux has followed (e.g. unlike Windows). We only have the keyring
> to identify an usage, which is unfortunate. On the other side, this
> approach lets users manage their certificates without constraint, which
> is quite (too?) flexible.

Yes, it is very flexible. What I believe Mimi is after is having a way to 
track what cert actually vouched for each specific binary hash.  But this
information is not tracked, plus entries within it can come from various 
sources that are not signed (dbx, mokx, compiled in).  Also key usage is 
being ignored.

> A complementary approach would be to create an
> LSM (or a dedicated interface) to tie certificate properties to a set of
> kernel usages, while still letting users configure these constraints.

That is an interesting idea.  Would the other security maintainers be in 
support of such an approach?  Would a LSM be the correct interface?  
Some of the recent work I have done with introducing key usage and CA 
enforcement is difficult for a distro to pick up, since these changes can be 
viewed as a regression.  Each end-user has different signing procedures 
and policies, so making something work for everyone is difficult.  Letting the 
user configure these constraints would solve this problem.

Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

[Mickaël Salaün]

CCing the LSM mailing list for this potential new LSM proposal:

On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote:
> 
> 
> > On Sep 13, 2023, at 4:21 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > 
> > On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
> >> 
> >> 
> >>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>> 
> >>> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
> >>>> 
> >>>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>> 
> >>>>> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
> >>>>>> 
> >>>>>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>>> 
> >>>>>>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
> >>>>>>>> 
> >>>>>>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
> >>>>>>>>> 
> >>>>>>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
> >>>>>>>>>> Hi Eric,
> >>>>>>>>>> 
> >>>>>>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> >>>>>>>>>>> Currently root can dynamically update the blacklist keyring if the hash
> >>>>>>>>>>> being added is signed and vouched for by the builtin trusted keyring.
> >>>>>>>>>>> Currently keys in the secondary trusted keyring can not be used.
> >>>>>>>>>>> 
> >>>>>>>>>>> Keys within the secondary trusted keyring carry the same capabilities as
> >>>>>>>>>>> the builtin trusted keyring.  Relax the current restriction for updating
> >>>>>>>>>>> the .blacklist keyring and allow the secondary to also be referenced as
> >>>>>>>>>>> a trust source.  Since the machine keyring is linked to the secondary
> >>>>>>>>>>> trusted keyring, any key within it may also be used.
> >>>>>>>>>>> 
> >>>>>>>>>>> An example use case for this is IMA appraisal.  Now that IMA both
> >>>>>>>>>>> references the blacklist keyring and allows the machine owner to add
> >>>>>>>>>>> custom IMA CA certs via the machine keyring, this adds the additional
> >>>>>>>>>>> capability for the machine owner to also do revocations on a running
> >>>>>>>>>>> system.
> >>>>>>>>>>> 
> >>>>>>>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
> >>>>>>>>>>> 
> >>>>>>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> >>>>>>>>>>> 
> >>>>>>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> >>>>>>>>>>>   -signer machine-certificate.pem -noattr -binary -outform DER \
> >>>>>>>>>>>   -out hash.p7s
> >>>>>>>>>>> 
> >>>>>>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> >>>>>>>>>>> 
> >>>>>>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> >>>>>>>>>> 
> >>>>>>>>>> The secondary keyring may include both CA and code signing keys.  With
> >>>>>>>>>> this change any key loaded onto the secondary keyring may blacklist a
> >>>>>>>>>> hash.  Wouldn't it make more sense to limit blacklisting
> >>>>>>>>>> certificates/hashes to at least CA keys? 
> >>>>>>>>> 
> >>>>>>>>> Some operational constraints may limit what a CA can sign.
> >>>>>>>> 
> >>>>>>>> Agreed.  
> >>>>>>>> 
> >>>>>>>> Is there precedents for requiring this S/MIME to be signed by a CA? 
> >>>>>>>> 
> >>>>>>>>> This change is critical and should be tied to a dedicated kernel config
> >>>>>>>>> (disabled by default), otherwise existing systems using this feature
> >>>>>>>>> will have their threat model automatically changed without notice.
> >>>>>>>> 
> >>>>>>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
> >>>>>>>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
> >>>>>>>> this be a suitable solution for what you are after?
> >>>>>>> 
> >>>>>>> There needs to be some correlation between the file hashes being added
> >>>>>>> to the blacklist and the certificate that signed them.  Without that
> >>>>>>> correlation, any key on the secondary trusted keyring could add any
> >>>>>>> file hashes it wants to the blacklist.
> >>>>>> 
> >>>>>> Today any key in the secondary trusted keyring can be used to validate a 
> >>>>>> signed kernel module.  At a later time, if a new hash is added to the blacklist 
> >>>>>> keyring to revoke loading a signed kernel module,  the ability to do the 
> >>>>>> revocation with this additional change would be more restrictive than loading 
> >>>>>> the original module.
> >>>>> 
> >>>>> A public key on the secondary keyring is used to verify code that it
> >>>>> signed, but does not impact any other code. Allowing any public key on
> >>>>> the secondary keyring to blacklist any file hash is giving it more
> >>>>> privileges than it originally had.
> >>>>> 
> >>>>> This requirement isn't different than how Certificate Revocation List
> >>>>> (CRL) work.  Not any CA can revoke a certificate.
> >>>> 
> >>>> In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
> >>>> Root can update the DBX on a host.  The requirement placed on updating 
> >>>> it is the new DBX entry must be signed by any key contained within the 
> >>>> KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
> >>>> There is not a requirement similar to how CRL’s work here, any KEK key 
> >>>> can be used.
> >>>> 
> >>>> With architectures booted through a shim there is the MOKX.  Similar to 
> >>>> DBX, MOKX have the same capabilities, however they do not need to be 
> >>>> signed by any key, the machine owner must show they have physical 
> >>>> presence (and potentially a MOK password) for inclusion.  Again there 
> >>>> is not a requirement similar to how CRL’s work here either.  The machine 
> >>>> owner can decide what is included.
> >>>> 
> >>>> Today when a kernel is built, any number of keys may be included within 
> >>>> the builtin trusted keyring.  The keys included in the kernel may not have 
> >>>> a single usage field set or the CA bit set.  There are no requirements on 
> >>>> how these keys get used later on.  Any key in the builtin trusted keyring 
> >>>> can be used to sign a revocation that can be added to the blacklist keyring.  
> >>>> Additionally, any key in the MOK can be used to sign this kernel and it will 
> >>>> boot.  Before booting the kernel, MOK keys have more privileges than 
> >>>> after the kernel is booted in some instances.
> >>>> 
> >>>> Today MOK keys can be loaded into the machine keyring.  These keys get 
> >>>> linked to the secondary trusted keyring.  Currently key usage enforcement
> >>>> is being applied to these keys behind some Kconfig options.  By default 
> >>>> anything in the secondary has the same capabilities as the builtin trusted 
> >>>> keyring.  What is challenging here with this request is the inconsistency 
> >>>> between how everything else currently works. 
> >>>> 
> >>>> Root can not arbitrarily add things to the secondary trusted keyring.  These 
> >>>> keys must be signed by something in either the machine or the builtin.  In 
> >>>> this thread [1], Jarkko is saying CA based infrastructure should be a policy 
> >>>> decision not to be enforced by the kernel. Wouldn’t this apply here as well?
> >>>> 
> >>>> 1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/
> >>> 
> >>> Mickaël said, "This change is critical and should be tied to a
> >>> dedicated kernel config
> >>> (disabled by default), otherwise existing systems using this feature
> >>> will have their threat model automatically changed without notice."
> >> 
> >> I was thinking he meant it is critical not to change the current behavior
> >> by limiting blacklisting to only CA keys.  Not that it was critical to add
> >> CA enforcement.  Maybe Mickaël can comment?
> > 
> > I meant that applying this patch as-is may change the threat model used
> > by some users. Currently, only signed hashes vouched by the builtin
> > trusted keyring are valid. If we extend this mechanism to the secondary
> > trusted keyring without notice, this means that more certificates could
> > vouch blacklisted hashes, which may include some certificates with an
> > initial different usage.
> > 
> > See commit 4da8f8c8a1e0 ("dm verity: Add support for signature
> > verification with 2nd keyring") that adds
> > CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING:
> > https://lore.kernel.org/all/20201023170512.201124-1-mic@digikod.net/
> 
> Thanks for clarifying.  I’ll add something similar in v2.
> 
> >> 
> >>> As a possible alternative I suggested limiting which file hashes the
> >>> certs on the secondary (or machine) keyring could blacklist.
> >> 
> >> I’m not sure I completely understand your suggestion here.
> >> Do you mean, verify the CA bit is set for secondary keys, but
> >> ignore the bit for builtin?  And then only use those keys to add
> >> hashes to the blacklist keyring?  If I have that right, what would 
> >> be the justification for the change based on how things currently
> >> get included in the blacklist keyring?  Thanks.
> > 
> > I'd like to be able to specify which kind of certificate can vouch for
> > blacklisting hashes, and for other usages, but AFAIK this is not the
> > path Linux has followed (e.g. unlike Windows). We only have the keyring
> > to identify an usage, which is unfortunate. On the other side, this
> > approach lets users manage their certificates without constraint, which
> > is quite (too?) flexible.
> 
> Yes, it is very flexible. What I believe Mimi is after is having a way to 
> track what cert actually vouched for each specific binary hash.  But this
> information is not tracked, plus entries within it can come from various 
> sources that are not signed (dbx, mokx, compiled in).  Also key usage is 
> being ignored.
> 
> > A complementary approach would be to create an
> > LSM (or a dedicated interface) to tie certificate properties to a set of
> > kernel usages, while still letting users configure these constraints.
> 
> That is an interesting idea.  Would the other security maintainers be in 
> support of such an approach?  Would a LSM be the correct interface?  
> Some of the recent work I have done with introducing key usage and CA 
> enforcement is difficult for a distro to pick up, since these changes can be 
> viewed as a regression.  Each end-user has different signing procedures 
> and policies, so making something work for everyone is difficult.  Letting the 
> user configure these constraints would solve this problem.
> 

RFC: New LSM to control usage of x509 certificates

[Mickaël Salaün]

The initial subject was "Re: [PATCH] certs: Restrict blacklist updates
to the secondary trusted keyring":
https://lore.kernel.org/all/20230908213428.731513-1-eric.snowberg@oracle.com/

On Thu, Sep 14, 2023 at 10:34:44AM +0200, Mickaël Salaün wrote:
> CCing the LSM mailing list for this potential new LSM proposal:
> 
> On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote:
> > 
> > 
> > > On Sep 13, 2023, at 4:21 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > > 
> > > On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
> > >> 
> > >> 
> > >>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >>> 
> > >>> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
> > >>>> 
> > >>>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >>>>> 
> > >>>>> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
> > >>>>>> 
> > >>>>>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >>>>>>> 
> > >>>>>>> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
> > >>>>>>>> 
> > >>>>>>>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > >>>>>>>>> 
> > >>>>>>>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
> > >>>>>>>>>> Hi Eric,
> > >>>>>>>>>> 
> > >>>>>>>>>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> > >>>>>>>>>>> Currently root can dynamically update the blacklist keyring if the hash
> > >>>>>>>>>>> being added is signed and vouched for by the builtin trusted keyring.
> > >>>>>>>>>>> Currently keys in the secondary trusted keyring can not be used.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> Keys within the secondary trusted keyring carry the same capabilities as
> > >>>>>>>>>>> the builtin trusted keyring.  Relax the current restriction for updating
> > >>>>>>>>>>> the .blacklist keyring and allow the secondary to also be referenced as
> > >>>>>>>>>>> a trust source.  Since the machine keyring is linked to the secondary
> > >>>>>>>>>>> trusted keyring, any key within it may also be used.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> An example use case for this is IMA appraisal.  Now that IMA both
> > >>>>>>>>>>> references the blacklist keyring and allows the machine owner to add
> > >>>>>>>>>>> custom IMA CA certs via the machine keyring, this adds the additional
> > >>>>>>>>>>> capability for the machine owner to also do revocations on a running
> > >>>>>>>>>>> system.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> IMA appraisal usage example to add a revocation for /usr/foo:
> > >>>>>>>>>>> 
> > >>>>>>>>>>> sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> > >>>>>>>>>>> 
> > >>>>>>>>>>> openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> > >>>>>>>>>>>   -signer machine-certificate.pem -noattr -binary -outform DER \
> > >>>>>>>>>>>   -out hash.p7s
> > >>>>>>>>>>> 
> > >>>>>>>>>>> keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> > >>>>>>>>>>> 
> > >>>>>>>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> > >>>>>>>>>> 
> > >>>>>>>>>> The secondary keyring may include both CA and code signing keys.  With
> > >>>>>>>>>> this change any key loaded onto the secondary keyring may blacklist a
> > >>>>>>>>>> hash.  Wouldn't it make more sense to limit blacklisting
> > >>>>>>>>>> certificates/hashes to at least CA keys? 
> > >>>>>>>>> 
> > >>>>>>>>> Some operational constraints may limit what a CA can sign.
> > >>>>>>>> 
> > >>>>>>>> Agreed.  
> > >>>>>>>> 
> > >>>>>>>> Is there precedents for requiring this S/MIME to be signed by a CA? 
> > >>>>>>>> 
> > >>>>>>>>> This change is critical and should be tied to a dedicated kernel config
> > >>>>>>>>> (disabled by default), otherwise existing systems using this feature
> > >>>>>>>>> will have their threat model automatically changed without notice.
> > >>>>>>>> 
> > >>>>>>>> Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
> > >>>>>>>> be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
> > >>>>>>>> this be a suitable solution for what you are after?
> > >>>>>>> 
> > >>>>>>> There needs to be some correlation between the file hashes being added
> > >>>>>>> to the blacklist and the certificate that signed them.  Without that
> > >>>>>>> correlation, any key on the secondary trusted keyring could add any
> > >>>>>>> file hashes it wants to the blacklist.
> > >>>>>> 
> > >>>>>> Today any key in the secondary trusted keyring can be used to validate a 
> > >>>>>> signed kernel module.  At a later time, if a new hash is added to the blacklist 
> > >>>>>> keyring to revoke loading a signed kernel module,  the ability to do the 
> > >>>>>> revocation with this additional change would be more restrictive than loading 
> > >>>>>> the original module.
> > >>>>> 
> > >>>>> A public key on the secondary keyring is used to verify code that it
> > >>>>> signed, but does not impact any other code. Allowing any public key on
> > >>>>> the secondary keyring to blacklist any file hash is giving it more
> > >>>>> privileges than it originally had.
> > >>>>> 
> > >>>>> This requirement isn't different than how Certificate Revocation List
> > >>>>> (CRL) work.  Not any CA can revoke a certificate.
> > >>>> 
> > >>>> In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
> > >>>> Root can update the DBX on a host.  The requirement placed on updating 
> > >>>> it is the new DBX entry must be signed by any key contained within the 
> > >>>> KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
> > >>>> There is not a requirement similar to how CRL’s work here, any KEK key 
> > >>>> can be used.
> > >>>> 
> > >>>> With architectures booted through a shim there is the MOKX.  Similar to 
> > >>>> DBX, MOKX have the same capabilities, however they do not need to be 
> > >>>> signed by any key, the machine owner must show they have physical 
> > >>>> presence (and potentially a MOK password) for inclusion.  Again there 
> > >>>> is not a requirement similar to how CRL’s work here either.  The machine 
> > >>>> owner can decide what is included.
> > >>>> 
> > >>>> Today when a kernel is built, any number of keys may be included within 
> > >>>> the builtin trusted keyring.  The keys included in the kernel may not have 
> > >>>> a single usage field set or the CA bit set.  There are no requirements on 
> > >>>> how these keys get used later on.  Any key in the builtin trusted keyring 
> > >>>> can be used to sign a revocation that can be added to the blacklist keyring.  
> > >>>> Additionally, any key in the MOK can be used to sign this kernel and it will 
> > >>>> boot.  Before booting the kernel, MOK keys have more privileges than 
> > >>>> after the kernel is booted in some instances.
> > >>>> 
> > >>>> Today MOK keys can be loaded into the machine keyring.  These keys get 
> > >>>> linked to the secondary trusted keyring.  Currently key usage enforcement
> > >>>> is being applied to these keys behind some Kconfig options.  By default 
> > >>>> anything in the secondary has the same capabilities as the builtin trusted 
> > >>>> keyring.  What is challenging here with this request is the inconsistency 
> > >>>> between how everything else currently works. 
> > >>>> 
> > >>>> Root can not arbitrarily add things to the secondary trusted keyring.  These 
> > >>>> keys must be signed by something in either the machine or the builtin.  In 
> > >>>> this thread [1], Jarkko is saying CA based infrastructure should be a policy 
> > >>>> decision not to be enforced by the kernel. Wouldn’t this apply here as well?
> > >>>> 
> > >>>> 1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/
> > >>> 
> > >>> Mickaël said, "This change is critical and should be tied to a
> > >>> dedicated kernel config
> > >>> (disabled by default), otherwise existing systems using this feature
> > >>> will have their threat model automatically changed without notice."
> > >> 
> > >> I was thinking he meant it is critical not to change the current behavior
> > >> by limiting blacklisting to only CA keys.  Not that it was critical to add
> > >> CA enforcement.  Maybe Mickaël can comment?
> > > 
> > > I meant that applying this patch as-is may change the threat model used
> > > by some users. Currently, only signed hashes vouched by the builtin
> > > trusted keyring are valid. If we extend this mechanism to the secondary
> > > trusted keyring without notice, this means that more certificates could
> > > vouch blacklisted hashes, which may include some certificates with an
> > > initial different usage.
> > > 
> > > See commit 4da8f8c8a1e0 ("dm verity: Add support for signature
> > > verification with 2nd keyring") that adds
> > > CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING:
> > > https://lore.kernel.org/all/20201023170512.201124-1-mic@digikod.net/
> > 
> > Thanks for clarifying.  I’ll add something similar in v2.
> > 
> > >> 
> > >>> As a possible alternative I suggested limiting which file hashes the
> > >>> certs on the secondary (or machine) keyring could blacklist.
> > >> 
> > >> I’m not sure I completely understand your suggestion here.
> > >> Do you mean, verify the CA bit is set for secondary keys, but
> > >> ignore the bit for builtin?  And then only use those keys to add
> > >> hashes to the blacklist keyring?  If I have that right, what would 
> > >> be the justification for the change based on how things currently
> > >> get included in the blacklist keyring?  Thanks.
> > > 
> > > I'd like to be able to specify which kind of certificate can vouch for
> > > blacklisting hashes, and for other usages, but AFAIK this is not the
> > > path Linux has followed (e.g. unlike Windows). We only have the keyring
> > > to identify an usage, which is unfortunate. On the other side, this
> > > approach lets users manage their certificates without constraint, which
> > > is quite (too?) flexible.
> > 
> > Yes, it is very flexible. What I believe Mimi is after is having a way to 
> > track what cert actually vouched for each specific binary hash.  But this
> > information is not tracked, plus entries within it can come from various 
> > sources that are not signed (dbx, mokx, compiled in).  Also key usage is 
> > being ignored.
> > 
> > > A complementary approach would be to create an
> > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > kernel usages, while still letting users configure these constraints.
> > 
> > That is an interesting idea.  Would the other security maintainers be in 
> > support of such an approach?  Would a LSM be the correct interface?  
> > Some of the recent work I have done with introducing key usage and CA 
> > enforcement is difficult for a distro to pick up, since these changes can be 
> > viewed as a regression.  Each end-user has different signing procedures 
> > and policies, so making something work for everyone is difficult.  Letting the 
> > user configure these constraints would solve this problem.
> > 

Re: RFC: New LSM to control usage of x509 certificates

[Paul Moore]

On Thu, Oct 5, 2023 at 6:32 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> The initial subject was "Re: [PATCH] certs: Restrict blacklist updates
> to the secondary trusted keyring":
> https://lore.kernel.org/all/20230908213428.731513-1-eric.snowberg@oracle.com/
>
> On Thu, Sep 14, 2023 at 10:34:44AM +0200, Mickaël Salaün wrote:
> > CCing the LSM mailing list for this potential new LSM proposal:
> > On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote:
> > > > On Sep 13, 2023, at 4:21 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > > > On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
> > > >>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:

[Just a reminder that trimming massive emails to the relevant portions
is a nice thing to do]

> > > > A complementary approach would be to create an
> > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > kernel usages, while still letting users configure these constraints.
> > >
> > > That is an interesting idea.  Would the other security maintainers be in
> > > support of such an approach?  Would a LSM be the correct interface?
> > > Some of the recent work I have done with introducing key usage and CA
> > > enforcement is difficult for a distro to pick up, since these changes can be
> > > viewed as a regression.  Each end-user has different signing procedures
> > > and policies, so making something work for everyone is difficult.  Letting the
> > > user configure these constraints would solve this problem.

I can't say that I have been following this thread very closely, but I
see no reason why we wouldn't support a LSM that enforces access
controls on certificates/keys based on their attributes/properties.
We do have some LSM control points for the kernel keyring, which are
used by at least one LSM, but I'm sure you would probably need some
additional control points.

If you are interested in pursuing the creation of a new LSM, and
likely new LSM hooks, we do have some documented guidelines you should
keep in mind:

* https://github.com/LinuxSecurityModule/kernel/blob/main/README.md

-- 
paul-moore.com

Re: RFC: New LSM to control usage of x509 certificates

[Mimi Zohar]

On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> > > > A complementary approach would be to create an
> > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > kernel usages, while still letting users configure these constraints.
> > > 
> > > That is an interesting idea.  Would the other security maintainers be in 
> > > support of such an approach?  Would a LSM be the correct interface?  
> > > Some of the recent work I have done with introducing key usage and CA 
> > > enforcement is difficult for a distro to pick up, since these changes can be 
> > > viewed as a regression.  Each end-user has different signing procedures 
> > > and policies, so making something work for everyone is difficult.  Letting the 
> > > user configure these constraints would solve this problem.

Something definitely needs to be done about controlling the usage of
x509 certificates.  My concern is the level of granularity.  Would this
be at the LSM hook level or even finer granaularity?

-- 
thanks,

Mimi

Re: RFC: New LSM to control usage of x509 certificates

[Paul Moore]

On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> > > > > A complementary approach would be to create an
> > > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > > kernel usages, while still letting users configure these constraints.
> > > >
> > > > That is an interesting idea.  Would the other security maintainers be in
> > > > support of such an approach?  Would a LSM be the correct interface?
> > > > Some of the recent work I have done with introducing key usage and CA
> > > > enforcement is difficult for a distro to pick up, since these changes can be
> > > > viewed as a regression.  Each end-user has different signing procedures
> > > > and policies, so making something work for everyone is difficult.  Letting the
> > > > user configure these constraints would solve this problem.
>
> Something definitely needs to be done about controlling the usage of
> x509 certificates.  My concern is the level of granularity.  Would this
> be at the LSM hook level or even finer granaularity?

You lost me, what do you mean by finer granularity than a LSM-based
access control?  Can you give an existing example in the Linux kernel
of access control granularity that is finer grained than what is
provided by the LSMs?

-- 
paul-moore.com

Re: RFC: New LSM to control usage of x509 certificates

[Mimi Zohar]

On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> > > > > > A complementary approach would be to create an
> > > > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > > > kernel usages, while still letting users configure these constraints.
> > > > >
> > > > > That is an interesting idea.  Would the other security maintainers be in
> > > > > support of such an approach?  Would a LSM be the correct interface?
> > > > > Some of the recent work I have done with introducing key usage and CA
> > > > > enforcement is difficult for a distro to pick up, since these changes can be
> > > > > viewed as a regression.  Each end-user has different signing procedures
> > > > > and policies, so making something work for everyone is difficult.  Letting the
> > > > > user configure these constraints would solve this problem.
> >
> > Something definitely needs to be done about controlling the usage of
> > x509 certificates.  My concern is the level of granularity.  Would this
> > be at the LSM hook level or even finer granaularity?
> 
> You lost me, what do you mean by finer granularity than a LSM-based
> access control?  Can you give an existing example in the Linux kernel
> of access control granularity that is finer grained than what is
> provided by the LSMs?

The current x509 certificate access control granularity is at the
keyring level.  Any key on the keyring may be used to verify a
signature.  Finer granularity could associate a set of certificates on
a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
firmware, etc.  Even finer granularity could somehow limit a key's
signature verification to files in particular software package(s) for
example.

Perhaps Mickaël and Eric were thinking about a new LSM to control usage
of x509 certificates from a totally different perspective.  I'd like to
hear what they're thinking.

I hope this addressed your questions.

-- 
thanks,

Mimi

Re: RFC: New LSM to control usage of x509 certificates

[Paul Moore]

On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> > On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> > > > > > > A complementary approach would be to create an
> > > > > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > > > > kernel usages, while still letting users configure these constraints.
> > > > > >
> > > > > > That is an interesting idea.  Would the other security maintainers be in
> > > > > > support of such an approach?  Would a LSM be the correct interface?
> > > > > > Some of the recent work I have done with introducing key usage and CA
> > > > > > enforcement is difficult for a distro to pick up, since these changes can be
> > > > > > viewed as a regression.  Each end-user has different signing procedures
> > > > > > and policies, so making something work for everyone is difficult.  Letting the
> > > > > > user configure these constraints would solve this problem.
> > >
> > > Something definitely needs to be done about controlling the usage of
> > > x509 certificates.  My concern is the level of granularity.  Would this
> > > be at the LSM hook level or even finer granaularity?
> >
> > You lost me, what do you mean by finer granularity than a LSM-based
> > access control?  Can you give an existing example in the Linux kernel
> > of access control granularity that is finer grained than what is
> > provided by the LSMs?
>
> The current x509 certificate access control granularity is at the
> keyring level.  Any key on the keyring may be used to verify a
> signature.  Finer granularity could associate a set of certificates on
> a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
> firmware, etc.  Even finer granularity could somehow limit a key's
> signature verification to files in particular software package(s) for
> example.
>
> Perhaps Mickaël and Eric were thinking about a new LSM to control usage
> of x509 certificates from a totally different perspective.  I'd like to
> hear what they're thinking.
>
> I hope this addressed your questions.

Okay, so you were talking about finer granularity when compared to the
*current* LSM keyring hooks.  Gotcha.

If we need additional, or modified, hooks that shouldn't be a problem.
Although I'm guessing the answer is going to be moving towards
purpose/operation specific keyrings which might fit in well with the
current keyring level controls.

-- 
paul-moore.com

Re: RFC: New LSM to control usage of x509 certificates

[Mimi Zohar]

On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> > > On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> > > > > > > > A complementary approach would be to create an
> > > > > > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > > > > > kernel usages, while still letting users configure these constraints.
> > > > > > >
> > > > > > > That is an interesting idea.  Would the other security maintainers be in
> > > > > > > support of such an approach?  Would a LSM be the correct interface?
> > > > > > > Some of the recent work I have done with introducing key usage and CA
> > > > > > > enforcement is difficult for a distro to pick up, since these changes can be
> > > > > > > viewed as a regression.  Each end-user has different signing procedures
> > > > > > > and policies, so making something work for everyone is difficult.  Letting the
> > > > > > > user configure these constraints would solve this problem.
> > > >
> > > > Something definitely needs to be done about controlling the usage of
> > > > x509 certificates.  My concern is the level of granularity.  Would this
> > > > be at the LSM hook level or even finer granaularity?
> > >
> > > You lost me, what do you mean by finer granularity than a LSM-based
> > > access control?  Can you give an existing example in the Linux kernel
> > > of access control granularity that is finer grained than what is
> > > provided by the LSMs?
> >
> > The current x509 certificate access control granularity is at the
> > keyring level.  Any key on the keyring may be used to verify a
> > signature.  Finer granularity could associate a set of certificates on
> > a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
> > firmware, etc.  Even finer granularity could somehow limit a key's
> > signature verification to files in particular software package(s) for
> > example.
> >
> > Perhaps Mickaël and Eric were thinking about a new LSM to control usage
> > of x509 certificates from a totally different perspective.  I'd like to
> > hear what they're thinking.
> >
> > I hope this addressed your questions.
> 
> Okay, so you were talking about finer granularity when compared to the
> *current* LSM keyring hooks.  Gotcha.
> 
> If we need additional, or modified, hooks that shouldn't be a problem.
> Although I'm guessing the answer is going to be moving towards
> purpose/operation specific keyrings which might fit in well with the
> current keyring level controls.

I don't believe defining per purpose/operation specific keyrings will
resolve the underlying problem of granularity.  For example, different
applications could be signed with different keys and should only be
verified with the specific key.

-- 
thanks,

Mimi

Re: RFC: New LSM to control usage of x509 certificates

[Paul Moore]

On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
> > On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> > > > On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> > > > > > > > > A complementary approach would be to create an
> > > > > > > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > > > > > > kernel usages, while still letting users configure these constraints.
> > > > > > > >
> > > > > > > > That is an interesting idea.  Would the other security maintainers be in
> > > > > > > > support of such an approach?  Would a LSM be the correct interface?
> > > > > > > > Some of the recent work I have done with introducing key usage and CA
> > > > > > > > enforcement is difficult for a distro to pick up, since these changes can be
> > > > > > > > viewed as a regression.  Each end-user has different signing procedures
> > > > > > > > and policies, so making something work for everyone is difficult.  Letting the
> > > > > > > > user configure these constraints would solve this problem.
> > > > >
> > > > > Something definitely needs to be done about controlling the usage of
> > > > > x509 certificates.  My concern is the level of granularity.  Would this
> > > > > be at the LSM hook level or even finer granaularity?
> > > >
> > > > You lost me, what do you mean by finer granularity than a LSM-based
> > > > access control?  Can you give an existing example in the Linux kernel
> > > > of access control granularity that is finer grained than what is
> > > > provided by the LSMs?
> > >
> > > The current x509 certificate access control granularity is at the
> > > keyring level.  Any key on the keyring may be used to verify a
> > > signature.  Finer granularity could associate a set of certificates on
> > > a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
> > > firmware, etc.  Even finer granularity could somehow limit a key's
> > > signature verification to files in particular software package(s) for
> > > example.
> > >
> > > Perhaps Mickaël and Eric were thinking about a new LSM to control usage
> > > of x509 certificates from a totally different perspective.  I'd like to
> > > hear what they're thinking.
> > >
> > > I hope this addressed your questions.
> >
> > Okay, so you were talking about finer granularity when compared to the
> > *current* LSM keyring hooks.  Gotcha.
> >
> > If we need additional, or modified, hooks that shouldn't be a problem.
> > Although I'm guessing the answer is going to be moving towards
> > purpose/operation specific keyrings which might fit in well with the
> > current keyring level controls.
>
> I don't believe defining per purpose/operation specific keyrings will
> resolve the underlying problem of granularity.

Perhaps not completely, but for in-kernel operations I believe it is
an attractive idea.

-- 
paul-moore.com

Re: RFC: New LSM to control usage of x509 certificates

[Eric Snowberg]

> On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
>>> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
>>>>> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
>>>>>>>>>> A complementary approach would be to create an
>>>>>>>>>> LSM (or a dedicated interface) to tie certificate properties to a set of
>>>>>>>>>> kernel usages, while still letting users configure these constraints.
>>>>>>>>> 
>>>>>>>>> That is an interesting idea.  Would the other security maintainers be in
>>>>>>>>> support of such an approach?  Would a LSM be the correct interface?
>>>>>>>>> Some of the recent work I have done with introducing key usage and CA
>>>>>>>>> enforcement is difficult for a distro to pick up, since these changes can be
>>>>>>>>> viewed as a regression.  Each end-user has different signing procedures
>>>>>>>>> and policies, so making something work for everyone is difficult.  Letting the
>>>>>>>>> user configure these constraints would solve this problem.
>>>>>> 
>>>>>> Something definitely needs to be done about controlling the usage of
>>>>>> x509 certificates.  My concern is the level of granularity.  Would this
>>>>>> be at the LSM hook level or even finer granaularity?
>>>>> 
>>>>> You lost me, what do you mean by finer granularity than a LSM-based
>>>>> access control?  Can you give an existing example in the Linux kernel
>>>>> of access control granularity that is finer grained than what is
>>>>> provided by the LSMs?
>>>> 
>>>> The current x509 certificate access control granularity is at the
>>>> keyring level.  Any key on the keyring may be used to verify a
>>>> signature.  Finer granularity could associate a set of certificates on
>>>> a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
>>>> firmware, etc.  Even finer granularity could somehow limit a key's
>>>> signature verification to files in particular software package(s) for
>>>> example.
>>>> 
>>>> Perhaps Mickaël and Eric were thinking about a new LSM to control usage
>>>> of x509 certificates from a totally different perspective.  I'd like to
>>>> hear what they're thinking.
>>>> 
>>>> I hope this addressed your questions.
>>> 
>>> Okay, so you were talking about finer granularity when compared to the
>>> *current* LSM keyring hooks.  Gotcha.
>>> 
>>> If we need additional, or modified, hooks that shouldn't be a problem.
>>> Although I'm guessing the answer is going to be moving towards
>>> purpose/operation specific keyrings which might fit in well with the
>>> current keyring level controls.
>> 
>> I don't believe defining per purpose/operation specific keyrings will
>> resolve the underlying problem of granularity.
> 
> Perhaps not completely, but for in-kernel operations I believe it is
> an attractive idea.

Could the X.509 Extended Key Usage (EKU) extension [1], be used here?  
Various OIDs would need to be defined or assigned for each purpose.  
Once assigned, the kernel could parse this information and do the
enforcement.  Then all keys could continue to remain in the .builtin, 
.secondary, and .machine keyrings.   Only a subset of each keyring 
would be used for verification based on what is contained in the EKU.

1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12

Re: RFC: New LSM to control usage of x509 certificates

[Mickaël Salaün]

On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:
> 
> 
> > On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
> > 
> > On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
> >>> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> >>>>> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> >>>>>>>>>> A complementary approach would be to create an
> >>>>>>>>>> LSM (or a dedicated interface) to tie certificate properties to a set of
> >>>>>>>>>> kernel usages, while still letting users configure these constraints.
> >>>>>>>>> 
> >>>>>>>>> That is an interesting idea.  Would the other security maintainers be in
> >>>>>>>>> support of such an approach?  Would a LSM be the correct interface?
> >>>>>>>>> Some of the recent work I have done with introducing key usage and CA
> >>>>>>>>> enforcement is difficult for a distro to pick up, since these changes can be
> >>>>>>>>> viewed as a regression.  Each end-user has different signing procedures
> >>>>>>>>> and policies, so making something work for everyone is difficult.  Letting the
> >>>>>>>>> user configure these constraints would solve this problem.
> >>>>>> 
> >>>>>> Something definitely needs to be done about controlling the usage of
> >>>>>> x509 certificates.  My concern is the level of granularity.  Would this
> >>>>>> be at the LSM hook level or even finer granaularity?
> >>>>> 
> >>>>> You lost me, what do you mean by finer granularity than a LSM-based
> >>>>> access control?  Can you give an existing example in the Linux kernel
> >>>>> of access control granularity that is finer grained than what is
> >>>>> provided by the LSMs?
> >>>> 
> >>>> The current x509 certificate access control granularity is at the
> >>>> keyring level.  Any key on the keyring may be used to verify a
> >>>> signature.  Finer granularity could associate a set of certificates on
> >>>> a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
> >>>> firmware, etc.  Even finer granularity could somehow limit a key's
> >>>> signature verification to files in particular software package(s) for
> >>>> example.
> >>>> 
> >>>> Perhaps Mickaël and Eric were thinking about a new LSM to control usage
> >>>> of x509 certificates from a totally different perspective.  I'd like to
> >>>> hear what they're thinking.
> >>>> 
> >>>> I hope this addressed your questions.
> >>> 
> >>> Okay, so you were talking about finer granularity when compared to the
> >>> *current* LSM keyring hooks.  Gotcha.
> >>> 
> >>> If we need additional, or modified, hooks that shouldn't be a problem.
> >>> Although I'm guessing the answer is going to be moving towards
> >>> purpose/operation specific keyrings which might fit in well with the
> >>> current keyring level controls.
> >> 
> >> I don't believe defining per purpose/operation specific keyrings will
> >> resolve the underlying problem of granularity.
> > 
> > Perhaps not completely, but for in-kernel operations I believe it is
> > an attractive idea.
> 
> Could the X.509 Extended Key Usage (EKU) extension [1], be used here?  
> Various OIDs would need to be defined or assigned for each purpose.  
> Once assigned, the kernel could parse this information and do the
> enforcement.  Then all keys could continue to remain in the .builtin, 
> .secondary, and .machine keyrings.   Only a subset of each keyring 
> would be used for verification based on what is contained in the EKU.
> 
> 1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12

I was also thinking about this kind of use cases. Because it might be
difficult in practice to control all certificate properties, we might
want to let sysadmins configure these subset of keyring according to
various certificate properties. There are currently LSM hooks to control
interactions with kernel keys by user space, and keys are already tied
to LSM blobs. New LSM hooks could be added to dynamically filter
keyrings according to kernel usages (e.g. kernel module verification, a
subset of an authentication mechanism according to the checked object).

Re: RFC: New LSM to control usage of x509 certificates

[Eric Snowberg]

> On Oct 18, 2023, at 8:14 AM, Mickaël Salaün <mic@digikod.net> wrote:
> 
> On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:
>> 
>> 
>>> On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> 
>>> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
>>>>> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
>>>>>>> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>>>> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
>>>>>>>>>>>> A complementary approach would be to create an
>>>>>>>>>>>> LSM (or a dedicated interface) to tie certificate properties to a set of
>>>>>>>>>>>> kernel usages, while still letting users configure these constraints.
>>>>>>>>>>> 
>>>>>>>>>>> That is an interesting idea.  Would the other security maintainers be in
>>>>>>>>>>> support of such an approach?  Would a LSM be the correct interface?
>>>>>>>>>>> Some of the recent work I have done with introducing key usage and CA
>>>>>>>>>>> enforcement is difficult for a distro to pick up, since these changes can be
>>>>>>>>>>> viewed as a regression.  Each end-user has different signing procedures
>>>>>>>>>>> and policies, so making something work for everyone is difficult.  Letting the
>>>>>>>>>>> user configure these constraints would solve this problem.
>>>>>>>> 
>>>>>>>> Something definitely needs to be done about controlling the usage of
>>>>>>>> x509 certificates.  My concern is the level of granularity.  Would this
>>>>>>>> be at the LSM hook level or even finer granaularity?
>>>>>>> 
>>>>>>> You lost me, what do you mean by finer granularity than a LSM-based
>>>>>>> access control?  Can you give an existing example in the Linux kernel
>>>>>>> of access control granularity that is finer grained than what is
>>>>>>> provided by the LSMs?
>>>>>> 
>>>>>> The current x509 certificate access control granularity is at the
>>>>>> keyring level.  Any key on the keyring may be used to verify a
>>>>>> signature.  Finer granularity could associate a set of certificates on
>>>>>> a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
>>>>>> firmware, etc.  Even finer granularity could somehow limit a key's
>>>>>> signature verification to files in particular software package(s) for
>>>>>> example.
>>>>>> 
>>>>>> Perhaps Mickaël and Eric were thinking about a new LSM to control usage
>>>>>> of x509 certificates from a totally different perspective.  I'd like to
>>>>>> hear what they're thinking.
>>>>>> 
>>>>>> I hope this addressed your questions.
>>>>> 
>>>>> Okay, so you were talking about finer granularity when compared to the
>>>>> *current* LSM keyring hooks.  Gotcha.
>>>>> 
>>>>> If we need additional, or modified, hooks that shouldn't be a problem.
>>>>> Although I'm guessing the answer is going to be moving towards
>>>>> purpose/operation specific keyrings which might fit in well with the
>>>>> current keyring level controls.
>>>> 
>>>> I don't believe defining per purpose/operation specific keyrings will
>>>> resolve the underlying problem of granularity.
>>> 
>>> Perhaps not completely, but for in-kernel operations I believe it is
>>> an attractive idea.
>> 
>> Could the X.509 Extended Key Usage (EKU) extension [1], be used here?  
>> Various OIDs would need to be defined or assigned for each purpose.  
>> Once assigned, the kernel could parse this information and do the
>> enforcement.  Then all keys could continue to remain in the .builtin, 
>> .secondary, and .machine keyrings.   Only a subset of each keyring 
>> would be used for verification based on what is contained in the EKU.
>> 
>> 1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12
> 
> I was also thinking about this kind of use cases. Because it might be
> difficult in practice to control all certificate properties, we might
> want to let sysadmins configure these subset of keyring according to
> various certificate properties.

I agree, a configuration component for a sysadmin would be needed.

> There are currently LSM hooks to control
> interactions with kernel keys by user space, and keys are already tied
> to LSM blobs. New LSM hooks could be added to dynamically filter
> keyrings according to kernel usages (e.g. kernel module verification, a
> subset of an authentication mechanism according to the checked object).

If an LSM hook could dynamically filter keyrings, and the EKU was used, 
is there an opinion on how flexible this should be?  Meaning, should there 
be OIDs defined and carried in mainline code?  This would make it easier 
to setup and use.  However who would be the initial OID owner?  Or would 
predefined OIDs not be contained within mainline code, leaving it to the 
sysadmin to create a policy that would be fed to the LSM to do the filtering.

Re: RFC: New LSM to control usage of x509 certificates

[Mickaël Salaün]

On Wed, Oct 18, 2023 at 11:12:45PM +0000, Eric Snowberg wrote:
> 
> 
> > On Oct 18, 2023, at 8:14 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > 
> > On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:
> >> 
> >> 
> >>> On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
> >>> 
> >>> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
> >>>>> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> >>>>>>> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>>>> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> >>>>>>>>>>>> A complementary approach would be to create an
> >>>>>>>>>>>> LSM (or a dedicated interface) to tie certificate properties to a set of
> >>>>>>>>>>>> kernel usages, while still letting users configure these constraints.
> >>>>>>>>>>> 
> >>>>>>>>>>> That is an interesting idea.  Would the other security maintainers be in
> >>>>>>>>>>> support of such an approach?  Would a LSM be the correct interface?
> >>>>>>>>>>> Some of the recent work I have done with introducing key usage and CA
> >>>>>>>>>>> enforcement is difficult for a distro to pick up, since these changes can be
> >>>>>>>>>>> viewed as a regression.  Each end-user has different signing procedures
> >>>>>>>>>>> and policies, so making something work for everyone is difficult.  Letting the
> >>>>>>>>>>> user configure these constraints would solve this problem.
> >>>>>>>> 
> >>>>>>>> Something definitely needs to be done about controlling the usage of
> >>>>>>>> x509 certificates.  My concern is the level of granularity.  Would this
> >>>>>>>> be at the LSM hook level or even finer granaularity?
> >>>>>>> 
> >>>>>>> You lost me, what do you mean by finer granularity than a LSM-based
> >>>>>>> access control?  Can you give an existing example in the Linux kernel
> >>>>>>> of access control granularity that is finer grained than what is
> >>>>>>> provided by the LSMs?
> >>>>>> 
> >>>>>> The current x509 certificate access control granularity is at the
> >>>>>> keyring level.  Any key on the keyring may be used to verify a
> >>>>>> signature.  Finer granularity could associate a set of certificates on
> >>>>>> a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
> >>>>>> firmware, etc.  Even finer granularity could somehow limit a key's
> >>>>>> signature verification to files in particular software package(s) for
> >>>>>> example.
> >>>>>> 
> >>>>>> Perhaps Mickaël and Eric were thinking about a new LSM to control usage
> >>>>>> of x509 certificates from a totally different perspective.  I'd like to
> >>>>>> hear what they're thinking.
> >>>>>> 
> >>>>>> I hope this addressed your questions.
> >>>>> 
> >>>>> Okay, so you were talking about finer granularity when compared to the
> >>>>> *current* LSM keyring hooks.  Gotcha.
> >>>>> 
> >>>>> If we need additional, or modified, hooks that shouldn't be a problem.
> >>>>> Although I'm guessing the answer is going to be moving towards
> >>>>> purpose/operation specific keyrings which might fit in well with the
> >>>>> current keyring level controls.
> >>>> 
> >>>> I don't believe defining per purpose/operation specific keyrings will
> >>>> resolve the underlying problem of granularity.
> >>> 
> >>> Perhaps not completely, but for in-kernel operations I believe it is
> >>> an attractive idea.
> >> 
> >> Could the X.509 Extended Key Usage (EKU) extension [1], be used here?  
> >> Various OIDs would need to be defined or assigned for each purpose.  
> >> Once assigned, the kernel could parse this information and do the
> >> enforcement.  Then all keys could continue to remain in the .builtin, 
> >> .secondary, and .machine keyrings.   Only a subset of each keyring 
> >> would be used for verification based on what is contained in the EKU.
> >> 
> >> 1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12
> > 
> > I was also thinking about this kind of use cases. Because it might be
> > difficult in practice to control all certificate properties, we might
> > want to let sysadmins configure these subset of keyring according to
> > various certificate properties.
> 
> I agree, a configuration component for a sysadmin would be needed.
> 
> > There are currently LSM hooks to control
> > interactions with kernel keys by user space, and keys are already tied
> > to LSM blobs. New LSM hooks could be added to dynamically filter
> > keyrings according to kernel usages (e.g. kernel module verification, a
> > subset of an authentication mechanism according to the checked object).
> 
> If an LSM hook could dynamically filter keyrings, and the EKU was used, 
> is there an opinion on how flexible this should be?  Meaning, should there 
> be OIDs defined and carried in mainline code?  This would make it easier 
> to setup and use.  However who would be the initial OID owner?  Or would 
> predefined OIDs not be contained within mainline code, leaving it to the 
> sysadmin to create a policy that would be fed to the LSM to do the filtering.

The more flexible approach would be to not hardcode any policy in the
kernel but let sysadmins define their own, including OIDs. We "just"
need to find an adequate configuration scheme to define these
constraints. We already have an ASN.1 parser in the kernel, so we might
want to leverage that to match a certificate. Another option would be to
rely on an eBPF program to filter certificates but I'm not sure how
complex it could get. Maybe exposing the ASN.1 parser to eBPF? :)

Re: RFC: New LSM to control usage of x509 certificates

[Eric Snowberg]

> On Oct 19, 2023, at 3:12 AM, Mickaël Salaün <mic@digikod.net> wrote:
> 
> On Wed, Oct 18, 2023 at 11:12:45PM +0000, Eric Snowberg wrote:
>> 
>> 
>>> On Oct 18, 2023, at 8:14 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>> 
>>> On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:
>>>> 
>>>> 
>>>>> On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>>> 
>>>>> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
>>>>>>> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>>>> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
>>>>>>>>> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>>>>>> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
>>>>>>>>>>>>>> A complementary approach would be to create an
>>>>>>>>>>>>>> LSM (or a dedicated interface) to tie certificate properties to a set of
>>>>>>>>>>>>>> kernel usages, while still letting users configure these constraints.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> That is an interesting idea.  Would the other security maintainers be in
>>>>>>>>>>>>> support of such an approach?  Would a LSM be the correct interface?
>>>>>>>>>>>>> Some of the recent work I have done with introducing key usage and CA
>>>>>>>>>>>>> enforcement is difficult for a distro to pick up, since these changes can be
>>>>>>>>>>>>> viewed as a regression.  Each end-user has different signing procedures
>>>>>>>>>>>>> and policies, so making something work for everyone is difficult.  Letting the
>>>>>>>>>>>>> user configure these constraints would solve this problem.
>>>>>>>>>> 
>>>>>>>>>> Something definitely needs to be done about controlling the usage of
>>>>>>>>>> x509 certificates.  My concern is the level of granularity.  Would this
>>>>>>>>>> be at the LSM hook level or even finer granaularity?
>>>>>>>>> 
>>>>>>>>> You lost me, what do you mean by finer granularity than a LSM-based
>>>>>>>>> access control?  Can you give an existing example in the Linux kernel
>>>>>>>>> of access control granularity that is finer grained than what is
>>>>>>>>> provided by the LSMs?
>>>>>>>> 
>>>>>>>> The current x509 certificate access control granularity is at the
>>>>>>>> keyring level.  Any key on the keyring may be used to verify a
>>>>>>>> signature.  Finer granularity could associate a set of certificates on
>>>>>>>> a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
>>>>>>>> firmware, etc.  Even finer granularity could somehow limit a key's
>>>>>>>> signature verification to files in particular software package(s) for
>>>>>>>> example.
>>>>>>>> 
>>>>>>>> Perhaps Mickaël and Eric were thinking about a new LSM to control usage
>>>>>>>> of x509 certificates from a totally different perspective.  I'd like to
>>>>>>>> hear what they're thinking.
>>>>>>>> 
>>>>>>>> I hope this addressed your questions.
>>>>>>> 
>>>>>>> Okay, so you were talking about finer granularity when compared to the
>>>>>>> *current* LSM keyring hooks.  Gotcha.
>>>>>>> 
>>>>>>> If we need additional, or modified, hooks that shouldn't be a problem.
>>>>>>> Although I'm guessing the answer is going to be moving towards
>>>>>>> purpose/operation specific keyrings which might fit in well with the
>>>>>>> current keyring level controls.
>>>>>> 
>>>>>> I don't believe defining per purpose/operation specific keyrings will
>>>>>> resolve the underlying problem of granularity.
>>>>> 
>>>>> Perhaps not completely, but for in-kernel operations I believe it is
>>>>> an attractive idea.
>>>> 
>>>> Could the X.509 Extended Key Usage (EKU) extension [1], be used here?  
>>>> Various OIDs would need to be defined or assigned for each purpose.  
>>>> Once assigned, the kernel could parse this information and do the
>>>> enforcement.  Then all keys could continue to remain in the .builtin, 
>>>> .secondary, and .machine keyrings.   Only a subset of each keyring 
>>>> would be used for verification based on what is contained in the EKU.
>>>> 
>>>> 1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12
>>> 
>>> I was also thinking about this kind of use cases. Because it might be
>>> difficult in practice to control all certificate properties, we might
>>> want to let sysadmins configure these subset of keyring according to
>>> various certificate properties.
>> 
>> I agree, a configuration component for a sysadmin would be needed.
>> 
>>> There are currently LSM hooks to control
>>> interactions with kernel keys by user space, and keys are already tied
>>> to LSM blobs. New LSM hooks could be added to dynamically filter
>>> keyrings according to kernel usages (e.g. kernel module verification, a
>>> subset of an authentication mechanism according to the checked object).
>> 
>> If an LSM hook could dynamically filter keyrings, and the EKU was used, 
>> is there an opinion on how flexible this should be?  Meaning, should there 
>> be OIDs defined and carried in mainline code?  This would make it easier 
>> to setup and use.  However who would be the initial OID owner?  Or would 
>> predefined OIDs not be contained within mainline code, leaving it to the 
>> sysadmin to create a policy that would be fed to the LSM to do the filtering.
> 
> The more flexible approach would be to not hardcode any policy in the
> kernel but let sysadmins define their own, including OIDs. We "just"
> need to find an adequate configuration scheme to define these
> constraints.

Also, with the flexible approach, the policy would need to be given to the 
kernel before any kernel module loads, fs-verity starts, or anything dealing 
with digital signature based IMA runs, etc.  With hardcoded policies this 
could be setup from the kernel command line or be set from a Kconfig.  
I assume with a flexible approach, this would need to come in early within 
the initram?

> We already have an ASN.1 parser in the kernel, so we might
> want to leverage that to match a certificate.

We have the parser, however after parsing the certificate we do not 
retain all the information within it.  Some of the recent changes I have 
done required modifications to the public_key struct.  If there isn’t any 
type of hard coded policy, what would be the reception of retaining the 
entire cert within the kernel? 

Re: RFC: New LSM to control usage of x509 certificates

[Mickaël Salaün]

On Thu, Oct 19, 2023 at 11:08:38PM +0000, Eric Snowberg wrote:
> 
> 
> > On Oct 19, 2023, at 3:12 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > 
> > On Wed, Oct 18, 2023 at 11:12:45PM +0000, Eric Snowberg wrote:
> >> 
> >> 
> >>> On Oct 18, 2023, at 8:14 AM, Mickaël Salaün <mic@digikod.net> wrote:
> >>> 
> >>> On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:
> >>>> 
> >>>> 
> >>>>> On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
> >>>>> 
> >>>>> On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>> On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
> >>>>>>> On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>>>> On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> >>>>>>>>> On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>>>>>> On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> >>>>>>>>>>>>>> A complementary approach would be to create an
> >>>>>>>>>>>>>> LSM (or a dedicated interface) to tie certificate properties to a set of
> >>>>>>>>>>>>>> kernel usages, while still letting users configure these constraints.
> >>>>>>>>>>>>> 
> >>>>>>>>>>>>> That is an interesting idea.  Would the other security maintainers be in
> >>>>>>>>>>>>> support of such an approach?  Would a LSM be the correct interface?
> >>>>>>>>>>>>> Some of the recent work I have done with introducing key usage and CA
> >>>>>>>>>>>>> enforcement is difficult for a distro to pick up, since these changes can be
> >>>>>>>>>>>>> viewed as a regression.  Each end-user has different signing procedures
> >>>>>>>>>>>>> and policies, so making something work for everyone is difficult.  Letting the
> >>>>>>>>>>>>> user configure these constraints would solve this problem.
> >>>>>>>>>> 
> >>>>>>>>>> Something definitely needs to be done about controlling the usage of
> >>>>>>>>>> x509 certificates.  My concern is the level of granularity.  Would this
> >>>>>>>>>> be at the LSM hook level or even finer granaularity?
> >>>>>>>>> 
> >>>>>>>>> You lost me, what do you mean by finer granularity than a LSM-based
> >>>>>>>>> access control?  Can you give an existing example in the Linux kernel
> >>>>>>>>> of access control granularity that is finer grained than what is
> >>>>>>>>> provided by the LSMs?
> >>>>>>>> 
> >>>>>>>> The current x509 certificate access control granularity is at the
> >>>>>>>> keyring level.  Any key on the keyring may be used to verify a
> >>>>>>>> signature.  Finer granularity could associate a set of certificates on
> >>>>>>>> a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
> >>>>>>>> firmware, etc.  Even finer granularity could somehow limit a key's
> >>>>>>>> signature verification to files in particular software package(s) for
> >>>>>>>> example.
> >>>>>>>> 
> >>>>>>>> Perhaps Mickaël and Eric were thinking about a new LSM to control usage
> >>>>>>>> of x509 certificates from a totally different perspective.  I'd like to
> >>>>>>>> hear what they're thinking.
> >>>>>>>> 
> >>>>>>>> I hope this addressed your questions.
> >>>>>>> 
> >>>>>>> Okay, so you were talking about finer granularity when compared to the
> >>>>>>> *current* LSM keyring hooks.  Gotcha.
> >>>>>>> 
> >>>>>>> If we need additional, or modified, hooks that shouldn't be a problem.
> >>>>>>> Although I'm guessing the answer is going to be moving towards
> >>>>>>> purpose/operation specific keyrings which might fit in well with the
> >>>>>>> current keyring level controls.
> >>>>>> 
> >>>>>> I don't believe defining per purpose/operation specific keyrings will
> >>>>>> resolve the underlying problem of granularity.
> >>>>> 
> >>>>> Perhaps not completely, but for in-kernel operations I believe it is
> >>>>> an attractive idea.
> >>>> 
> >>>> Could the X.509 Extended Key Usage (EKU) extension [1], be used here?  
> >>>> Various OIDs would need to be defined or assigned for each purpose.  
> >>>> Once assigned, the kernel could parse this information and do the
> >>>> enforcement.  Then all keys could continue to remain in the .builtin, 
> >>>> .secondary, and .machine keyrings.   Only a subset of each keyring 
> >>>> would be used for verification based on what is contained in the EKU.
> >>>> 
> >>>> 1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12
> >>> 
> >>> I was also thinking about this kind of use cases. Because it might be
> >>> difficult in practice to control all certificate properties, we might
> >>> want to let sysadmins configure these subset of keyring according to
> >>> various certificate properties.
> >> 
> >> I agree, a configuration component for a sysadmin would be needed.
> >> 
> >>> There are currently LSM hooks to control
> >>> interactions with kernel keys by user space, and keys are already tied
> >>> to LSM blobs. New LSM hooks could be added to dynamically filter
> >>> keyrings according to kernel usages (e.g. kernel module verification, a
> >>> subset of an authentication mechanism according to the checked object).
> >> 
> >> If an LSM hook could dynamically filter keyrings, and the EKU was used, 
> >> is there an opinion on how flexible this should be?  Meaning, should there 
> >> be OIDs defined and carried in mainline code?  This would make it easier 
> >> to setup and use.  However who would be the initial OID owner?  Or would 
> >> predefined OIDs not be contained within mainline code, leaving it to the 
> >> sysadmin to create a policy that would be fed to the LSM to do the filtering.
> > 
> > The more flexible approach would be to not hardcode any policy in the
> > kernel but let sysadmins define their own, including OIDs. We "just"
> > need to find an adequate configuration scheme to define these
> > constraints.
> 
> Also, with the flexible approach, the policy would need to be given to the 
> kernel before any kernel module loads, fs-verity starts, or anything dealing 
> with digital signature based IMA runs, etc.  With hardcoded policies this 
> could be setup from the kernel command line or be set from a Kconfig.  
> I assume with a flexible approach, this would need to come in early within 
> the initram?

Yes, either the cmdline and/or the initramfs.

> 
> > We already have an ASN.1 parser in the kernel, so we might
> > want to leverage that to match a certificate.
> 
> We have the parser, however after parsing the certificate we do not 
> retain all the information within it.  Some of the recent changes I have 
> done required modifications to the public_key struct.  If there isn’t any 
> type of hard coded policy, what would be the reception of retaining the 
> entire cert within the kernel? 

I think it would make sense to have a default policy loaded at boot
time, then load and take into account new pieces of policies at run
time, but only parse/tag/assign a role to certificates/keys when they
are loaded.

Re: RFC: New LSM to control usage of x509 certificates

[Roberto Sassu]

On Fri, 2023-10-20 at 17:05 +0200, Mickaël Salaün wrote:
> On Thu, Oct 19, 2023 at 11:08:38PM +0000, Eric Snowberg wrote:
> > 
> > 
> > > On Oct 19, 2023, at 3:12 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > > 
> > > On Wed, Oct 18, 2023 at 11:12:45PM +0000, Eric Snowberg wrote:
> > > > 
> > > > 
> > > > > On Oct 18, 2023, at 8:14 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > > > > 
> > > > > On Tue, Oct 17, 2023 at 07:34:25PM +0000, Eric Snowberg wrote:
> > > > > > 
> > > > > > 
> > > > > > > On Oct 17, 2023, at 12:51 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > > > > > 
> > > > > > > On Tue, Oct 17, 2023 at 1:59 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > > On Tue, 2023-10-17 at 13:29 -0400, Paul Moore wrote:
> > > > > > > > > On Tue, Oct 17, 2023 at 1:09 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > > > > On Tue, 2023-10-17 at 11:45 -0400, Paul Moore wrote:
> > > > > > > > > > > On Tue, Oct 17, 2023 at 9:48 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > > > > > > On Thu, 2023-10-05 at 12:32 +0200, Mickaël Salaün wrote:
> > > > > > > > > > > > > > > > A complementary approach would be to create an
> > > > > > > > > > > > > > > > LSM (or a dedicated interface) to tie certificate properties to a set of
> > > > > > > > > > > > > > > > kernel usages, while still letting users configure these constraints.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > That is an interesting idea.  Would the other security maintainers be in
> > > > > > > > > > > > > > > support of such an approach?  Would a LSM be the correct interface?
> > > > > > > > > > > > > > > Some of the recent work I have done with introducing key usage and CA
> > > > > > > > > > > > > > > enforcement is difficult for a distro to pick up, since these changes can be
> > > > > > > > > > > > > > > viewed as a regression.  Each end-user has different signing procedures
> > > > > > > > > > > > > > > and policies, so making something work for everyone is difficult.  Letting the
> > > > > > > > > > > > > > > user configure these constraints would solve this problem.
> > > > > > > > > > > > 
> > > > > > > > > > > > Something definitely needs to be done about controlling the usage of
> > > > > > > > > > > > x509 certificates.  My concern is the level of granularity.  Would this
> > > > > > > > > > > > be at the LSM hook level or even finer granaularity?
> > > > > > > > > > > 
> > > > > > > > > > > You lost me, what do you mean by finer granularity than a LSM-based
> > > > > > > > > > > access control?  Can you give an existing example in the Linux kernel
> > > > > > > > > > > of access control granularity that is finer grained than what is
> > > > > > > > > > > provided by the LSMs?
> > > > > > > > > > 
> > > > > > > > > > The current x509 certificate access control granularity is at the
> > > > > > > > > > keyring level.  Any key on the keyring may be used to verify a
> > > > > > > > > > signature.  Finer granularity could associate a set of certificates on
> > > > > > > > > > a particular keyring with an LSM hook - kernel modules, BPRM, kexec,
> > > > > > > > > > firmware, etc.  Even finer granularity could somehow limit a key's
> > > > > > > > > > signature verification to files in particular software package(s) for
> > > > > > > > > > example.
> > > > > > > > > > 
> > > > > > > > > > Perhaps Mickaël and Eric were thinking about a new LSM to control usage
> > > > > > > > > > of x509 certificates from a totally different perspective.  I'd like to
> > > > > > > > > > hear what they're thinking.
> > > > > > > > > > 
> > > > > > > > > > I hope this addressed your questions.
> > > > > > > > > 
> > > > > > > > > Okay, so you were talking about finer granularity when compared to the
> > > > > > > > > *current* LSM keyring hooks.  Gotcha.
> > > > > > > > > 
> > > > > > > > > If we need additional, or modified, hooks that shouldn't be a problem.
> > > > > > > > > Although I'm guessing the answer is going to be moving towards
> > > > > > > > > purpose/operation specific keyrings which might fit in well with the
> > > > > > > > > current keyring level controls.
> > > > > > > > 
> > > > > > > > I don't believe defining per purpose/operation specific keyrings will
> > > > > > > > resolve the underlying problem of granularity.
> > > > > > > 
> > > > > > > Perhaps not completely, but for in-kernel operations I believe it is
> > > > > > > an attractive idea.
> > > > > > 
> > > > > > Could the X.509 Extended Key Usage (EKU) extension [1], be used here?  
> > > > > > Various OIDs would need to be defined or assigned for each purpose.  
> > > > > > Once assigned, the kernel could parse this information and do the
> > > > > > enforcement.  Then all keys could continue to remain in the .builtin, 
> > > > > > .secondary, and .machine keyrings.   Only a subset of each keyring 
> > > > > > would be used for verification based on what is contained in the EKU.
> > > > > > 
> > > > > > 1. https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.12
> > > > > 
> > > > > I was also thinking about this kind of use cases. Because it might be
> > > > > difficult in practice to control all certificate properties, we might
> > > > > want to let sysadmins configure these subset of keyring according to
> > > > > various certificate properties.
> > > > 
> > > > I agree, a configuration component for a sysadmin would be needed.
> > > > 
> > > > > There are currently LSM hooks to control
> > > > > interactions with kernel keys by user space, and keys are already tied
> > > > > to LSM blobs. New LSM hooks could be added to dynamically filter
> > > > > keyrings according to kernel usages (e.g. kernel module verification, a
> > > > > subset of an authentication mechanism according to the checked object).
> > > > 
> > > > If an LSM hook could dynamically filter keyrings, and the EKU was used, 
> > > > is there an opinion on how flexible this should be?  Meaning, should there 
> > > > be OIDs defined and carried in mainline code?  This would make it easier 
> > > > to setup and use.  However who would be the initial OID owner?  Or would 
> > > > predefined OIDs not be contained within mainline code, leaving it to the 
> > > > sysadmin to create a policy that would be fed to the LSM to do the filtering.
> > > 
> > > The more flexible approach would be to not hardcode any policy in the
> > > kernel but let sysadmins define their own, including OIDs. We "just"
> > > need to find an adequate configuration scheme to define these
> > > constraints.
> > 
> > Also, with the flexible approach, the policy would need to be given to the 
> > kernel before any kernel module loads, fs-verity starts, or anything dealing 
> > with digital signature based IMA runs, etc.  With hardcoded policies this 
> > could be setup from the kernel command line or be set from a Kconfig.  
> > I assume with a flexible approach, this would need to come in early within 
> > the initram?
> 
> Yes, either the cmdline and/or the initramfs.

If SELinux was enabled in the initramfs, I would have thought to extend
the 'key' class with a sig_verify permission, and you pass the label of
the key used for signature verification and of the data to verify (from
the file it was read from?).

Just an idea.

Roberto

> > > We already have an ASN.1 parser in the kernel, so we might
> > > want to leverage that to match a certificate.
> > 
> > We have the parser, however after parsing the certificate we do not 
> > retain all the information within it.  Some of the recent changes I have 
> > done required modifications to the public_key struct.  If there isn’t any 
> > type of hard coded policy, what would be the reception of retaining the 
> > entire cert within the kernel? 
> 
> I think it would make sense to have a default policy loaded at boot
> time, then load and take into account new pieces of policies at run
> time, but only parse/tag/assign a role to certificates/keys when they
> are loaded.

Re: RFC: New LSM to control usage of x509 certificates

[Eric Snowberg]

> On Oct 20, 2023, at 9:05 AM, Mickaël Salaün <mic@digikod.net> wrote:
> 
> On Thu, Oct 19, 2023 at 11:08:38PM +0000, Eric Snowberg wrote:
>> 
>> 
>>> On Oct 19, 2023, at 3:12 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>> 
>>> The more flexible approach would be to not hardcode any policy in the
>>> kernel but let sysadmins define their own, including OIDs. We "just"
>>> need to find an adequate configuration scheme to define these
>>> constraints.
>> 
>> Also, with the flexible approach, the policy would need to be given to the 
>> kernel before any kernel module loads, fs-verity starts, or anything dealing 
>> with digital signature based IMA runs, etc.  With hardcoded policies this 
>> could be setup from the kernel command line or be set from a Kconfig.  
>> I assume with a flexible approach, this would need to come in early within 
>> the initram?
> 
> Yes, either the cmdline and/or the initramfs.
> 
>> 
>>> We already have an ASN.1 parser in the kernel, so we might
>>> want to leverage that to match a certificate.
>> 
>> We have the parser, however after parsing the certificate we do not 
>> retain all the information within it.  Some of the recent changes I have 
>> done required modifications to the public_key struct.  If there isn’t any 
>> type of hard coded policy, what would be the reception of retaining the 
>> entire cert within the kernel? 
> 
> I think it would make sense to have a default policy loaded at boot
> time, then load and take into account new pieces of policies at run
> time, but only parse/tag/assign a role to certificates/keys when they
> are loaded.

Many keys are loaded into the kernel before the initram is used.  This 
includes:  builtin, platform (UEFI DB), and machine (MOK).  I believe 
these are the keys of most interest for controlling usage.  By not retaining 
all the attributes, I’m not sure how a useful filtering policy could be 
implemented afterwards.  Do you have any ideas?

Also, for revocation, today we allow any system key to vouch for inclusion 
into the blacklist keyring.  Shouldn’t only the CA with the correct attributes
that originally signed the key be able to do this?  If all attributes were retained 
this could also be possible.  There is a similar issue with keys added to the 
secondary keyring.  Any key linked to the secondary can do the vouching 
for inclusion and usage is ignored.  If a policy is added afterwards to enforce 
this, we don’t have all the information necessary to do the enforcement.