| Message ID | 20221214003401.4086781-1-eric.snowberg@oracle.com |
|---|---|
| Headers | show |
| Series | Add CA enforcement keyring restrictions | expand |
On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote: > Prior to the introduction of the machine keyring, most distros simply > allowed all keys contained within the platform keyring to be used > for both kernel and module verification. This was done by an out of > tree patch. Some distros took it even further and loaded all these keys > into the secondary trusted keyring. This also allowed the system owner > to add their own key for IMA usage. > > Each distro contains similar documentation on how to sign kernel modules > and enroll the key into the MOK. The process is fairly straightforward. > With the introduction of the machine keyring, the process remains > basically the same, without the need for any out of tree patches. > > The machine keyring allowed distros to eliminate the out of tree patches > for kernel module signing. However, it falls short in allowing the end > user to add their own keys for IMA. Currently the machine keyring can not > be used as another trust anchor for adding keys to the ima keyring, since > CA enforcement does not currently exist. This would expand the current > integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY > Kconfig states that keys may be added to the ima keyrings if the key is > validly signed by a CA cert in the system built-in or secondary trusted > keyring. Currently there is not code that enforces the contents of a > CA cert. Any key in the builtin or secondary keyring can be used. > > To allow IMA to be enabled with the machine keyring, this series introduces > enforcement of key usage in the certificate. This series also applies > this enforcement across all kernel keyrings. > > The machine keyring shares similarities with both the builtin and > secondary keyrings. Similar to the builtin, no keys may be added to the > machine keyring following boot. The secondary keyring allows user > provided keys to be added following boot; however, a previously enrolled > kernel key must vouch for the key before it may be included. The system > owner may include their own keys into the machine keyring prior to boot. > If the end-user is not the system owner, they may not add their own keys > to the machine keyring. > > The machine keyring is only populated when Secure Boot is enabled. A > system owner has the ability to control the entire Secure Boot keychain > (PK, KEK, DB, and DBX). The system owner can also turn Secure Boot off. > With this control, they may use insert-sys-cert to include their own key > and re-sign their kernel and have it boot. The system owner also has > control to include or exclude MOK keys. This series does not try to > interpret how a system owner has configured their machine. If the system > owner has taken the steps to add their own MOK keys, they will be > included in the machine keyring and used for verification, exactly > the same way as keys contained in the builtin and secondary keyrings. > Since the system owner has the ability to add keys before booting to > either the machine or builtin keyrings, it is viewed as inconsequential > if the key originated from one or the other. > > This series introduces two different ways to configure the machine keyring. > By default, nothing changes and all MOK keys are loaded into it. Whenever > a CA cert is found within the machine, builtin, or secondary, a flag > indicating this is stored in the public key struct. The other option is > if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs > will be loaded into the machine keyring. All remaining MOK keys will be > loaded into the platform keyring. > > A CA cert shall be defined as any X509 certificate that contains the > keyCertSign key usage and has the CA bit set to true. Hi Eric, Allowing CA certificates with the digitalSignature key usage flag enabled defeats the purpose of the new Kconfig. Please update the above definition to exclude the digitalSignature key usage flag and modify the code accordingly. thanks, Mimi > With this series applied, CA enforcement is in place whenever > IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled. Meaning, > before any key can be included into the ima keyring, it must be > vouched for by a CA key contained within the builtin, secondary, or > machine keyrings. > > IMA allows userspace applications to be signed. The enduser may sign > their own application, however they may also want to use an application > provided by a 3rd party. The entity building the kernel, may not be the > same entity building the userspace program. The system owner may also > be a third entity. If the system owner trusts the entity building the > userspace program, they will include their public key within the MOK. > This key would be used to sign the key added to the ima keyring. Not all > 3rd party userspace providers have the capability to properly manage a > root CA. Some may outsource to a different code signing provider. Many > code signing providers use Intermediate CA certificates. Therefore, this > series also includes support for Intermediate CA certificates. > > This series could be broken up into 3 different parts. The first two > patches could be taken now. They solve current issues that will be > triggered by the build robots. Patches 3-8 add CA enforcement for the > ima keyring. Patches 9-10 restrict the machine keyring to only load CA > certs into it. Patches 9-10 require all the previous patches. > > Changelog: > > v3: > - Allow Intermediate CA certs to be enrolled through the MOK. The > Intermediate CA cert must contain keyCertSign key usage and have the > CA bit set to true. This was done by removing the self signed > requirement. > > > Eric Snowberg (10): > KEYS: Create static version of public_key_verify_signature > KEYS: Add missing function documentation > KEYS: X.509: Parse Basic Constraints for CA > KEYS: X.509: Parse Key Usage > KEYS: Introduce a CA endorsed flag > KEYS: Introduce keyring restriction that validates ca trust > KEYS: X.509: Flag Intermediate CA certs as endorsed > integrity: Use root of trust signature restriction > KEYS: CA link restriction > integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca > > certs/system_keyring.c | 32 +++++++++- > crypto/asymmetric_keys/restrict.c | 76 +++++++++++++++++++++++ > crypto/asymmetric_keys/x509_cert_parser.c | 31 +++++++++ > crypto/asymmetric_keys/x509_parser.h | 2 + > crypto/asymmetric_keys/x509_public_key.c | 16 +++++ > include/crypto/public_key.h | 30 +++++++++ > include/keys/system_keyring.h | 12 +++- > include/linux/ima.h | 11 ++++ > include/linux/key-type.h | 3 + > include/linux/key.h | 2 + > security/integrity/Kconfig | 11 +++- > security/integrity/digsig.c | 12 ++-- > security/integrity/ima/Kconfig | 6 +- > security/keys/key.c | 13 ++++ > 14 files changed, 245 insertions(+), 12 deletions(-) > > > base-commit: 830b3c68c1fb1e9176028d02ef86f3cf76aa2476
On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote: > Parse the X.509 Key Usage. The key usage extension defines the purpose of > the key contained in the certificate. > > id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } > > KeyUsage ::= BIT STRING { > digitalSignature (0), > contentCommitment (1), > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } > > If the keyCertSign is set, store it in the x509_certificate structure. > This will be used in a follow on patch that requires knowing the > certificate key usage type. Either in this patch or separately, the "digitalSignature" key usage flag needs to be saved. > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> > --- > crypto/asymmetric_keys/x509_cert_parser.c | 22 ++++++++++++++++++++++ > crypto/asymmetric_keys/x509_parser.h | 1 + > 2 files changed, 23 insertions(+) > > diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c > index b4443e507153..edb22cf04eed 100644 > --- a/crypto/asymmetric_keys/x509_cert_parser.c > +++ b/crypto/asymmetric_keys/x509_cert_parser.c > @@ -579,6 +579,28 @@ int x509_process_extension(void *context, size_t hdrlen, > return 0; > } > > + if (ctx->last_oid == OID_keyUsage) { > + /* > + * Get hold of the keyUsage bit string to validate keyCertSign > + * v[1] is the encoding size > + * (Expect either 0x02 or 0x03, making it 1 or 2 bytes) > + * v[2] is the number of unused bits in the bit string > + * (If >= 3 keyCertSign is missing) > + * v[3] and possibly v[4] contain the bit string > + * 0x04 is where KeyCertSign lands in this bit string (from > + * RFC 5280 4.2.1.3) > + */ > + if (v[0] != ASN1_BTS) > + return -EBADMSG; > + if (vlen < 4) > + return -EBADMSG; > + if (v[1] == 0x02 && v[2] <= 2 && (v[3] & 0x04)) > + ctx->cert->kcs_set = true; > + else if (vlen > 4 && v[1] == 0x03 && (v[3] & 0x04)) > + ctx->cert->kcs_set = true; > + return 0; > + } > + > if (ctx->last_oid == OID_authorityKeyIdentifier) { > /* Get hold of the CA key fingerprint */ > ctx->raw_akid = v; > diff --git a/crypto/asymmetric_keys/x509_parser.h b/crypto/asymmetric_keys/x509_parser.h > index 7c5c0ad1c22e..74a9f929e400 100644 > --- a/crypto/asymmetric_keys/x509_parser.h > +++ b/crypto/asymmetric_keys/x509_parser.h > @@ -39,6 +39,7 @@ struct x509_certificate { > bool unsupported_sig; /* T if signature uses unsupported crypto */ > bool blacklisted; > bool root_ca; /* T if basic constraints CA is set */ > + bool kcs_set; /* T if keyCertSign is set */ Using acronyms as variable names makes reviewing code more difficult. Perhaps rename "kcs_set" to either "key_cert_sign" or "keycertsign". > }; > > /*
> On Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote: >> Prior to the introduction of the machine keyring, most distros simply >> allowed all keys contained within the platform keyring to be used >> for both kernel and module verification. This was done by an out of >> tree patch. Some distros took it even further and loaded all these keys >> into the secondary trusted keyring. This also allowed the system owner >> to add their own key for IMA usage. >> >> Each distro contains similar documentation on how to sign kernel modules >> and enroll the key into the MOK. The process is fairly straightforward. >> With the introduction of the machine keyring, the process remains >> basically the same, without the need for any out of tree patches. >> >> The machine keyring allowed distros to eliminate the out of tree patches >> for kernel module signing. However, it falls short in allowing the end >> user to add their own keys for IMA. Currently the machine keyring can not >> be used as another trust anchor for adding keys to the ima keyring, since >> CA enforcement does not currently exist. This would expand the current >> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY >> Kconfig states that keys may be added to the ima keyrings if the key is >> validly signed by a CA cert in the system built-in or secondary trusted >> keyring. Currently there is not code that enforces the contents of a >> CA cert. Any key in the builtin or secondary keyring can be used. >> >> To allow IMA to be enabled with the machine keyring, this series introduces >> enforcement of key usage in the certificate. This series also applies >> this enforcement across all kernel keyrings. >> >> The machine keyring shares similarities with both the builtin and >> secondary keyrings. Similar to the builtin, no keys may be added to the >> machine keyring following boot. The secondary keyring allows user >> provided keys to be added following boot; however, a previously enrolled >> kernel key must vouch for the key before it may be included. The system >> owner may include their own keys into the machine keyring prior to boot. >> If the end-user is not the system owner, they may not add their own keys >> to the machine keyring. >> >> The machine keyring is only populated when Secure Boot is enabled. A >> system owner has the ability to control the entire Secure Boot keychain >> (PK, KEK, DB, and DBX). The system owner can also turn Secure Boot off. >> With this control, they may use insert-sys-cert to include their own key >> and re-sign their kernel and have it boot. The system owner also has >> control to include or exclude MOK keys. This series does not try to >> interpret how a system owner has configured their machine. If the system >> owner has taken the steps to add their own MOK keys, they will be >> included in the machine keyring and used for verification, exactly >> the same way as keys contained in the builtin and secondary keyrings. >> Since the system owner has the ability to add keys before booting to >> either the machine or builtin keyrings, it is viewed as inconsequential >> if the key originated from one or the other. >> >> This series introduces two different ways to configure the machine keyring. >> By default, nothing changes and all MOK keys are loaded into it. Whenever >> a CA cert is found within the machine, builtin, or secondary, a flag >> indicating this is stored in the public key struct. The other option is >> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs >> will be loaded into the machine keyring. All remaining MOK keys will be >> loaded into the platform keyring. >> >> A CA cert shall be defined as any X509 certificate that contains the >> keyCertSign key usage and has the CA bit set to true. > > Hi Eric, > > Allowing CA certificates with the digitalSignature key usage flag > enabled defeats the purpose of the new Kconfig. Please update the > above definition to exclude the digitalSignature key usage flag and > modify the code accordingly. Within v2, the request was made to allow Intermediate CA certificates to be loaded directly. The Intermediate CA referenced was the one used by kernel.org. This Intermediate CA contains both digitalSignature and keyCertSign. If the code is changed to exclude this certificate, now the root CA has to be loaded again. Is that the intent?
On Thu, 2022-12-15 at 16:26 +0000, Eric Snowberg wrote: > > > On Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote: > >> Prior to the introduction of the machine keyring, most distros simply > >> allowed all keys contained within the platform keyring to be used > >> for both kernel and module verification. This was done by an out of > >> tree patch. Some distros took it even further and loaded all these keys > >> into the secondary trusted keyring. This also allowed the system owner > >> to add their own key for IMA usage. > >> > >> Each distro contains similar documentation on how to sign kernel modules > >> and enroll the key into the MOK. The process is fairly straightforward. > >> With the introduction of the machine keyring, the process remains > >> basically the same, without the need for any out of tree patches. > >> > >> The machine keyring allowed distros to eliminate the out of tree patches > >> for kernel module signing. However, it falls short in allowing the end > >> user to add their own keys for IMA. Currently the machine keyring can not > >> be used as another trust anchor for adding keys to the ima keyring, since > >> CA enforcement does not currently exist. This would expand the current > >> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY > >> Kconfig states that keys may be added to the ima keyrings if the key is > >> validly signed by a CA cert in the system built-in or secondary trusted > >> keyring. Currently there is not code that enforces the contents of a > >> CA cert. Any key in the builtin or secondary keyring can be used. > >> > >> To allow IMA to be enabled with the machine keyring, this series introduces > >> enforcement of key usage in the certificate. This series also applies > >> this enforcement across all kernel keyrings. > >> > >> The machine keyring shares similarities with both the builtin and > >> secondary keyrings. Similar to the builtin, no keys may be added to the > >> machine keyring following boot. The secondary keyring allows user > >> provided keys to be added following boot; however, a previously enrolled > >> kernel key must vouch for the key before it may be included. The system > >> owner may include their own keys into the machine keyring prior to boot. > >> If the end-user is not the system owner, they may not add their own keys > >> to the machine keyring. > >> > >> The machine keyring is only populated when Secure Boot is enabled. A > >> system owner has the ability to control the entire Secure Boot keychain > >> (PK, KEK, DB, and DBX). The system owner can also turn Secure Boot off. > >> With this control, they may use insert-sys-cert to include their own key > >> and re-sign their kernel and have it boot. The system owner also has > >> control to include or exclude MOK keys. This series does not try to > >> interpret how a system owner has configured their machine. If the system > >> owner has taken the steps to add their own MOK keys, they will be > >> included in the machine keyring and used for verification, exactly > >> the same way as keys contained in the builtin and secondary keyrings. > >> Since the system owner has the ability to add keys before booting to > >> either the machine or builtin keyrings, it is viewed as inconsequential > >> if the key originated from one or the other. > >> > >> This series introduces two different ways to configure the machine keyring. > >> By default, nothing changes and all MOK keys are loaded into it. Whenever > >> a CA cert is found within the machine, builtin, or secondary, a flag > >> indicating this is stored in the public key struct. The other option is > >> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs > >> will be loaded into the machine keyring. All remaining MOK keys will be > >> loaded into the platform keyring. > >> > >> A CA cert shall be defined as any X509 certificate that contains the > >> keyCertSign key usage and has the CA bit set to true. > > > > Hi Eric, > > > > Allowing CA certificates with the digitalSignature key usage flag > > enabled defeats the purpose of the new Kconfig. Please update the > > above definition to exclude the digitalSignature key usage flag and > > modify the code accordingly. > > Within v2, the request was made to allow Intermediate CA certificates to be > loaded directly. The Intermediate CA referenced was the one used by kernel.org. > This Intermediate CA contains both digitalSignature and keyCertSign. If the code > is changed to exclude this certificate, now the root CA has to be loaded again. Is that > the intent? That definitely was not the intent. Nor would it address the issue of a particular intermediate CA certificate having both keyCertSign and digitalSignature. thanks, Mimi
> On Dec 15, 2022, at 12:58 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2022-12-15 at 16:26 +0000, Eric Snowberg wrote: >> >>> On Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>> On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote: >>>> Prior to the introduction of the machine keyring, most distros simply >>>> allowed all keys contained within the platform keyring to be used >>>> for both kernel and module verification. This was done by an out of >>>> tree patch. Some distros took it even further and loaded all these keys >>>> into the secondary trusted keyring. This also allowed the system owner >>>> to add their own key for IMA usage. >>>> >>>> Each distro contains similar documentation on how to sign kernel modules >>>> and enroll the key into the MOK. The process is fairly straightforward. >>>> With the introduction of the machine keyring, the process remains >>>> basically the same, without the need for any out of tree patches. >>>> >>>> The machine keyring allowed distros to eliminate the out of tree patches >>>> for kernel module signing. However, it falls short in allowing the end >>>> user to add their own keys for IMA. Currently the machine keyring can not >>>> be used as another trust anchor for adding keys to the ima keyring, since >>>> CA enforcement does not currently exist. This would expand the current >>>> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY >>>> Kconfig states that keys may be added to the ima keyrings if the key is >>>> validly signed by a CA cert in the system built-in or secondary trusted >>>> keyring. Currently there is not code that enforces the contents of a >>>> CA cert. Any key in the builtin or secondary keyring can be used. >>>> >>>> To allow IMA to be enabled with the machine keyring, this series introduces >>>> enforcement of key usage in the certificate. This series also applies >>>> this enforcement across all kernel keyrings. >>>> >>>> The machine keyring shares similarities with both the builtin and >>>> secondary keyrings. Similar to the builtin, no keys may be added to the >>>> machine keyring following boot. The secondary keyring allows user >>>> provided keys to be added following boot; however, a previously enrolled >>>> kernel key must vouch for the key before it may be included. The system >>>> owner may include their own keys into the machine keyring prior to boot. >>>> If the end-user is not the system owner, they may not add their own keys >>>> to the machine keyring. >>>> >>>> The machine keyring is only populated when Secure Boot is enabled. A >>>> system owner has the ability to control the entire Secure Boot keychain >>>> (PK, KEK, DB, and DBX). The system owner can also turn Secure Boot off. >>>> With this control, they may use insert-sys-cert to include their own key >>>> and re-sign their kernel and have it boot. The system owner also has >>>> control to include or exclude MOK keys. This series does not try to >>>> interpret how a system owner has configured their machine. If the system >>>> owner has taken the steps to add their own MOK keys, they will be >>>> included in the machine keyring and used for verification, exactly >>>> the same way as keys contained in the builtin and secondary keyrings. >>>> Since the system owner has the ability to add keys before booting to >>>> either the machine or builtin keyrings, it is viewed as inconsequential >>>> if the key originated from one or the other. >>>> >>>> This series introduces two different ways to configure the machine keyring. >>>> By default, nothing changes and all MOK keys are loaded into it. Whenever >>>> a CA cert is found within the machine, builtin, or secondary, a flag >>>> indicating this is stored in the public key struct. The other option is >>>> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs >>>> will be loaded into the machine keyring. All remaining MOK keys will be >>>> loaded into the platform keyring. >>>> >>>> A CA cert shall be defined as any X509 certificate that contains the >>>> keyCertSign key usage and has the CA bit set to true. >>> >>> Hi Eric, >>> >>> Allowing CA certificates with the digitalSignature key usage flag >>> enabled defeats the purpose of the new Kconfig. Please update the >>> above definition to exclude the digitalSignature key usage flag and >>> modify the code accordingly. >> >> Within v2, the request was made to allow Intermediate CA certificates to be >> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >> the intent? > > That definitely was not the intent. Nor would it address the issue of > a particular intermediate CA certificate having both keyCertSign and > digitalSignature. Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate CA cert like the one used on kernel.org?
On Thu, 2022-12-15 at 20:28 +0000, Eric Snowberg wrote: > > > On Dec 15, 2022, at 12:58 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Thu, 2022-12-15 at 16:26 +0000, Eric Snowberg wrote: > >> > >>> On Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > >>> > >>> On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote: > >>>> Prior to the introduction of the machine keyring, most distros simply > >>>> allowed all keys contained within the platform keyring to be used > >>>> for both kernel and module verification. This was done by an out of > >>>> tree patch. Some distros took it even further and loaded all these keys > >>>> into the secondary trusted keyring. This also allowed the system owner > >>>> to add their own key for IMA usage. > >>>> > >>>> Each distro contains similar documentation on how to sign kernel modules > >>>> and enroll the key into the MOK. The process is fairly straightforward. > >>>> With the introduction of the machine keyring, the process remains > >>>> basically the same, without the need for any out of tree patches. > >>>> > >>>> The machine keyring allowed distros to eliminate the out of tree patches > >>>> for kernel module signing. However, it falls short in allowing the end > >>>> user to add their own keys for IMA. Currently the machine keyring can not > >>>> be used as another trust anchor for adding keys to the ima keyring, since > >>>> CA enforcement does not currently exist. This would expand the current > >>>> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY > >>>> Kconfig states that keys may be added to the ima keyrings if the key is > >>>> validly signed by a CA cert in the system built-in or secondary trusted > >>>> keyring. Currently there is not code that enforces the contents of a > >>>> CA cert. Any key in the builtin or secondary keyring can be used. > >>>> > >>>> To allow IMA to be enabled with the machine keyring, this series introduces > >>>> enforcement of key usage in the certificate. This series also applies > >>>> this enforcement across all kernel keyrings. > >>>> > >>>> The machine keyring shares similarities with both the builtin and > >>>> secondary keyrings. Similar to the builtin, no keys may be added to the > >>>> machine keyring following boot. The secondary keyring allows user > >>>> provided keys to be added following boot; however, a previously enrolled > >>>> kernel key must vouch for the key before it may be included. The system > >>>> owner may include their own keys into the machine keyring prior to boot. > >>>> If the end-user is not the system owner, they may not add their own keys > >>>> to the machine keyring. > >>>> > >>>> The machine keyring is only populated when Secure Boot is enabled. A > >>>> system owner has the ability to control the entire Secure Boot keychain > >>>> (PK, KEK, DB, and DBX). The system owner can also turn Secure Boot off. > >>>> With this control, they may use insert-sys-cert to include their own key > >>>> and re-sign their kernel and have it boot. The system owner also has > >>>> control to include or exclude MOK keys. This series does not try to > >>>> interpret how a system owner has configured their machine. If the system > >>>> owner has taken the steps to add their own MOK keys, they will be > >>>> included in the machine keyring and used for verification, exactly > >>>> the same way as keys contained in the builtin and secondary keyrings. > >>>> Since the system owner has the ability to add keys before booting to > >>>> either the machine or builtin keyrings, it is viewed as inconsequential > >>>> if the key originated from one or the other. > >>>> > >>>> This series introduces two different ways to configure the machine keyring. > >>>> By default, nothing changes and all MOK keys are loaded into it. Whenever > >>>> a CA cert is found within the machine, builtin, or secondary, a flag > >>>> indicating this is stored in the public key struct. The other option is > >>>> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs > >>>> will be loaded into the machine keyring. All remaining MOK keys will be > >>>> loaded into the platform keyring. > >>>> > >>>> A CA cert shall be defined as any X509 certificate that contains the > >>>> keyCertSign key usage and has the CA bit set to true. > >>> > >>> Hi Eric, > >>> > >>> Allowing CA certificates with the digitalSignature key usage flag > >>> enabled defeats the purpose of the new Kconfig. Please update the > >>> above definition to exclude the digitalSignature key usage flag and > >>> modify the code accordingly. > >> > >> Within v2, the request was made to allow Intermediate CA certificates to be > >> loaded directly. The Intermediate CA referenced was the one used by kernel.org. > >> This Intermediate CA contains both digitalSignature and keyCertSign. If the code > >> is changed to exclude this certificate, now the root CA has to be loaded again. Is that > >> the intent? > > > > That definitely was not the intent. Nor would it address the issue of > > a particular intermediate CA certificate having both keyCertSign and > > digitalSignature. > > Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains > both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate > CA cert like the one used on kernel.org? I must be missing something. Isn't the purpose of "keyUsage" to minimize how a certificate may be used? Why would we want the same certificate to be used for both certificate signing and code signing? thanks, Mimi
> On Dec 15, 2022, at 2:03 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2022-12-15 at 20:28 +0000, Eric Snowberg wrote: >> >>> On Dec 15, 2022, at 12:58 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>> On Thu, 2022-12-15 at 16:26 +0000, Eric Snowberg wrote: >>>> >>>>> On Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>>>> >>>>> On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote: >>>>>> Prior to the introduction of the machine keyring, most distros simply >>>>>> allowed all keys contained within the platform keyring to be used >>>>>> for both kernel and module verification. This was done by an out of >>>>>> tree patch. Some distros took it even further and loaded all these keys >>>>>> into the secondary trusted keyring. This also allowed the system owner >>>>>> to add their own key for IMA usage. >>>>>> >>>>>> Each distro contains similar documentation on how to sign kernel modules >>>>>> and enroll the key into the MOK. The process is fairly straightforward. >>>>>> With the introduction of the machine keyring, the process remains >>>>>> basically the same, without the need for any out of tree patches. >>>>>> >>>>>> The machine keyring allowed distros to eliminate the out of tree patches >>>>>> for kernel module signing. However, it falls short in allowing the end >>>>>> user to add their own keys for IMA. Currently the machine keyring can not >>>>>> be used as another trust anchor for adding keys to the ima keyring, since >>>>>> CA enforcement does not currently exist. This would expand the current >>>>>> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY >>>>>> Kconfig states that keys may be added to the ima keyrings if the key is >>>>>> validly signed by a CA cert in the system built-in or secondary trusted >>>>>> keyring. Currently there is not code that enforces the contents of a >>>>>> CA cert. Any key in the builtin or secondary keyring can be used. >>>>>> >>>>>> To allow IMA to be enabled with the machine keyring, this series introduces >>>>>> enforcement of key usage in the certificate. This series also applies >>>>>> this enforcement across all kernel keyrings. >>>>>> >>>>>> The machine keyring shares similarities with both the builtin and >>>>>> secondary keyrings. Similar to the builtin, no keys may be added to the >>>>>> machine keyring following boot. The secondary keyring allows user >>>>>> provided keys to be added following boot; however, a previously enrolled >>>>>> kernel key must vouch for the key before it may be included. The system >>>>>> owner may include their own keys into the machine keyring prior to boot. >>>>>> If the end-user is not the system owner, they may not add their own keys >>>>>> to the machine keyring. >>>>>> >>>>>> The machine keyring is only populated when Secure Boot is enabled. A >>>>>> system owner has the ability to control the entire Secure Boot keychain >>>>>> (PK, KEK, DB, and DBX). The system owner can also turn Secure Boot off. >>>>>> With this control, they may use insert-sys-cert to include their own key >>>>>> and re-sign their kernel and have it boot. The system owner also has >>>>>> control to include or exclude MOK keys. This series does not try to >>>>>> interpret how a system owner has configured their machine. If the system >>>>>> owner has taken the steps to add their own MOK keys, they will be >>>>>> included in the machine keyring and used for verification, exactly >>>>>> the same way as keys contained in the builtin and secondary keyrings. >>>>>> Since the system owner has the ability to add keys before booting to >>>>>> either the machine or builtin keyrings, it is viewed as inconsequential >>>>>> if the key originated from one or the other. >>>>>> >>>>>> This series introduces two different ways to configure the machine keyring. >>>>>> By default, nothing changes and all MOK keys are loaded into it. Whenever >>>>>> a CA cert is found within the machine, builtin, or secondary, a flag >>>>>> indicating this is stored in the public key struct. The other option is >>>>>> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs >>>>>> will be loaded into the machine keyring. All remaining MOK keys will be >>>>>> loaded into the platform keyring. >>>>>> >>>>>> A CA cert shall be defined as any X509 certificate that contains the >>>>>> keyCertSign key usage and has the CA bit set to true. >>>>> >>>>> Hi Eric, >>>>> >>>>> Allowing CA certificates with the digitalSignature key usage flag >>>>> enabled defeats the purpose of the new Kconfig. Please update the >>>>> above definition to exclude the digitalSignature key usage flag and >>>>> modify the code accordingly. >>>> >>>> Within v2, the request was made to allow Intermediate CA certificates to be >>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >>>> the intent? >>> >>> That definitely was not the intent. Nor would it address the issue of >>> a particular intermediate CA certificate having both keyCertSign and >>> digitalSignature. >> >> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains >> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate >> CA cert like the one used on kernel.org? > > I must be missing something. Isn't the purpose of "keyUsage" to > minimize how a certificate may be used? Why would we want the same > certificate to be used for both certificate signing and code signing? Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be challenging and will severely limit usage.
Hi Eric and Mimi, On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote: > > >>>>>>> A CA cert shall be defined as any X509 certificate that contains the >>>>>>> keyCertSign key usage and has the CA bit set to true. >>>>>> >>>>>> Hi Eric, >>>>>> >>>>>> Allowing CA certificates with the digitalSignature key usage flag >>>>>> enabled defeats the purpose of the new Kconfig. Please update the >>>>>> above definition to exclude the digitalSignature key usage flag and >>>>>> modify the code accordingly. >>>>> >>>>> Within v2, the request was made to allow Intermediate CA certificates to be >>>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >>>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >>>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >>>>> the intent? >>>> >>>> That definitely was not the intent. Nor would it address the issue of >>>> a particular intermediate CA certificate having both keyCertSign and >>>> digitalSignature. >>> >>> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains >>> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate >>> CA cert like the one used on kernel.org? >> >> I must be missing something. Isn't the purpose of "keyUsage" to >> minimize how a certificate may be used? Why would we want the same >> certificate to be used for both certificate signing and code signing? > >Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. >Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature >set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be >challenging and will severely limit usage. How about allowing both keyCertSign and digitalSignature asserted but issuing a warning for this case? Here's my rationale for this proposal. I assume we should conform to some X.509 specifications. So I checked "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10) [2]. [1] states in 4.2.1.3. Key Usage, "If the keyUsage extension is present, then the subject public key MUST NOT be used to verify signatures on certificates or CRLs unless the corresponding keyCertSign or cRLSign bit is set. If the subject public key is only to be used for verifying signatures on certificates and/or CRLs, then the digitalSignature and nonRepudiation bits SHOULD NOT be set. However, the digitalSignature and/or nonRepudiation bits MAY be set in addition to the keyCertSign and/or cRLSign bits if the subject public key is to be used to verify signatures on certificates and/or CRLs as well as other objects." and [2] states in 8.2.2.3 Key usage extension that, "More than one bit may be set in an instance of the keyUsage extension. The setting of multiple bits shall not change the meaning of each individual bit but shall indicate that the certificate may be used for all of the purposes indicated by the set bits. There may be risks incurred when setting multiple bits. A review of those risks is documented in Annex I." I interpret the above texts as we should allow both keyCertSign and digitalSignature. However [2] warns about the risks of setting multiple bits. Quoting Annex I, "Combining the contentCommitment bit in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the security environment in which the certificate is to be used. If the subject's environment can be fully controlled and trusted, then there are no specific security implications. For example, in cases where the subject is fully confident about exactly which data is signed or cases where the subject is fully confident about the security characteristics of the authentication protocol being used. If the subject's environment is not fully controlled or not fully trusted, then unintentional signing of commitments is possible. Examples include the use of badly formed authentication exchanges and the use of a rogue software component. If untrusted environments are used by a subject, these security implications can be limited through use of the following measures: – to not combine the contentCommitment key usage setting in certificates with any other key usage setting and to use the corresponding private key only with this certificate; – to limit the use of private keys associated with certificates that have the contentCommitment key usage bit set, to environments which are considered adequately controlled and trustworthy" So maybe it's useful to add a warning if both keyCertSign and digitalSignature are asserted.
> On Dec 18, 2022, at 5:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Fri, 2022-12-16 at 22:06 +0800, Coiby Xu wrote: >> Hi Eric and Mimi, >> >> On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote: >>> >>> >>>>>>>>> A CA cert shall be defined as any X509 certificate that contains the >>>>>>>>> keyCertSign key usage and has the CA bit set to true. >>>>>>>> >>>>>>>> Hi Eric, >>>>>>>> >>>>>>>> Allowing CA certificates with the digitalSignature key usage flag >>>>>>>> enabled defeats the purpose of the new Kconfig. Please update the >>>>>>>> above definition to exclude the digitalSignature key usage flag and >>>>>>>> modify the code accordingly. >>>>>>> >>>>>>> Within v2, the request was made to allow Intermediate CA certificates to be >>>>>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >>>>>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >>>>>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >>>>>>> the intent? >>>>>> >>>>>> That definitely was not the intent. Nor would it address the issue of >>>>>> a particular intermediate CA certificate having both keyCertSign and >>>>>> digitalSignature. >>>>> >>>>> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains >>>>> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate >>>>> CA cert like the one used on kernel.org? >>>> >>>> I must be missing something. Isn't the purpose of "keyUsage" to >>>> minimize how a certificate may be used? Why would we want the same >>>> certificate to be used for both certificate signing and code signing? >>> >>> Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. >>> Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature >>> set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be >>> challenging and will severely limit usage. >> >> How about allowing both keyCertSign and digitalSignature asserted but >> issuing a warning for this case? >> >> Here's my rationale for this proposal. >> >> I assume we should conform to some X.509 specifications. So I checked >> "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and >> Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10) >> [2]. >> >> [1] states in 4.2.1.3. Key Usage, >> "If the keyUsage extension is present, then the subject public key >> MUST NOT be used to verify signatures on certificates or CRLs unless >> the corresponding keyCertSign or cRLSign bit is set. If the subject >> public key is only to be used for verifying signatures on >> certificates and/or CRLs, then the digitalSignature and >> nonRepudiation bits SHOULD NOT be set. However, the digitalSignature >> and/or nonRepudiation bits MAY be set in addition to the keyCertSign >> and/or cRLSign bits if the subject public key is to be used to verify >> signatures on certificates and/or CRLs as well as other objects." >> >> and [2] states in 8.2.2.3 Key usage extension that, >> "More than one bit may be set in an instance of the keyUsage extension. >> The setting of multiple bits shall not change the meaning of each >> individual bit but shall indicate that the certificate may be used for >> all of the purposes indicated by the set bits. There may be risks >> incurred when setting multiple bits. A review of those risks is >> documented in Annex I." >> >> I interpret the above texts as we should allow both keyCertSign and >> digitalSignature. However [2] warns about the risks of setting multiple >> bits. Quoting Annex I, >> >> "Combining the contentCommitment bit in the keyUsage certificate >> extension with other keyUsage bits may have security implications >> depending on the security environment in which the certificate is to be >> used. If the subject's environment can be fully controlled and trusted, >> then there are no specific security implications. For example, in cases >> where the subject is fully confident about exactly which data is signed >> or cases where the subject is fully confident about the security >> characteristics of the authentication protocol being used. If the >> subject's environment is not fully controlled or not fully trusted, then >> unintentional signing of commitments is possible. Examples include the >> use of badly formed authentication exchanges and the use of a rogue >> software component. If untrusted environments are used by a subject, >> these security implications can be limited through use of the following >> measures: >> – to not combine the contentCommitment key usage setting in >> certificates with any other key usage setting and to use the >> corresponding private key only with this certificate; >> >> – to limit the use of private keys associated with certificates that >> have the contentCommitment key usage bit set, to environments which >> are considered adequately controlled and trustworthy" >> >> So maybe it's useful to add a warning if both keyCertSign and >> digitalSignature are asserted. > > Coiby, thank you for adding these details. I was hoping others would > chime in as well. I agree at minimum there should be a warning. A warning could be added. > Perhaps instead of making INTEGRITY_CA_MACHINE_KEYRING dependent on > INTEGRITY_MACHINE_KEYRING, make them a Kconfig "choice" to support the > more restrictive certificate use case requirements: all certificates, > CA certificate signing and digital signature, only CA certificate > signing. As could support for additional restrictions. Would these additions be required within this series? What is missing from this discussion is why would these additions be necessary? Why should the kernel enforce a restriction that is beyond the scope of the X.509 spec? If a warning was to be added, what would be the justification for adding this additional code? From my research every single 3rd party code signing intermediate CA would be flagged with the warning. Isn’t this just going to cause confusion? Or is there a benefit that I am missing that needs to be stated?
> On Dec 21, 2022, at 12:01 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Wed, 2022-12-21 at 18:27 +0000, Eric Snowberg wrote: >> >>> On Dec 18, 2022, at 5:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>> On Fri, 2022-12-16 at 22:06 +0800, Coiby Xu wrote: >>>> Hi Eric and Mimi, >>>> >>>> On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote: >>>>> >>>>> >>>>>>>>>>> A CA cert shall be defined as any X509 certificate that contains the >>>>>>>>>>> keyCertSign key usage and has the CA bit set to true. >>>>>>>>>> >>>>>>>>>> Hi Eric, >>>>>>>>>> >>>>>>>>>> Allowing CA certificates with the digitalSignature key usage flag >>>>>>>>>> enabled defeats the purpose of the new Kconfig. Please update the >>>>>>>>>> above definition to exclude the digitalSignature key usage flag and >>>>>>>>>> modify the code accordingly. >>>>>>>>> >>>>>>>>> Within v2, the request was made to allow Intermediate CA certificates to be >>>>>>>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >>>>>>>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >>>>>>>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >>>>>>>>> the intent? >>>>>>>> >>>>>>>> That definitely was not the intent. Nor would it address the issue of >>>>>>>> a particular intermediate CA certificate having both keyCertSign and >>>>>>>> digitalSignature. >>>>>>> >>>>>>> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains >>>>>>> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate >>>>>>> CA cert like the one used on kernel.org? >>>>>> >>>>>> I must be missing something. Isn't the purpose of "keyUsage" to >>>>>> minimize how a certificate may be used? Why would we want the same >>>>>> certificate to be used for both certificate signing and code signing? >>>>> >>>>> Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. >>>>> Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature >>>>> set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be >>>>> challenging and will severely limit usage. >>>> >>>> How about allowing both keyCertSign and digitalSignature asserted but >>>> issuing a warning for this case? >>>> >>>> Here's my rationale for this proposal. >>>> >>>> I assume we should conform to some X.509 specifications. So I checked >>>> "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and >>>> Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10) >>>> [2]. >>>> >>>> [1] states in 4.2.1.3. Key Usage, >>>> "If the keyUsage extension is present, then the subject public key >>>> MUST NOT be used to verify signatures on certificates or CRLs unless >>>> the corresponding keyCertSign or cRLSign bit is set. If the subject >>>> public key is only to be used for verifying signatures on >>>> certificates and/or CRLs, then the digitalSignature and >>>> nonRepudiation bits SHOULD NOT be set. However, the digitalSignature >>>> and/or nonRepudiation bits MAY be set in addition to the keyCertSign >>>> and/or cRLSign bits if the subject public key is to be used to verify >>>> signatures on certificates and/or CRLs as well as other objects." >>>> >>>> and [2] states in 8.2.2.3 Key usage extension that, >>>> "More than one bit may be set in an instance of the keyUsage extension. >>>> The setting of multiple bits shall not change the meaning of each >>>> individual bit but shall indicate that the certificate may be used for >>>> all of the purposes indicated by the set bits. There may be risks >>>> incurred when setting multiple bits. A review of those risks is >>>> documented in Annex I." >>>> >>>> I interpret the above texts as we should allow both keyCertSign and >>>> digitalSignature. However [2] warns about the risks of setting multiple >>>> bits. Quoting Annex I, >>>> >>>> "Combining the contentCommitment bit in the keyUsage certificate >>>> extension with other keyUsage bits may have security implications >>>> depending on the security environment in which the certificate is to be >>>> used. If the subject's environment can be fully controlled and trusted, >>>> then there are no specific security implications. For example, in cases >>>> where the subject is fully confident about exactly which data is signed >>>> or cases where the subject is fully confident about the security >>>> characteristics of the authentication protocol being used. If the >>>> subject's environment is not fully controlled or not fully trusted, then >>>> unintentional signing of commitments is possible. Examples include the >>>> use of badly formed authentication exchanges and the use of a rogue >>>> software component. If untrusted environments are used by a subject, >>>> these security implications can be limited through use of the following >>>> measures: >>>> – to not combine the contentCommitment key usage setting in >>>> certificates with any other key usage setting and to use the >>>> corresponding private key only with this certificate; >>>> >>>> – to limit the use of private keys associated with certificates that >>>> have the contentCommitment key usage bit set, to environments which >>>> are considered adequately controlled and trustworthy" >>>> >>>> So maybe it's useful to add a warning if both keyCertSign and >>>> digitalSignature are asserted. >>> >>> Coiby, thank you for adding these details. I was hoping others would >>> chime in as well. I agree at minimum there should be a warning. >> >> A warning could be added. >> >>> Perhaps instead of making INTEGRITY_CA_MACHINE_KEYRING dependent on >>> INTEGRITY_MACHINE_KEYRING, make them a Kconfig "choice" to support the >>> more restrictive certificate use case requirements: all certificates, >>> CA certificate signing and digital signature, only CA certificate >>> signing. >> >> As could support for additional restrictions. >> >> Would these additions be required within this series? What is missing from this >> discussion is why would these additions be necessary? Why should the kernel >> enforce a restriction that is beyond the scope of the X.509 spec? If a warning was >> to be added, what would be the justification for adding this additional code? From >> my research every single 3rd party code signing intermediate CA would be flagged >> with the warning. Isn’t this just going to cause confusion? Or is there a benefit that >> I am missing that needs to be stated? > > You're focusing on third party kernel modules and forgetting about the > simple use case of allowing an end user (or business) to sign their own > code. True they could use the less restrictive CA certificates, but it > is unnecessary. My focus is on signing user-space applications, as outlined in the cover letter. This series has nothing to do with kernel modules. Most end-users and businesses rely on a third party to deal with code signing. All third party code signing services I have found use an intermediate CA containing more than just the keyCertSign usage set. It seems to be an industry accepted practice that does not violate the spec. Before writing new code to either warn or exclude a third party intermediate CA, I would like to understand the motivation behind this request.
On Thu, 2022-12-22 at 15:15 +0000, Eric Snowberg wrote: > > > On Dec 21, 2022, at 12:01 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Wed, 2022-12-21 at 18:27 +0000, Eric Snowberg wrote: > >> > >>> On Dec 18, 2022, at 5:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > >>> > >>> On Fri, 2022-12-16 at 22:06 +0800, Coiby Xu wrote: > >>>> Hi Eric and Mimi, > >>>> > >>>> On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote: > >>>>> > >>>>> > >>>>>>>>>>> A CA cert shall be defined as any X509 certificate that contains the > >>>>>>>>>>> keyCertSign key usage and has the CA bit set to true. > >>>>>>>>>> > >>>>>>>>>> Hi Eric, > >>>>>>>>>> > >>>>>>>>>> Allowing CA certificates with the digitalSignature key usage flag > >>>>>>>>>> enabled defeats the purpose of the new Kconfig. Please update the > >>>>>>>>>> above definition to exclude the digitalSignature key usage flag and > >>>>>>>>>> modify the code accordingly. > >>>>>>>>> > >>>>>>>>> Within v2, the request was made to allow Intermediate CA certificates to be > >>>>>>>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. > >>>>>>>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code > >>>>>>>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that > >>>>>>>>> the intent? > >>>>>>>> > >>>>>>>> That definitely was not the intent. Nor would it address the issue of > >>>>>>>> a particular intermediate CA certificate having both keyCertSign and > >>>>>>>> digitalSignature. > >>>>>>> > >>>>>>> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains > >>>>>>> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate > >>>>>>> CA cert like the one used on kernel.org? > >>>>>> > >>>>>> I must be missing something. Isn't the purpose of "keyUsage" to > >>>>>> minimize how a certificate may be used? Why would we want the same > >>>>>> certificate to be used for both certificate signing and code signing? > >>>>> > >>>>> Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. > >>>>> Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature > >>>>> set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be > >>>>> challenging and will severely limit usage. > >>>> > >>>> How about allowing both keyCertSign and digitalSignature asserted but > >>>> issuing a warning for this case? > >>>> > >>>> Here's my rationale for this proposal. > >>>> > >>>> I assume we should conform to some X.509 specifications. So I checked > >>>> "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and > >>>> Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10) > >>>> [2]. > >>>> > >>>> [1] states in 4.2.1.3. Key Usage, > >>>> "If the keyUsage extension is present, then the subject public key > >>>> MUST NOT be used to verify signatures on certificates or CRLs unless > >>>> the corresponding keyCertSign or cRLSign bit is set. If the subject > >>>> public key is only to be used for verifying signatures on > >>>> certificates and/or CRLs, then the digitalSignature and > >>>> nonRepudiation bits SHOULD NOT be set. However, the digitalSignature > >>>> and/or nonRepudiation bits MAY be set in addition to the keyCertSign > >>>> and/or cRLSign bits if the subject public key is to be used to verify > >>>> signatures on certificates and/or CRLs as well as other objects." > >>>> > >>>> and [2] states in 8.2.2.3 Key usage extension that, > >>>> "More than one bit may be set in an instance of the keyUsage extension. > >>>> The setting of multiple bits shall not change the meaning of each > >>>> individual bit but shall indicate that the certificate may be used for > >>>> all of the purposes indicated by the set bits. There may be risks > >>>> incurred when setting multiple bits. A review of those risks is > >>>> documented in Annex I." > >>>> > >>>> I interpret the above texts as we should allow both keyCertSign and > >>>> digitalSignature. However [2] warns about the risks of setting multiple > >>>> bits. Quoting Annex I, > >>>> > >>>> "Combining the contentCommitment bit in the keyUsage certificate > >>>> extension with other keyUsage bits may have security implications > >>>> depending on the security environment in which the certificate is to be > >>>> used. If the subject's environment can be fully controlled and trusted, > >>>> then there are no specific security implications. For example, in cases > >>>> where the subject is fully confident about exactly which data is signed > >>>> or cases where the subject is fully confident about the security > >>>> characteristics of the authentication protocol being used. If the > >>>> subject's environment is not fully controlled or not fully trusted, then > >>>> unintentional signing of commitments is possible. Examples include the > >>>> use of badly formed authentication exchanges and the use of a rogue > >>>> software component. If untrusted environments are used by a subject, > >>>> these security implications can be limited through use of the following > >>>> measures: > >>>> – to not combine the contentCommitment key usage setting in > >>>> certificates with any other key usage setting and to use the > >>>> corresponding private key only with this certificate; > >>>> > >>>> – to limit the use of private keys associated with certificates that > >>>> have the contentCommitment key usage bit set, to environments which > >>>> are considered adequately controlled and trustworthy" > >>>> > >>>> So maybe it's useful to add a warning if both keyCertSign and > >>>> digitalSignature are asserted. > >>> > >>> Coiby, thank you for adding these details. I was hoping others would > >>> chime in as well. I agree at minimum there should be a warning. > >> > >> A warning could be added. > >> > >>> Perhaps instead of making INTEGRITY_CA_MACHINE_KEYRING dependent on > >>> INTEGRITY_MACHINE_KEYRING, make them a Kconfig "choice" to support the > >>> more restrictive certificate use case requirements: all certificates, > >>> CA certificate signing and digital signature, only CA certificate > >>> signing. > >> > >> As could support for additional restrictions. > >> > >> Would these additions be required within this series? What is missing from this > >> discussion is why would these additions be necessary? Why should the kernel > >> enforce a restriction that is beyond the scope of the X.509 spec? If a warning was > >> to be added, what would be the justification for adding this additional code? From > >> my research every single 3rd party code signing intermediate CA would be flagged > >> with the warning. Isn’t this just going to cause confusion? Or is there a benefit that > >> I am missing that needs to be stated? > > > > You're focusing on third party kernel modules and forgetting about the > > simple use case of allowing an end user (or business) to sign their own > > code. True they could use the less restrictive CA certificates, but it > > is unnecessary. > > My focus is on signing user-space applications, as outlined in the cover letter. This > series has nothing to do with kernel modules. Most end-users and businesses rely on > a third party to deal with code signing. All third party code signing services I have > found use an intermediate CA containing more than just the keyCertSign usage set. > It seems to be an industry accepted practice that does not violate the spec. Before writing > new code to either warn or exclude a third party intermediate CA, I would like to understand > the motivation behind this request. In older discussions there are comments like, "Any CA certificate, no matter if it's a root or an intermediate, must have the keyCertSign extension. If you want to sign a revocation list (CRL) with the CA certificate as well (you usually do want that), than you have to add cRLSign as well. Any other keyUsages can and should be avoided for CA certificates." The question as to "why" this changed to include "digitalSignature" was posed here [2] with the response being for "OCSP". It also includes a link to Entrusts root and intermediate CAs with just keyCertSign and cRLSign keyUsages. The matchine keyring is a means of establishing a new root of trust. The motivation for further restricting CA certificates to just keyCertSign and cRLSign keyUsages is to limit how the CA certificates may be used. They should not be used for code signing. thanks, Mimi [1] https://superuser.com/questions/738612/openssl-ca-keyusage-extension [2] https://security.stackexchange.com/questions/231133/keyusage-extensions-on-a-certificate-authority
> On Dec 22, 2022, at 8:41 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2022-12-22 at 15:15 +0000, Eric Snowberg wrote: >> >>> On Dec 21, 2022, at 12:01 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>> On Wed, 2022-12-21 at 18:27 +0000, Eric Snowberg wrote: >>>> >>>>> On Dec 18, 2022, at 5:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>>>> >>>>> On Fri, 2022-12-16 at 22:06 +0800, Coiby Xu wrote: >>>>>> Hi Eric and Mimi, >>>>>> >>>>>> On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote: >>>>>>> >>>>>>> >>>>>>>>>>>>> A CA cert shall be defined as any X509 certificate that contains the >>>>>>>>>>>>> keyCertSign key usage and has the CA bit set to true. >>>>>>>>>>>> >>>>>>>>>>>> Hi Eric, >>>>>>>>>>>> >>>>>>>>>>>> Allowing CA certificates with the digitalSignature key usage flag >>>>>>>>>>>> enabled defeats the purpose of the new Kconfig. Please update the >>>>>>>>>>>> above definition to exclude the digitalSignature key usage flag and >>>>>>>>>>>> modify the code accordingly. >>>>>>>>>>> >>>>>>>>>>> Within v2, the request was made to allow Intermediate CA certificates to be >>>>>>>>>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >>>>>>>>>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >>>>>>>>>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >>>>>>>>>>> the intent? >>>>>>>>>> >>>>>>>>>> That definitely was not the intent. Nor would it address the issue of >>>>>>>>>> a particular intermediate CA certificate having both keyCertSign and >>>>>>>>>> digitalSignature. >>>>>>>>> >>>>>>>>> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains >>>>>>>>> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate >>>>>>>>> CA cert like the one used on kernel.org? >>>>>>>> >>>>>>>> I must be missing something. Isn't the purpose of "keyUsage" to >>>>>>>> minimize how a certificate may be used? Why would we want the same >>>>>>>> certificate to be used for both certificate signing and code signing? >>>>>>> >>>>>>> Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. >>>>>>> Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature >>>>>>> set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be >>>>>>> challenging and will severely limit usage. >>>>>> >>>>>> How about allowing both keyCertSign and digitalSignature asserted but >>>>>> issuing a warning for this case? >>>>>> >>>>>> Here's my rationale for this proposal. >>>>>> >>>>>> I assume we should conform to some X.509 specifications. So I checked >>>>>> "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and >>>>>> Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10) >>>>>> [2]. >>>>>> >>>>>> [1] states in 4.2.1.3. Key Usage, >>>>>> "If the keyUsage extension is present, then the subject public key >>>>>> MUST NOT be used to verify signatures on certificates or CRLs unless >>>>>> the corresponding keyCertSign or cRLSign bit is set. If the subject >>>>>> public key is only to be used for verifying signatures on >>>>>> certificates and/or CRLs, then the digitalSignature and >>>>>> nonRepudiation bits SHOULD NOT be set. However, the digitalSignature >>>>>> and/or nonRepudiation bits MAY be set in addition to the keyCertSign >>>>>> and/or cRLSign bits if the subject public key is to be used to verify >>>>>> signatures on certificates and/or CRLs as well as other objects." >>>>>> >>>>>> and [2] states in 8.2.2.3 Key usage extension that, >>>>>> "More than one bit may be set in an instance of the keyUsage extension. >>>>>> The setting of multiple bits shall not change the meaning of each >>>>>> individual bit but shall indicate that the certificate may be used for >>>>>> all of the purposes indicated by the set bits. There may be risks >>>>>> incurred when setting multiple bits. A review of those risks is >>>>>> documented in Annex I." >>>>>> >>>>>> I interpret the above texts as we should allow both keyCertSign and >>>>>> digitalSignature. However [2] warns about the risks of setting multiple >>>>>> bits. Quoting Annex I, >>>>>> >>>>>> "Combining the contentCommitment bit in the keyUsage certificate >>>>>> extension with other keyUsage bits may have security implications >>>>>> depending on the security environment in which the certificate is to be >>>>>> used. If the subject's environment can be fully controlled and trusted, >>>>>> then there are no specific security implications. For example, in cases >>>>>> where the subject is fully confident about exactly which data is signed >>>>>> or cases where the subject is fully confident about the security >>>>>> characteristics of the authentication protocol being used. If the >>>>>> subject's environment is not fully controlled or not fully trusted, then >>>>>> unintentional signing of commitments is possible. Examples include the >>>>>> use of badly formed authentication exchanges and the use of a rogue >>>>>> software component. If untrusted environments are used by a subject, >>>>>> these security implications can be limited through use of the following >>>>>> measures: >>>>>> – to not combine the contentCommitment key usage setting in >>>>>> certificates with any other key usage setting and to use the >>>>>> corresponding private key only with this certificate; >>>>>> >>>>>> – to limit the use of private keys associated with certificates that >>>>>> have the contentCommitment key usage bit set, to environments which >>>>>> are considered adequately controlled and trustworthy" >>>>>> >>>>>> So maybe it's useful to add a warning if both keyCertSign and >>>>>> digitalSignature are asserted. >>>>> >>>>> Coiby, thank you for adding these details. I was hoping others would >>>>> chime in as well. I agree at minimum there should be a warning. >>>> >>>> A warning could be added. >>>> >>>>> Perhaps instead of making INTEGRITY_CA_MACHINE_KEYRING dependent on >>>>> INTEGRITY_MACHINE_KEYRING, make them a Kconfig "choice" to support the >>>>> more restrictive certificate use case requirements: all certificates, >>>>> CA certificate signing and digital signature, only CA certificate >>>>> signing. >>>> >>>> As could support for additional restrictions. >>>> >>>> Would these additions be required within this series? What is missing from this >>>> discussion is why would these additions be necessary? Why should the kernel >>>> enforce a restriction that is beyond the scope of the X.509 spec? If a warning was >>>> to be added, what would be the justification for adding this additional code? From >>>> my research every single 3rd party code signing intermediate CA would be flagged >>>> with the warning. Isn’t this just going to cause confusion? Or is there a benefit that >>>> I am missing that needs to be stated? >>> >>> You're focusing on third party kernel modules and forgetting about the >>> simple use case of allowing an end user (or business) to sign their own >>> code. True they could use the less restrictive CA certificates, but it >>> is unnecessary. >> >> My focus is on signing user-space applications, as outlined in the cover letter. This >> series has nothing to do with kernel modules. Most end-users and businesses rely on >> a third party to deal with code signing. All third party code signing services I have >> found use an intermediate CA containing more than just the keyCertSign usage set. >> It seems to be an industry accepted practice that does not violate the spec. Before writing >> new code to either warn or exclude a third party intermediate CA, I would like to understand >> the motivation behind this request. > > In older discussions there are comments like, "Any CA certificate, no > matter if it's a root or an intermediate, must have the keyCertSign > extension. If you want to sign a revocation list (CRL) with the CA > certificate as well (you usually do want that), than you have to add > cRLSign as well. Any other keyUsages can and should be avoided for CA > certificates." > > The question as to "why" this changed to include "digitalSignature" was > posed here [2] with the response being for "OCSP". It also includes a > link to Entrusts root and intermediate CAs with just keyCertSign and > cRLSign keyUsages. > > The matchine keyring is a means of establishing a new root of trust. > The motivation for further restricting CA certificates to just > keyCertSign and cRLSign keyUsages is to limit how the CA certificates > may be used. They should not be used for code signing. Fair enough. If this will be viewed as justification for adding the additional code, I can work on adding it. Above you mentioned a warning would be needed at a minimum and a restriction could be placed behind a Kconfig. How about for the default case I add the warning and when compiling with INTEGRITY_CA_MACHINE_KEYRING the restriction will be enforced.
> On Dec 23, 2022, at 9:34 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Fri, 2022-12-23 at 16:13 +0000, Eric Snowberg wrote: >> >>> On Dec 22, 2022, at 8:41 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>> On Thu, 2022-12-22 at 15:15 +0000, Eric Snowberg wrote: >>>> >>>>> On Dec 21, 2022, at 12:01 PM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>>>> >>>>> On Wed, 2022-12-21 at 18:27 +0000, Eric Snowberg wrote: >>>>>> >>>>>>> On Dec 18, 2022, at 5:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>>>>>> >>>>>>> On Fri, 2022-12-16 at 22:06 +0800, Coiby Xu wrote: >>>>>>>> Hi Eric and Mimi, >>>>>>>> >>>>>>>> On Thu, Dec 15, 2022 at 09:45:37PM +0000, Eric Snowberg wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> A CA cert shall be defined as any X509 certificate that contains the >>>>>>>>>>>>>>> keyCertSign key usage and has the CA bit set to true. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Allowing CA certificates with the digitalSignature key usage flag >>>>>>>>>>>>>> enabled defeats the purpose of the new Kconfig. Please update the >>>>>>>>>>>>>> above definition to exclude the digitalSignature key usage flag and >>>>>>>>>>>>>> modify the code accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> Within v2, the request was made to allow Intermediate CA certificates to be >>>>>>>>>>>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >>>>>>>>>>>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >>>>>>>>>>>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >>>>>>>>>>>>> the intent? >>>>>>>>>>>> >>>>>>>>>>>> That definitely was not the intent. Nor would it address the issue of >>>>>>>>>>>> a particular intermediate CA certificate having both keyCertSign and >>>>>>>>>>>> digitalSignature. >>>>>>>>>>> >>>>>>>>>>> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains >>>>>>>>>>> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate >>>>>>>>>>> CA cert like the one used on kernel.org? >>>>>>>>>> >>>>>>>>>> I must be missing something. Isn't the purpose of "keyUsage" to >>>>>>>>>> minimize how a certificate may be used? Why would we want the same >>>>>>>>>> certificate to be used for both certificate signing and code signing? >>>>>>>>> >>>>>>>>> Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. >>>>>>>>> Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature >>>>>>>>> set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be >>>>>>>>> challenging and will severely limit usage. >>>>>>>> >>>>>>>> How about allowing both keyCertSign and digitalSignature asserted but >>>>>>>> issuing a warning for this case? >>>>>>>> >>>>>>>> Here's my rationale for this proposal. >>>>>>>> >>>>>>>> I assume we should conform to some X.509 specifications. So I checked >>>>>>>> "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and >>>>>>>> Certificate Revocation List (CRL) Profile" [1] and ITU-T X.509 (2012-10) >>>>>>>> [2]. >>>>>>>> >>>>>>>> [1] states in 4.2.1.3. Key Usage, >>>>>>>> "If the keyUsage extension is present, then the subject public key >>>>>>>> MUST NOT be used to verify signatures on certificates or CRLs unless >>>>>>>> the corresponding keyCertSign or cRLSign bit is set. If the subject >>>>>>>> public key is only to be used for verifying signatures on >>>>>>>> certificates and/or CRLs, then the digitalSignature and >>>>>>>> nonRepudiation bits SHOULD NOT be set. However, the digitalSignature >>>>>>>> and/or nonRepudiation bits MAY be set in addition to the keyCertSign >>>>>>>> and/or cRLSign bits if the subject public key is to be used to verify >>>>>>>> signatures on certificates and/or CRLs as well as other objects." >>>>>>>> >>>>>>>> and [2] states in 8.2.2.3 Key usage extension that, >>>>>>>> "More than one bit may be set in an instance of the keyUsage extension. >>>>>>>> The setting of multiple bits shall not change the meaning of each >>>>>>>> individual bit but shall indicate that the certificate may be used for >>>>>>>> all of the purposes indicated by the set bits. There may be risks >>>>>>>> incurred when setting multiple bits. A review of those risks is >>>>>>>> documented in Annex I." >>>>>>>> >>>>>>>> I interpret the above texts as we should allow both keyCertSign and >>>>>>>> digitalSignature. However [2] warns about the risks of setting multiple >>>>>>>> bits. Quoting Annex I, >>>>>>>> >>>>>>>> "Combining the contentCommitment bit in the keyUsage certificate >>>>>>>> extension with other keyUsage bits may have security implications >>>>>>>> depending on the security environment in which the certificate is to be >>>>>>>> used. If the subject's environment can be fully controlled and trusted, >>>>>>>> then there are no specific security implications. For example, in cases >>>>>>>> where the subject is fully confident about exactly which data is signed >>>>>>>> or cases where the subject is fully confident about the security >>>>>>>> characteristics of the authentication protocol being used. If the >>>>>>>> subject's environment is not fully controlled or not fully trusted, then >>>>>>>> unintentional signing of commitments is possible. Examples include the >>>>>>>> use of badly formed authentication exchanges and the use of a rogue >>>>>>>> software component. If untrusted environments are used by a subject, >>>>>>>> these security implications can be limited through use of the following >>>>>>>> measures: >>>>>>>> – to not combine the contentCommitment key usage setting in >>>>>>>> certificates with any other key usage setting and to use the >>>>>>>> corresponding private key only with this certificate; >>>>>>>> >>>>>>>> – to limit the use of private keys associated with certificates that >>>>>>>> have the contentCommitment key usage bit set, to environments which >>>>>>>> are considered adequately controlled and trustworthy" >>>>>>>> >>>>>>>> So maybe it's useful to add a warning if both keyCertSign and >>>>>>>> digitalSignature are asserted. >>>>>>> >>>>>>> Coiby, thank you for adding these details. I was hoping others would >>>>>>> chime in as well. I agree at minimum there should be a warning. >>>>>> >>>>>> A warning could be added. >>>>>> >>>>>>> Perhaps instead of making INTEGRITY_CA_MACHINE_KEYRING dependent on >>>>>>> INTEGRITY_MACHINE_KEYRING, make them a Kconfig "choice" to support the >>>>>>> more restrictive certificate use case requirements: all certificates, >>>>>>> CA certificate signing and digital signature, only CA certificate >>>>>>> signing. >>>>>> >>>>>> As could support for additional restrictions. >>>>>> >>>>>> Would these additions be required within this series? What is missing from this >>>>>> discussion is why would these additions be necessary? Why should the kernel >>>>>> enforce a restriction that is beyond the scope of the X.509 spec? If a warning was >>>>>> to be added, what would be the justification for adding this additional code? From >>>>>> my research every single 3rd party code signing intermediate CA would be flagged >>>>>> with the warning. Isn’t this just going to cause confusion? Or is there a benefit that >>>>>> I am missing that needs to be stated? >>>>> >>>>> You're focusing on third party kernel modules and forgetting about the >>>>> simple use case of allowing an end user (or business) to sign their own >>>>> code. True they could use the less restrictive CA certificates, but it >>>>> is unnecessary. >>>> >>>> My focus is on signing user-space applications, as outlined in the cover letter. This >>>> series has nothing to do with kernel modules. Most end-users and businesses rely on >>>> a third party to deal with code signing. All third party code signing services I have >>>> found use an intermediate CA containing more than just the keyCertSign usage set. >>>> It seems to be an industry accepted practice that does not violate the spec. Before writing >>>> new code to either warn or exclude a third party intermediate CA, I would like to understand >>>> the motivation behind this request. >>> >>> In older discussions there are comments like, "Any CA certificate, no >>> matter if it's a root or an intermediate, must have the keyCertSign >>> extension. If you want to sign a revocation list (CRL) with the CA >>> certificate as well (you usually do want that), than you have to add >>> cRLSign as well. Any other keyUsages can and should be avoided for CA >>> certificates." >>> >>> The question as to "why" this changed to include "digitalSignature" was >>> posed here [2] with the response being for "OCSP". It also includes a >>> link to Entrusts root and intermediate CAs with just keyCertSign and >>> cRLSign keyUsages. >>> >>> The matchine keyring is a means of establishing a new root of trust. >>> The motivation for further restricting CA certificates to just >>> keyCertSign and cRLSign keyUsages is to limit how the CA certificates >>> may be used. They should not be used for code signing. >> >> Fair enough. If this will be viewed as justification for adding the additional >> code, I can work on adding it. Above you mentioned a warning would be needed >> at a minimum and a restriction could be placed behind a Kconfig. How about for >> the default case I add the warning and when compiling with >> INTEGRITY_CA_MACHINE_KEYRING the restriction will be enforced. > > Sounds good to me. To avoid misunderstandings, will there be a Kconfig > menu with 3 options? I will add the three options in the next round. > There were a couple of other comments having to > do with variable names. Will you address them as well? And take care of the variable name changes. I won’t get back to this until January.
On Tue, Dec 13, 2022 at 07:33:55PM -0500, Eric Snowberg wrote: > Parse the X.509 Key Usage. The key usage extension defines the purpose of > the key contained in the certificate. > > id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } > > KeyUsage ::= BIT STRING { > digitalSignature (0), > contentCommitment (1), > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } > > If the keyCertSign is set, store it in the x509_certificate structure. > This will be used in a follow on patch that requires knowing the > certificate key usage type. > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> > --- > crypto/asymmetric_keys/x509_cert_parser.c | 22 ++++++++++++++++++++++ > crypto/asymmetric_keys/x509_parser.h | 1 + > 2 files changed, 23 insertions(+) > > diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c > index b4443e507153..edb22cf04eed 100644 > --- a/crypto/asymmetric_keys/x509_cert_parser.c > +++ b/crypto/asymmetric_keys/x509_cert_parser.c > @@ -579,6 +579,28 @@ int x509_process_extension(void *context, size_t hdrlen, > return 0; > } > > + if (ctx->last_oid == OID_keyUsage) { > + /* > + * Get hold of the keyUsage bit string to validate keyCertSign > + * v[1] is the encoding size > + * (Expect either 0x02 or 0x03, making it 1 or 2 bytes) > + * v[2] is the number of unused bits in the bit string > + * (If >= 3 keyCertSign is missing) > + * v[3] and possibly v[4] contain the bit string > + * 0x04 is where KeyCertSign lands in this bit string (from > + * RFC 5280 4.2.1.3) > + */ > + if (v[0] != ASN1_BTS) > + return -EBADMSG; > + if (vlen < 4) > + return -EBADMSG; > + if (v[1] == 0x02 && v[2] <= 2 && (v[3] & 0x04)) > + ctx->cert->kcs_set = true; > + else if (vlen > 4 && v[1] == 0x03 && (v[3] & 0x04)) > + ctx->cert->kcs_set = true; > + return 0; This is much more easier to follow thanks to explanation. > + } > + > if (ctx->last_oid == OID_authorityKeyIdentifier) { > /* Get hold of the CA key fingerprint */ > ctx->raw_akid = v; > diff --git a/crypto/asymmetric_keys/x509_parser.h b/crypto/asymmetric_keys/x509_parser.h > index 7c5c0ad1c22e..74a9f929e400 100644 > --- a/crypto/asymmetric_keys/x509_parser.h > +++ b/crypto/asymmetric_keys/x509_parser.h > @@ -39,6 +39,7 @@ struct x509_certificate { > bool unsupported_sig; /* T if signature uses unsupported crypto */ > bool blacklisted; > bool root_ca; /* T if basic constraints CA is set */ > + bool kcs_set; /* T if keyCertSign is set */ > }; > > /* > -- > 2.27.0 > LGTM but I'll hold with reviewed-by's up until the patch set overally looks good to me and I have actually tested it. BR, Jarkko
On Tue, Dec 13, 2022 at 07:34:00PM -0500, Eric Snowberg wrote: > +/** > + * restrict_link_by_ca - Restrict additions to a ring of CA keys > + * @dest_keyring: Keyring being linked to. > + * @type: The type of key being added. > + * @payload: The payload of the new key. > + * @trust_keyring: Unused. > + * > + * Check if the new certificate is a CA. If it is a CA, then mark the new > + * certificate as being ok to link. > + * > + * Returns 0 if the new certificate was accepted, -ENOKEY if the > + * certificate is not a CA. -ENOPKG if the signature uses unsupported > + * crypto, or some other error if there is a matching certificate but > + * the signature check cannot be performed. > + */ > +int restrict_link_by_ca(struct key *dest_keyring, > + const struct key_type *type, > + const union key_payload *payload, > + struct key *trust_keyring) Why you want to define trust_keyring, other than matching the parameter list in restrict_link_by_signature()? Also if it is unused, it should be then just "struct key *)", right? BR, Jarkko