ima: extending secure boot certificate chain of trust
Subsystems (7)
v5 cover ima: extending secure boot certificate chain of trust
The original patches extended the secure boot signature chain of trust to IMA-appraisal, by allowing only certificates signed by a 'trusted' key on the system_trusted_keyring to be added to the IMA keyring.
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, the last patch in this patch set further restricts the certificates to those signed by a particular key on the system keyring. (This is a total rewrite of the previous version.)
All comments have been addressed aside from the issue of requiring procfs for loading a key on the ima keyring.
Mimi
Mimi Zohar (4):
KEYS: special dot prefixed keyring name bug fix
KEYS: verify a certificate is signed by a 'trusted' key
ima: define '.ima' as a builtin 'trusted' keyring
KEYS: define an owner trusted keyring
Documentation/kernel-parameters.txt | 5 ++ crypto/asymmetric_keys/x509_public_key.c | 86 +++++++++++++++++++++++++++++++- include/keys/owner_keyring.h | 27 ++++++++++ include/keys/system_keyring.h | 10 +++- init/Kconfig | 10 ++++ kernel/Makefile | 1 + kernel/owner_keyring.c | 85 +++++++++++++++++++++++++++++++ security/integrity/digsig.c | 26 ++++++++++ security/integrity/ima/Kconfig | 8 +++ security/integrity/ima/ima_main.c | 12 ++++- security/integrity/integrity.h | 5 ++ security/keys/keyctl.c | 6 ++- 12 files changed, 275 insertions(+), 6 deletions(-) create mode 100644 include/keys/owner_keyring.h create mode 100644 kernel/owner_keyring.c
Signature · 1 line
1.8.1.4
RFC PATCH v5 1/4 KEYS: special dot prefixed keyring name bug fix
Dot prefixed keyring names are supposed to be reserved for the kernel, but add_key() calls key_get_type_from_user(), which incorrectly verifies the 'type' field, not the 'description' field. This patch verifies the 'description' field isn't dot prefixed, when creating a new keyring, and removes the dot prefix test in key_get_type_from_user().
Changelog v5:
- Only prevent userspace from creating a dot prefixed keyring, not regular keys - Dmitry
--- security/keys/keyctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
security/keys/keyctl.c +4 -2
@@ -37,8 +37,6 @@ static int key_get_type_from_user(char *type,return ret;if (ret ==0 || ret >= len)return -EINVAL ; -if (type[0 ] =='.' ) -return -EPERM ; type[len -1 ] ='\0' ;return 0 ; }
@@ -86,6 +84,10 @@ SYSCALL_DEFINE5(add_key, const char __user *, _type,if (!*description) {kfree (description); description =NULL ; + }else if ((description[0 ] =='.' ) && + (strncmp (type,"keyring" ,7 ) ==0 )) { + ret = -EPERM ; + goto error2; } }
Signature · 1 line
1.8.1.4
Dmitry Kasatkin
maintainerRe: [RFC PATCH v5 1/4] KEYS: special dot prefixed keyring name bug fix
Quoted 45 lines · Mimi Zohar
Dot prefixed keyring names are supposed to be reserved for the kernel, but
add_key()callskey_get_type_from_user(), which incorrectly verifies the 'type' field, not the 'description' field. This patch verifies the 'description' field isn't dot prefixed, when creating a new keyring, and removes the dot prefix test inkey_get_type_from_user().Changelog v5:
- Only prevent userspace from creating a dot prefixed keyring, not regular keys - DmitryReported-by Dmitry Kasatkin <[email protected]>Cc David Howells <[email protected]>Signed-off-by Mimi Zohar <[email protected]>--- security/keys/keyctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)security/keys/keyctl.c +4
-3@@ -37,8 +37,6 @@ static int key_get_type_from_user(char *type,return ret;if (ret ==0 || ret >= len)return -EINVAL ; -if (type[0 ] =='.' ) -return -EPERM ; type[len -1 ] ='\0' ;return 0 ; }@@ -86,6 +84,10 @@ SYSCALL_DEFINE5(add_key, const char __user *, _type,if (!*description) {kfree (description); description =NULL ; + }else if ((description[0 ] =='.' ) && + (strncmp (type,"keyring" ,7 ) ==0 )) { + ret = -EPERM ; + goto error2; } } --1.8.1.4
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I think it does not another problem...
It is not only prevent creating new keyring with ".abc" name but also prevent adding new key...
this is wrong...
- Dmitry
Re: [RFC PATCH v5 1/4] KEYS: special dot prefixed keyring name bug fix
Quoted 47 lines · Dmitry Kasatkin
Quoted 32 lines · Mimi Zohar
Dot prefixed keyring names are supposed to be reserved for the kernel, but
add_key()callskey_get_type_from_user(), which incorrectly verifies the 'type' field, not the 'description' field. This patch verifies the 'description' field isn't dot prefixed, when creating a new keyring, and removes the dot prefix test inkey_get_type_from_user().Changelog v5:
- Only prevent userspace from creating a dot prefixed keyring, not regular keys - DmitryReported-by Dmitry Kasatkin <[email protected]>Cc David Howells <[email protected]>Signed-off-by Mimi Zohar <[email protected]>--- security/keys/keyctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)security/keys/keyctl.c +0
-2@@ -37,8 +37,6 @@ static int key_get_type_from_user(char *type,return ret;if (ret ==0 || ret >= len)return -EINVAL ; -if (type[0 ] =='.' ) -return -EPERM ; type[len -1 ] ='\0' ;return 0 ; }security/keys/keyctl.c SYSCALL_DEFINE5(add_key, const char __user *, _type, · line 92
Quoted 9 lines
security/keys/keyctl.c +4
-0@@ -86,6 +84,10 @@ SYSCALL_DEFINE5(add_key, const char __user *, _type,if (!*description) {kfree (description); description =NULL ; + }else if ((description[0 ] =='.' ) && + (strncmp (type,"keyring" ,7 ) ==0 )) { + ret = -EPERM ; + goto error2; } }I think it does not another problem...
It is not only prevent creating new keyring with ".abc" name but also prevent adding new key...
Quoted 1 line
this is wrong...
Seems to prevent creating a dot prefixed keyring, but permits creating a dot prefixed key. Do you have an example?
thanks,
Mimi
Mimi
Re: [RFC PATCH v5 1/4] KEYS: special dot prefixed keyring name bug fix
Quoted 47 lines · Mimi Zohar
Quoted 46 lines · Dmitry Kasatkin
Quoted 32 lines · Mimi Zohar
Dot prefixed keyring names are supposed to be reserved for the kernel, but
add_key()callskey_get_type_from_user(), which incorrectly verifies the 'type' field, not the 'description' field. This patch verifies the 'description' field isn't dot prefixed, when creating a new keyring, and removes the dot prefix test inkey_get_type_from_user().Changelog v5:
- Only prevent userspace from creating a dot prefixed keyring, not regular keys - DmitryReported-by Dmitry Kasatkin <[email protected]>Cc David Howells <[email protected]>Signed-off-by Mimi Zohar <[email protected]>--- security/keys/keyctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)security/keys/keyctl.c +0
-2@@ -37,8 +37,6 @@ static int key_get_type_from_user(char *type,return ret;if (ret ==0 || ret >= len)return -EINVAL ; -if (type[0 ] =='.' ) -return -EPERM ; type[len -1 ] ='\0' ;return 0 ; }security/keys/keyctl.c SYSCALL_DEFINE5(add_key, const char __user *, _type, · line 92
Quoted 9 lines
security/keys/keyctl.c +4
-0@@ -86,6 +84,10 @@ SYSCALL_DEFINE5(add_key, const char __user *, _type,if (!*description) {kfree (description); description =NULL ; + }else if ((description[0 ] =='.' ) && + (strncmp (type,"keyring" ,7 ) ==0 )) { + ret = -EPERM ; + goto error2; } }I think it does not another problem...
It is not only prevent creating new keyring with ".abc" name but also prevent adding new key...
Quoted 3 lines
Quoted 1 line
this is wrong...
Seems to prevent creating a dot prefixed keyring, but permits creating a dot prefixed key. Do you have an example?
I think by mistake I was checking old patch in the thread because I have not noticed strncmp(type, "keyring", 7).
This patch definitely should do the job.
- Dmitry
Quoted 8 lines
thanks,
Mimi
Mimi
Re: [RFC PATCH v5 1/4] KEYS: special dot prefixed keyring name bug fix
Quoted 32 lines · Dmitry Kasatkin
Quoted 31 lines · Mimi Zohar
Quoted 30 lines · Dmitry Kasatkin
Quoted 29 lines · Mimi Zohar
Dot prefixed keyring names are supposed to be reserved for the kernel, but
add_key()callskey_get_type_from_user(), which incorrectly verifies the 'type' field, not the 'description' field. This patch verifies the 'description' field isn't dot prefixed, when creating a new keyring, and removes the dot prefix test inkey_get_type_from_user().Changelog v5:
- Only prevent userspace from creating a dot prefixed keyring, not regular keys - DmitryReported-by Dmitry Kasatkin <[email protected]>Cc David Howells <[email protected]>Signed-off-by Mimi Zohar <[email protected]>--- security/keys/keyctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)security/keys/keyctl.c +0
-2@@ -37,8 +37,6 @@ static int key_get_type_from_user(char *type,return ret;if (ret ==0 || ret >= len)return -EINVAL ; -if (type[0 ] =='.' ) -return -EPERM ; type[len -1 ] ='\0' ;
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
security/keys/keyctl.c SYSCALL_DEFINE5(add_key, const char __user *, _type, · line 88
Quoted 8 lines
security/keys/keyctl.c +2
-0return 0 ; }@@ -86,6 +84,10 @@ SYSCALL_DEFINE5(add_key, const char __user *, _type,if (!*description) {kfree (description); description =NULL ; + }else if ((description[0 ] =='.' ) && + (strncmp (type,"keyring" ,7 ) ==0 )) {
BTW. using strcmp is good enough here. string constants are always NULL terminated.
Comparison will terminate after no more than 7 bytes.
Quoted 26 lines
Quoted 11 lines
Quoted 9 lines
security/keys/keyctl.c SYSCALL_DEFINE5(add_key, const char __user *, _type, · line 92
Quoted 4 lines
security/keys/keyctl.c +2
-0+ ret = -EPERM ; + goto error2; } }I think it does not another problem...
It is not only prevent creating new keyring with ".abc" name but also prevent adding new key...this is wrong...
Seems to prevent creating a dot prefixed keyring, but permits creating a dot prefixed key. Do you have an example?
I think by mistake I was checking old patch in the thread because I have not noticed
strncmp(type, "keyring", 7).
This patch definitely should do the job.- Dmitry
Quoted 8 lines
thanks,
Mimi
Mimi
RFC PATCH v5 2/4 KEYS: verify a certificate is signed by a 'trusted' key
In reply to Mimi ZoharOnly public keys, with certificates signed by an existing 'trusted' key on the system trusted keyring, should be added to a trusted keyring. This patch adds support for verifying a certificate's signature.
This is derived from David Howells pkcs7_request_asymmetric_key() patch.
Changelog:
- define get_system_trusted_keyring() to fix kbuild issues
--- crypto/asymmetric_keys/x509_public_key.c | 84 +++++++++++++++++++++++++++++++- include/keys/system_keyring.h | 10 +++- 2 files changed, 92 insertions(+), 2 deletions(-)
crypto/asymmetric_keys/x509_public_key.c +83 -1
@@ -18,12 +18,60 @@#include <linux/asn1_decoder.h> #include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> +#include <keys/system_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" /* +* Find a key in the given keyring by issuer and authority. +*/ +static struct key *x509_request_asymmetric_key ( +struct key *keyring, +const char *signer,size_t signer_len, +const char *authority,size_t auth_len) +{ +key_ref_t key; +char *id; + +/* Construct an identifier. */ + id =kmalloc (signer_len +2 + auth_len +1 ,GFP_KERNEL ); +if (!id) +return ERR_PTR (-ENOMEM ); + +memcpy (id, signer, signer_len); + id[signer_len +0 ] =':' ; + id[signer_len +1 ] =' ' ; +memcpy (id + signer_len +2 , authority, auth_len); + id[signer_len +2 + auth_len] =0 ; + +pr_debug ("Look up: \"%s\"\n" , id); + + key =keyring_search (make_key_ref (keyring,1 ), + &key_type_asymmetric, id); +if (IS_ERR (key)) +pr_debug ("Request for module key '%s' err %ld\n" , + id,PTR_ERR (key)); +kfree (id); + +if (IS_ERR (key)) { +switch (PTR_ERR (key)) { +/* Hide some search errors */ +case -EACCES : +case -ENOTDIR : +case -EAGAIN : +return ERR_PTR (-ENOKEY ); +default : +return ERR_CAST (key); + } + } + +pr_devel ("<==%s() = 0 [%x]\n" , __func__,key_serial (key_ref_to_ptr (key))); +return key_ref_to_ptr (key); +} + +/* * Set up the signature parameters in an X.509 certificate. This involves * digesting the signed data and extracting the signature. */
@@ -103,6 +151,36 @@ int x509_check_signature(const struct public_key *pub,EXPORT_SYMBOL_GPL (x509_check_signature);/* +* Check the new certificate against the ones in the trust keyring. If one of +* those is the signing key and validates the new certificate, then mark the +* new certificate as being trusted. +* +* Return 0 if the new certificate was successfully validated, 1 if we couldn't +* find a matching parent certificate in the trusted list and an error if there +* is a matching certificate but the signature check fails. +*/ +static int x509_validate_trust (struct x509_certificate *cert, +struct key *trust_keyring) +{ +const struct public_key *pk; +struct key *key; +int ret =1 ; + +if (!trust_keyring) +return -EOPNOTSUPP ; + + key =x509_request_asymmetric_key (trust_keyring, + cert->issuer,strlen (cert->issuer), + cert->authority, +strlen (cert->authority)); +if (!IS_ERR (key)) { + pk = key->payload.data; + ret =x509_check_signature (pk, cert); + } +return ret; +} + +/* * Attempt to parse a data blob for a key as an X509 certificate. */ static int x509_key_preparse (struct key_preparsed_payload *prep)
@@ -155,9 +233,13 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)/* Check the signature on the key if it appears to be self-signed */ if (!cert->authority ||strcmp (cert->fingerprint, cert->authority) ==0 ) { - ret =x509_check_signature (cert->pub, cert); + ret =x509_check_signature (cert->pub, cert);/* self-signed */ if (ret <0 ) goto error_free_cert; + }else { + ret =x509_validate_trust (cert,get_system_trusted_keyring ()); +if (!ret) + prep->trusted =1 ; }/* Propose a description */
include/keys/system_keyring.h +9 -1
@@ -17,7 +17,15 @@#include <linux/key.h> extern struct key *system_trusted_keyring; - +static inline struct key *get_system_trusted_keyring (void ) +{ +return system_trusted_keyring; +} +#else +static inline struct key *get_system_trusted_keyring (void ) +{ +return NULL ; +}#endif #endif /* _KEYS_SYSTEM_KEYRING_H */
Signature · 1 line
1.8.1.4
Re: [RFC PATCH v5 2/4] KEYS: verify a certificate is signed by a 'trusted' key
Quoted 5 lines · Mimi Zohar
Only public keys, with certificates signed by an existing 'trusted' key on the system trusted keyring, should be added to a trusted keyring. This patch adds support for verifying a certificate's signature.
Quoted 7 lines
This is derived from David Howells
pkcs7_request_asymmetric_key()patch.Changelog:
- defineget_system_trusted_keyring()to fix kbuild issuesSigned-off-by Mimi Zohar <[email protected]>Signed-off-by David Howells <[email protected]>
Quoted 150 lines
--- crypto/asymmetric_keys/x509_public_key.c | 84 +++++++++++++++++++++++++++++++- include/keys/system_keyring.h | 10 +++- 2 files changed, 92 insertions(+), 2 deletions(-)crypto/asymmetric_keys/x509_public_key.c +83
-1@@ -18,12 +18,60 @@#include <linux/asn1_decoder.h> #include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> +#include <keys/system_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" /* +* Find a key in the given keyring by issuer and authority. +*/ +static struct key *x509_request_asymmetric_key ( +struct key *keyring, +const char *signer,size_t signer_len, +const char *authority,size_t auth_len) +{ +key_ref_t key; +char *id; + +/* Construct an identifier. */ + id =kmalloc (signer_len +2 + auth_len +1 ,GFP_KERNEL ); +if (!id) +return ERR_PTR (-ENOMEM ); + +memcpy (id, signer, signer_len); + id[signer_len +0 ] =':' ; + id[signer_len +1 ] =' ' ; +memcpy (id + signer_len +2 , authority, auth_len); + id[signer_len +2 + auth_len] =0 ; + +pr_debug ("Look up: \"%s\"\n" , id); + + key =keyring_search (make_key_ref (keyring,1 ), + &key_type_asymmetric, id); +if (IS_ERR (key)) +pr_debug ("Request for module key '%s' err %ld\n" , + id,PTR_ERR (key)); +kfree (id); + +if (IS_ERR (key)) { +switch (PTR_ERR (key)) { +/* Hide some search errors */ +case -EACCES : +case -ENOTDIR : +case -EAGAIN : +return ERR_PTR (-ENOKEY ); +default : +return ERR_CAST (key); + } + } + +pr_devel ("<==%s() = 0 [%x]\n" , __func__,key_serial (key_ref_to_ptr (key))); +return key_ref_to_ptr (key); +} + +/* * Set up the signature parameters in an X.509 certificate. This involves * digesting the signed data and extracting the signature. */ @@ -103,6 +151,36 @@ int x509_check_signature(const struct public_key *pub,EXPORT_SYMBOL_GPL (x509_check_signature);/* +* Check the new certificate against the ones in the trust keyring. If one of +* those is the signing key and validates the new certificate, then mark the +* new certificate as being trusted. +* +* Return 0 if the new certificate was successfully validated, 1 if we couldn't +* find a matching parent certificate in the trusted list and an error if there +* is a matching certificate but the signature check fails. +*/ +static int x509_validate_trust (struct x509_certificate *cert, +struct key *trust_keyring) +{ +const struct public_key *pk; +struct key *key; +int ret =1 ; + +if (!trust_keyring) +return -EOPNOTSUPP ; + + key =x509_request_asymmetric_key (trust_keyring, + cert->issuer,strlen (cert->issuer), + cert->authority, +strlen (cert->authority)); +if (!IS_ERR (key)) { + pk = key->payload.data; + ret =x509_check_signature (pk, cert); + } +return ret; +} + +/* * Attempt to parse a data blob for a key as an X509 certificate. */ static int x509_key_preparse (struct key_preparsed_payload *prep)@@ -155,9 +233,13 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)/* Check the signature on the key if it appears to be self-signed */ if (!cert->authority ||strcmp (cert->fingerprint, cert->authority) ==0 ) { - ret =x509_check_signature (cert->pub, cert); + ret =x509_check_signature (cert->pub, cert);/* self-signed */ if (ret <0 ) goto error_free_cert; + }else { + ret =x509_validate_trust (cert,get_system_trusted_keyring ()); +if (!ret) + prep->trusted =1 ; }/* Propose a description */ include/keys/system_keyring.h +9
-2@@ -17,7 +17,15 @@#include <linux/key.h> extern struct key *system_trusted_keyring; - +static inline struct key *get_system_trusted_keyring (void ) +{ +return system_trusted_keyring; +} +#else +static inline struct key *get_system_trusted_keyring (void ) +{ +return NULL ; +}#endif #endif /* _KEYS_SYSTEM_KEYRING_H */ --1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Thanks, Dmitry
Re: [RFC PATCH v5 2/4] KEYS: verify a certificate is signed by a 'trusted' key
Quoted 127 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Only public keys, with certificates signed by an existing 'trusted' key on the system trusted keyring, should be added to a trusted keyring. This patch adds support for verifying a certificate's signature.
Quoted 7 lines
This is derived from David Howells
pkcs7_request_asymmetric_key()patch.Changelog:
- defineget_system_trusted_keyring()to fix kbuild issuesSigned-off-by Mimi Zohar <[email protected]>Signed-off-by David Howells <[email protected]>Acked-by meQuoted 111 lines
--- crypto/asymmetric_keys/x509_public_key.c | 84 +++++++++++++++++++++++++++++++- include/keys/system_keyring.h | 10 +++- 2 files changed, 92 insertions(+), 2 deletions(-)crypto/asymmetric_keys/x509_public_key.c +78
-0@@ -18,12 +18,60 @@#include <linux/asn1_decoder.h> #include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> +#include <keys/system_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" /* +* Find a key in the given keyring by issuer and authority. +*/ +static struct key *x509_request_asymmetric_key ( +struct key *keyring, +const char *signer,size_t signer_len, +const char *authority,size_t auth_len) +{ +key_ref_t key; +char *id; + +/* Construct an identifier. */ + id =kmalloc (signer_len +2 + auth_len +1 ,GFP_KERNEL ); +if (!id) +return ERR_PTR (-ENOMEM ); + +memcpy (id, signer, signer_len); + id[signer_len +0 ] =':' ; + id[signer_len +1 ] =' ' ; +memcpy (id + signer_len +2 , authority, auth_len); + id[signer_len +2 + auth_len] =0 ; + +pr_debug ("Look up: \"%s\"\n" , id); + + key =keyring_search (make_key_ref (keyring,1 ), + &key_type_asymmetric, id); +if (IS_ERR (key)) +pr_debug ("Request for module key '%s' err %ld\n" , + id,PTR_ERR (key)); +kfree (id); + +if (IS_ERR (key)) { +switch (PTR_ERR (key)) { +/* Hide some search errors */ +case -EACCES : +case -ENOTDIR : +case -EAGAIN : +return ERR_PTR (-ENOKEY ); +default : +return ERR_CAST (key); + } + } + +pr_devel ("<==%s() = 0 [%x]\n" , __func__,key_serial (key_ref_to_ptr (key))); +return key_ref_to_ptr (key); +} + +/* * Set up the signature parameters in an X.509 certificate. This involves * digesting the signed data and extracting the signature. */ @@ -103,6 +151,36 @@ int x509_check_signature(const struct public_key *pub,EXPORT_SYMBOL_GPL (x509_check_signature);/* +* Check the new certificate against the ones in the trust keyring. If one of +* those is the signing key and validates the new certificate, then mark the +* new certificate as being trusted. +* +* Return 0 if the new certificate was successfully validated, 1 if we couldn't +* find a matching parent certificate in the trusted list and an error if there +* is a matching certificate but the signature check fails. +*/ +static int x509_validate_trust (struct x509_certificate *cert, +struct key *trust_keyring) +{ +const struct public_key *pk; +struct key *key; +int ret =1 ; + +if (!trust_keyring) +return -EOPNOTSUPP ; + + key =x509_request_asymmetric_key (trust_keyring, + cert->issuer,strlen (cert->issuer), + cert->authority, +strlen (cert->authority)); +if (!IS_ERR (key)) { + pk = key->payload.data; + ret =x509_check_signature (pk, cert); + } +return ret; +} + +/* * Attempt to parse a data blob for a key as an X509 certificate. */ static int x509_key_preparse (struct key_preparsed_payload *prep)@@ -155,9 +233,13 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)/* Check the signature on the key if it appears to be self-signed */ if (!cert->authority ||strcmp (cert->fingerprint, cert->authority) ==0 ) {
Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c static int x509_key_preparse(struct key_preparsed_payload *prep) · line 242
Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c +5
-1- ret =x509_check_signature (cert->pub, cert); + ret =x509_check_signature (cert->pub, cert);/* self-signed */ if (ret <0 ) goto error_free_cert; + }else { + ret =x509_validate_trust (cert,get_system_trusted_keyring ()); +if (!ret) + prep->trusted =1 ;
Actually this can be like this
Quoted 2 lines
crypto/asymmetric_keys/x509_public_key.c static int x509_key_preparse(struct key_preparsed_payload *prep) · line 244
Quoted 2 lines
crypto/asymmetric_keys/x509_public_key.c +2
-0+ }else if (!prep->trusted) + ret = x509_validate_trust(cert,
get_system_trusted_keyring());
Quoted 36 lines
Quoted 34 lines
crypto/asymmetric_keys/x509_public_key.c +2
-0+if (!ret) + prep->trusted =1 ; }/* Propose a description */ include/keys/system_keyring.h +9
-2@@ -17,7 +17,15 @@#include <linux/key.h> extern struct key *system_trusted_keyring; - +static inline struct key *get_system_trusted_keyring (void ) +{ +return system_trusted_keyring; +} +#else +static inline struct key *get_system_trusted_keyring (void ) +{ +return NULL ; +}#endif #endif /* _KEYS_SYSTEM_KEYRING_H */ --1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v5 2/4] KEYS: verify a certificate is signed by a 'trusted' key
Quoted 139 lines · Dmitry Kasatkin
Quoted 127 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Only public keys, with certificates signed by an existing 'trusted' key on the system trusted keyring, should be added to a trusted keyring. This patch adds support for verifying a certificate's signature.
Quoted 7 lines
This is derived from David Howells
pkcs7_request_asymmetric_key()patch.Changelog:
- defineget_system_trusted_keyring()to fix kbuild issuesSigned-off-by Mimi Zohar <[email protected]>Signed-off-by David Howells <[email protected]>Acked-by meQuoted 111 lines
--- crypto/asymmetric_keys/x509_public_key.c | 84 +++++++++++++++++++++++++++++++- include/keys/system_keyring.h | 10 +++- 2 files changed, 92 insertions(+), 2 deletions(-)crypto/asymmetric_keys/x509_public_key.c +78
-0@@ -18,12 +18,60 @@#include <linux/asn1_decoder.h> #include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> +#include <keys/system_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" /* +* Find a key in the given keyring by issuer and authority. +*/ +static struct key *x509_request_asymmetric_key ( +struct key *keyring, +const char *signer,size_t signer_len, +const char *authority,size_t auth_len) +{ +key_ref_t key; +char *id; + +/* Construct an identifier. */ + id =kmalloc (signer_len +2 + auth_len +1 ,GFP_KERNEL ); +if (!id) +return ERR_PTR (-ENOMEM ); + +memcpy (id, signer, signer_len); + id[signer_len +0 ] =':' ; + id[signer_len +1 ] =' ' ; +memcpy (id + signer_len +2 , authority, auth_len); + id[signer_len +2 + auth_len] =0 ; + +pr_debug ("Look up: \"%s\"\n" , id); + + key =keyring_search (make_key_ref (keyring,1 ), + &key_type_asymmetric, id); +if (IS_ERR (key)) +pr_debug ("Request for module key '%s' err %ld\n" , + id,PTR_ERR (key)); +kfree (id); + +if (IS_ERR (key)) { +switch (PTR_ERR (key)) { +/* Hide some search errors */ +case -EACCES : +case -ENOTDIR : +case -EAGAIN : +return ERR_PTR (-ENOKEY ); +default : +return ERR_CAST (key); + } + } + +pr_devel ("<==%s() = 0 [%x]\n" , __func__,key_serial (key_ref_to_ptr (key))); +return key_ref_to_ptr (key); +} + +/* * Set up the signature parameters in an X.509 certificate. This involves * digesting the signed data and extracting the signature. */ @@ -103,6 +151,36 @@ int x509_check_signature(const struct public_key *pub,EXPORT_SYMBOL_GPL (x509_check_signature);/* +* Check the new certificate against the ones in the trust keyring. If one of +* those is the signing key and validates the new certificate, then mark the +* new certificate as being trusted. +* +* Return 0 if the new certificate was successfully validated, 1 if we couldn't +* find a matching parent certificate in the trusted list and an error if there +* is a matching certificate but the signature check fails. +*/ +static int x509_validate_trust (struct x509_certificate *cert, +struct key *trust_keyring) +{ +const struct public_key *pk; +struct key *key; +int ret =1 ; + +if (!trust_keyring) +return -EOPNOTSUPP ; + + key =x509_request_asymmetric_key (trust_keyring, + cert->issuer,strlen (cert->issuer), + cert->authority, +strlen (cert->authority)); +if (!IS_ERR (key)) { + pk = key->payload.data; + ret =x509_check_signature (pk, cert); + } +return ret; +} + +/* * Attempt to parse a data blob for a key as an X509 certificate. */ static int x509_key_preparse (struct key_preparsed_payload *prep)@@ -155,9 +233,13 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)/* Check the signature on the key if it appears to be self-signed */ if (!cert->authority ||strcmp (cert->fingerprint, cert->authority) ==0 ) {Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c static int x509_key_preparse(struct key_preparsed_payload *prep) · line 242
Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c +5
-1- ret =x509_check_signature (cert->pub, cert); + ret =x509_check_signature (cert->pub, cert);/* self-signed */ if (ret <0 ) goto error_free_cert; + }else { + ret =x509_validate_trust (cert,get_system_trusted_keyring ()); +if (!ret) + prep->trusted =1 ;Actually this can be like this
Quoted 7 lines
Quoted 2 lines
crypto/asymmetric_keys/x509_public_key.c static int x509_key_preparse(struct key_preparsed_payload *prep) · line 244
Quoted 2 lines
crypto/asymmetric_keys/x509_public_key.c +2
-0+ }else if (!prep->trusted) + ret = x509_validate_trust(cert,
get_system_trusted_keyring());Quoted 4 lines
Quoted 4 lines
crypto/asymmetric_keys/x509_public_key.c +2
-0+if (!ret) + prep->trusted =1 ; }
Fine
Mimi
Quoted 37 lines
Quoted 21 lines
Quoted 21 lines
/* Propose a description */include/keys/system_keyring.h +9
-1@@ -17,7 +17,15 @@#include <linux/key.h> extern struct key *system_trusted_keyring; - +static inline struct key *get_system_trusted_keyring (void ) +{ +return system_trusted_keyring; +} +#else +static inline struct key *get_system_trusted_keyring (void ) +{ +return NULL ; +}#endif Quoted 10 lines
Quoted 8 lines
include/keys/system_keyring.h +0
-1#endif /* _KEYS_SYSTEM_KEYRING_H */ --1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v5 2/4] KEYS: verify a certificate is signed by a 'trusted' key
Quoted 109 lines · Mimi Zohar
Quoted 108 lines · Dmitry Kasatkin
Quoted 107 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Only public keys, with certificates signed by an existing 'trusted' key on the system trusted keyring, should be added to a trusted keyring. This patch adds support for verifying a certificate's signature.
Quoted 7 lines
This is derived from David Howells
pkcs7_request_asymmetric_key()patch.Changelog:
- defineget_system_trusted_keyring()to fix kbuild issuesSigned-off-by Mimi Zohar <[email protected]>Signed-off-by David Howells <[email protected]>Acked-by meQuoted 91 lines
--- crypto/asymmetric_keys/x509_public_key.c | 84 +++++++++++++++++++++++++++++++- include/keys/system_keyring.h | 10 +++- 2 files changed, 92 insertions(+), 2 deletions(-)crypto/asymmetric_keys/x509_public_key.c +65
-0@@ -18,12 +18,60 @@#include <linux/asn1_decoder.h> #include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> +#include <keys/system_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" /* +* Find a key in the given keyring by issuer and authority. +*/ +static struct key *x509_request_asymmetric_key ( +struct key *keyring, +const char *signer,size_t signer_len, +const char *authority,size_t auth_len) +{ +key_ref_t key; +char *id; + +/* Construct an identifier. */ + id =kmalloc (signer_len +2 + auth_len +1 ,GFP_KERNEL ); +if (!id) +return ERR_PTR (-ENOMEM ); + +memcpy (id, signer, signer_len); + id[signer_len +0 ] =':' ; + id[signer_len +1 ] =' ' ; +memcpy (id + signer_len +2 , authority, auth_len); + id[signer_len +2 + auth_len] =0 ; + +pr_debug ("Look up: \"%s\"\n" , id); + + key =keyring_search (make_key_ref (keyring,1 ), + &key_type_asymmetric, id); +if (IS_ERR (key)) +pr_debug ("Request for module key '%s' err %ld\n" , + id,PTR_ERR (key)); +kfree (id); + +if (IS_ERR (key)) { +switch (PTR_ERR (key)) { +/* Hide some search errors */ +case -EACCES : +case -ENOTDIR : +case -EAGAIN : +return ERR_PTR (-ENOKEY ); +default : +return ERR_CAST (key); + } + } + +pr_devel ("<==%s() = 0 [%x]\n" , __func__,key_serial (key_ref_to_ptr (key))); +return key_ref_to_ptr (key); +} + +/* * Set up the signature parameters in an X.509 certificate. This involves * digesting the signed data and extracting the signature. */ @@ -103,6 +151,36 @@ int x509_check_signature(const struct public_key *pub,EXPORT_SYMBOL_GPL (x509_check_signature);/* +* Check the new certificate against the ones in the trust keyring. If one of +* those is the signing key and validates the new certificate, then mark the +* new certificate as being trusted. +* +* Return 0 if the new certificate was successfully validated, 1 if we couldn't +* find a matching parent certificate in the trusted list and an error if there +* is a matching certificate but the signature check fails. +*/ +static int x509_validate_trust (struct x509_certificate *cert, +struct key *trust_keyring) +{ +const struct public_key *pk; +struct key *key; +int ret =1 ; + +if (!trust_keyring) +return -EOPNOTSUPP ;
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c int x509_check_signature(const struct public_key *pub, · line 178
Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c +8
-0+ + key =x509_request_asymmetric_key (trust_keyring, + cert->issuer,strlen (cert->issuer), + cert->authority, +strlen (cert->authority)); +if (!IS_ERR (key)) { + pk = key->payload.data; + ret =x509_check_signature (pk, cert);
I suspect that key_put(key) is missing here...
Quoted 73 lines
Quoted 22 lines
Quoted 12 lines
Quoted 12 lines
crypto/asymmetric_keys/x509_public_key.c +5
-0+ } +return ret; +} + +/* * Attempt to parse a data blob for a key as an X509 certificate. */ static int x509_key_preparse (struct key_preparsed_payload *prep)@@ -155,9 +233,13 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)/* Check the signature on the key if it appears to be self-signed */ if (!cert->authority ||strcmp (cert->fingerprint, cert->authority) ==0 ) {Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c static int x509_key_preparse(struct key_preparsed_payload *prep) · line 242
Quoted 8 lines
crypto/asymmetric_keys/x509_public_key.c +5
-1- ret =x509_check_signature (cert->pub, cert); + ret =x509_check_signature (cert->pub, cert);/* self-signed */ if (ret <0 ) goto error_free_cert; + }else { + ret =x509_validate_trust (cert,get_system_trusted_keyring ()); +if (!ret) + prep->trusted =1 ;Actually this can be like this
Quoted 6 lines
Quoted 2 lines
crypto/asymmetric_keys/x509_public_key.c static int x509_key_preparse(struct key_preparsed_payload *prep) · line 244
Quoted 2 lines
crypto/asymmetric_keys/x509_public_key.c +2
-0+ }else if (!prep->trusted) + ret = x509_validate_trust(cert,
get_system_trusted_keyring());Quoted 3 lines
Quoted 3 lines
crypto/asymmetric_keys/x509_public_key.c +2
-0+if (!ret) + prep->trusted =1 ; }Fine
Mimi
Quoted 30 lines
Quoted 21 lines
Quoted 21 lines
/* Propose a description */include/keys/system_keyring.h +9
-1@@ -17,7 +17,15 @@#include <linux/key.h> extern struct key *system_trusted_keyring; - +static inline struct key *get_system_trusted_keyring (void ) +{ +return system_trusted_keyring; +} +#else +static inline struct key *get_system_trusted_keyring (void ) +{ +return NULL ; +}#endif Quoted 9 lines
Quoted 8 lines
include/keys/system_keyring.h +0
-1#endif /* _KEYS_SYSTEM_KEYRING_H */ --1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.htmlQuoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC PATCH v5 3/4 ima: define '.ima' as a builtin 'trusted' keyring
In reply to Mimi ZoharRequire all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring.
Changelog v5:
- Move integrity_init_keyring() to init_ima() - Dmitry
- reset keyring[id] on failure - Dmitry
Changelog v1:
- don't link IMA trusted keyring to user keyring
Changelog:
- define stub integrity_init_keyring() function (reported-by Fengguang Wu)
- differentiate between regular and trusted keyring names.
- replace printk with pr_info (D. Kasatkin)
- only make the IMA keyring a trusted keyring (reported-by D. Kastatkin)
- define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis)
--- security/integrity/digsig.c | 26 ++++++++++++++++++++++++++ security/integrity/ima/Kconfig | 8 ++++++++ security/integrity/ima/ima_main.c | 12 ++++++++++-- security/integrity/integrity.h | 5 +++++ 4 files changed, 49 insertions(+), 2 deletions(-)
security/integrity/digsig.c +26 -0
@@ -13,7 +13,9 @@#define pr_fmt (fmt) KBUILD_MODNAME ": " fmt#include <linux/err.h> +#include <linux/sched.h> #include <linux/rbtree.h> +#include <linux/cred.h> #include <linux/key-type.h> #include <linux/digsig.h>
@@ -24,7 +26,11 @@ static struct key *keyring[INTEGRITY_KEYRING_MAX];static const char *keyring_name[INTEGRITY_KEYRING_MAX ] = {"_evm" ,"_module" , +#ifndef CONFIG_IMA_TRUSTED_KEYRING"_ima" , +#else +".ima" , +#endif }; int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
@@ -56,3 +62,23 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,return -EOPNOTSUPP ; } + +int integrity_init_keyring (const unsigned int id) +{ +const struct cred *cred =current_cred (); + + keyring[id] =keyring_alloc (keyring_name[id],KUIDT_INIT (0 ), +KGIDT_INIT (0 ), cred, + ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | +KEY_USR_VIEW |KEY_USR_READ | +KEY_USR_WRITE |KEY_USR_SEARCH ), +KEY_ALLOC_NOT_IN_QUOTA ,NULL ); +if (!IS_ERR (keyring[id])) +set_bit (KEY_FLAG_TRUSTED_ONLY , &keyring[id]->flags); +else { +pr_info ("Can't allocate %s keyring (%ld)\n" , + keyring_name[id],PTR_ERR (keyring[id])); + keyring[id] =NULL ; + } +return 0 ; +}
security/integrity/ima/Kconfig +8 -0
@@ -123,3 +123,11 @@ config IMA_APPRAISE For more information on integrity appraisal refer to: <http://linux-ima.sourceforge.net> If unsure, say N. + +config IMA_TRUSTED_KEYRING + bool "Require all keys on the _ima keyring be signed" + depends on IMA_APPRAISE && SYSTEM_TRUSTED_KEYRING + default y + help + This option requires that all keys added to the _ima + keyring be signed by a key on the system trusted keyring.
security/integrity/ima/ima_main.c +10 -2
@@ -328,8 +328,16 @@ static int __init init_ima(void)hash_setup (CONFIG_IMA_DEFAULT_HASH ); error =ima_init (); -if (!error) - ima_initialized =1 ; +if (error) + goto out; + +#ifdef CONFIG_IMA_TRUSTED_KEYRING + error =integrity_init_keyring (INTEGRITY_KEYRING_IMA ); +if (error) + goto out; +#endif + ima_initialized =1 ; +out:return error; }
security/integrity/integrity.h +5 -0
@@ -124,6 +124,7 @@ struct integrity_iint_cache *integrity_iint_find(struct inode *inode);int integrity_digsig_verify (const unsigned int id,const char *sig,int siglen,const char *digest,int digestlen); +int integrity_init_keyring (const unsigned int id);#else static inline int integrity_digsig_verify(const unsigned int id,
@@ -133,6 +134,10 @@ static inline int integrity_digsig_verify(const unsigned int id, return -EOPNOTSUPP; } +static inline int integrity_init_keyring (const unsigned int id) +{ +return 0 ; +}#endif /* CONFIG_INTEGRITY_SIGNATURE */ #ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS
Signature · 1 line
1.8.1.4
Dmitry Kasatkin
maintainerRe: [RFC PATCH v5 3/4] ima: define '.ima' as a builtin 'trusted' keyring
Quoted 101 lines · Mimi Zohar
Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring.
Changelog v5:
- Moveintegrity_init_keyring()toinit_ima()- Dmitry
- reset keyring[id] on failure - DmitryChangelog v1:
- don't link IMA trusted keyring to user keyringChangelog:
- define stubintegrity_init_keyring()function (reported-by Fengguang Wu)
- differentiate between regular and trusted keyring names.
- replace printk withpr_info(D. Kasatkin)
- only make the IMA keyring a trusted keyring (reported-by D. Kastatkin)
- define stubintegrity_init_keyring()definition based onCONFIG_INTEGRITY_SIGNATURE, notCONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis)Signed-off-by Mimi Zohar<[email protected]>--- security/integrity/digsig.c | 26 ++++++++++++++++++++++++++ security/integrity/ima/Kconfig | 8 ++++++++ security/integrity/ima/ima_main.c | 12 ++++++++++-- security/integrity/integrity.h | 5 +++++ 4 files changed, 49 insertions(+), 2 deletions(-)security/integrity/digsig.c +26
-0@@ -13,7 +13,9 @@#define pr_fmt (fmt) KBUILD_MODNAME ": " fmt#include <linux/err.h> +#include <linux/sched.h> #include <linux/rbtree.h> +#include <linux/cred.h> #include <linux/key-type.h> #include <linux/digsig.h> @@ -24,7 +26,11 @@ static struct key *keyring[INTEGRITY_KEYRING_MAX];static const char *keyring_name[INTEGRITY_KEYRING_MAX ] = {"_evm" ,"_module" , +#ifndef CONFIG_IMA_TRUSTED_KEYRING"_ima" , +#else +".ima" , +#endif }; int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,@@ -56,3 +62,23 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,return -EOPNOTSUPP ; } + +int integrity_init_keyring (const unsigned int id) +{ +const struct cred *cred =current_cred (); + + keyring[id] =keyring_alloc (keyring_name[id],KUIDT_INIT (0 ), +KGIDT_INIT (0 ), cred, + ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | +KEY_USR_VIEW |KEY_USR_READ | +KEY_USR_WRITE |KEY_USR_SEARCH ), +KEY_ALLOC_NOT_IN_QUOTA ,NULL ); +if (!IS_ERR (keyring[id])) +set_bit (KEY_FLAG_TRUSTED_ONLY , &keyring[id]->flags); +else { +pr_info ("Can't allocate %s keyring (%ld)\n" , + keyring_name[id],PTR_ERR (keyring[id])); + keyring[id] =NULL ; + } +return 0 ; +}security/integrity/ima/Kconfig +8
-0@@ -123,3 +123,11 @@ config IMA_APPRAISE For more information on integrity appraisal refer to: <http://linux-ima.sourceforge.net> If unsure, say N. + +config IMA_TRUSTED_KEYRING + bool "Require all keys on the _ima keyring be signed" + depends on IMA_APPRAISE && SYSTEM_TRUSTED_KEYRING + default y + help + This option requires that all keys added to the _ima + keyring be signed by a key on the system trusted keyring.security/integrity/ima/ima_main.c +0
-0@@ -328,8 +328,16 @@ static int __init init_ima(void)hash_setup (CONFIG_IMA_DEFAULT_HASH ); error =ima_init ();
security/integrity/ima/ima_main.c static int __init init_ima(void) · line 338
Quoted 10 lines
security/integrity/ima/ima_main.c +8
-2-if (!error) - ima_initialized =1 ; +if (error) + goto out; + +#ifdef CONFIG_IMA_TRUSTED_KEYRING + error =integrity_init_keyring (INTEGRITY_KEYRING_IMA ); +if (error) + goto out; +#endif
integrity_init_keyring() has variation in header file... Why do you need #ifdef in .c file? You you usually do not like it...
- Dmitry
Quoted 35 lines
security/integrity/ima/ima_main.c +2
-0+ ima_initialized =1 ; +out:return error; }security/integrity/integrity.h +5
-1@@ -124,6 +124,7 @@ struct integrity_iint_cache *integrity_iint_find(struct inode *inode);int integrity_digsig_verify (const unsigned int id,const char *sig,int siglen,const char *digest,int digestlen); +int integrity_init_keyring (const unsigned int id);#else static inline int integrity_digsig_verify(const unsigned int id,@@ -133,6 +134,10 @@ static inline int integrity_digsig_verify(const unsigned int id, return -EOPNOTSUPP; } +static inline int integrity_init_keyring (const unsigned int id) +{ +return 0 ; +}#endif /* CONFIG_INTEGRITY_SIGNATURE */ #ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS --1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Thanks, Dmitry
Re: [RFC PATCH v5 3/4] ima: define '.ima' as a builtin 'trusted' keyring
Quoted 100 lines · Dmitry Kasatkin
Quoted 99 lines · Mimi Zohar
Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring.
Changelog v5:
- Moveintegrity_init_keyring()toinit_ima()- Dmitry
- reset keyring[id] on failure - DmitryChangelog v1:
- don't link IMA trusted keyring to user keyringChangelog:
- define stubintegrity_init_keyring()function (reported-by Fengguang Wu)
- differentiate between regular and trusted keyring names.
- replace printk withpr_info(D. Kasatkin)
- only make the IMA keyring a trusted keyring (reported-by D. Kastatkin)
- define stubintegrity_init_keyring()definition based onCONFIG_INTEGRITY_SIGNATURE, notCONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis)Signed-off-by Mimi Zohar<[email protected]>--- security/integrity/digsig.c | 26 ++++++++++++++++++++++++++ security/integrity/ima/Kconfig | 8 ++++++++ security/integrity/ima/ima_main.c | 12 ++++++++++-- security/integrity/integrity.h | 5 +++++ 4 files changed, 49 insertions(+), 2 deletions(-)security/integrity/digsig.c +26
-0@@ -13,7 +13,9 @@#define pr_fmt (fmt) KBUILD_MODNAME ": " fmt#include <linux/err.h> +#include <linux/sched.h> #include <linux/rbtree.h> +#include <linux/cred.h> #include <linux/key-type.h> #include <linux/digsig.h> @@ -24,7 +26,11 @@ static struct key *keyring[INTEGRITY_KEYRING_MAX];static const char *keyring_name[INTEGRITY_KEYRING_MAX ] = {"_evm" ,"_module" , +#ifndef CONFIG_IMA_TRUSTED_KEYRING"_ima" , +#else +".ima" , +#endif }; int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,@@ -56,3 +62,23 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,return -EOPNOTSUPP ; } + +int integrity_init_keyring (const unsigned int id) +{ +const struct cred *cred =current_cred (); + + keyring[id] =keyring_alloc (keyring_name[id],KUIDT_INIT (0 ), +KGIDT_INIT (0 ), cred, + ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | +KEY_USR_VIEW |KEY_USR_READ | +KEY_USR_WRITE |KEY_USR_SEARCH ), +KEY_ALLOC_NOT_IN_QUOTA ,NULL ); +if (!IS_ERR (keyring[id])) +set_bit (KEY_FLAG_TRUSTED_ONLY , &keyring[id]->flags); +else { +pr_info ("Can't allocate %s keyring (%ld)\n" , + keyring_name[id],PTR_ERR (keyring[id])); + keyring[id] =NULL ; + } +return 0 ; +}security/integrity/ima/Kconfig +8
-0@@ -123,3 +123,11 @@ config IMA_APPRAISE For more information on integrity appraisal refer to: <http://linux-ima.sourceforge.net> If unsure, say N. + +config IMA_TRUSTED_KEYRING + bool "Require all keys on the _ima keyring be signed" + depends on IMA_APPRAISE && SYSTEM_TRUSTED_KEYRING + default y + help + This option requires that all keys added to the _ima + keyring be signed by a key on the system trusted keyring.security/integrity/ima/ima_main.c +0
-0@@ -328,8 +328,16 @@ static int __init init_ima(void)
Quoted 15 lines
security/integrity/ima/ima_main.c static int __init init_ima(void) · line 338
Quoted 12 lines
security/integrity/ima/ima_main.c +8
-2hash_setup (CONFIG_IMA_DEFAULT_HASH ); error =ima_init (); -if (!error) - ima_initialized =1 ; +if (error) + goto out; + +#ifdef CONFIG_IMA_TRUSTED_KEYRING + error =integrity_init_keyring (INTEGRITY_KEYRING_IMA ); +if (error) + goto out; +#endif
integrity_init_keyring()has variation in header file... Why do you need #ifdef in .c file? You you usually do not like it...
Up to now, unsigned certificates could be added to the IMA keyring. We can not all of a sudden require all keys being added to the IMA keyring to be signed. Although there is a stub integrity_init_keyring() function definition, it is based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_IMA_TRUSTED_KEYRING.
Right, ifdef's don't belong in C code. One solution would be to define ima_init_keyring() as a wrapper for integrity_init_keyring() and a stub function.
Mimi
Quoted 39 lines
Quoted 36 lines
security/integrity/ima/ima_main.c +2
-0+ ima_initialized =1 ; +out:return error; }security/integrity/integrity.h +5
-1@@ -124,6 +124,7 @@ struct integrity_iint_cache *integrity_iint_find(struct inode *inode);int integrity_digsig_verify (const unsigned int id,const char *sig,int siglen,const char *digest,int digestlen); +int integrity_init_keyring (const unsigned int id);#else static inline int integrity_digsig_verify(const unsigned int id,@@ -133,6 +134,10 @@ static inline int integrity_digsig_verify(const unsigned int id, return -EOPNOTSUPP; } +static inline int integrity_init_keyring (const unsigned int id) +{ +return 0 ; +}#endif /* CONFIG_INTEGRITY_SIGNATURE */ #ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS --1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v5 3/4] ima: define '.ima' as a builtin 'trusted' keyring
Quoted 121 lines · Mimi Zohar
Quoted 100 lines · Dmitry Kasatkin
Quoted 99 lines · Mimi Zohar
Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring.
Changelog v5:
- Moveintegrity_init_keyring()toinit_ima()- Dmitry
- reset keyring[id] on failure - DmitryChangelog v1:
- don't link IMA trusted keyring to user keyringChangelog:
- define stubintegrity_init_keyring()function (reported-by Fengguang Wu)
- differentiate between regular and trusted keyring names.
- replace printk withpr_info(D. Kasatkin)
- only make the IMA keyring a trusted keyring (reported-by D. Kastatkin)
- define stubintegrity_init_keyring()definition based onCONFIG_INTEGRITY_SIGNATURE, notCONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis)Signed-off-by Mimi Zohar<[email protected]>--- security/integrity/digsig.c | 26 ++++++++++++++++++++++++++ security/integrity/ima/Kconfig | 8 ++++++++ security/integrity/ima/ima_main.c | 12 ++++++++++-- security/integrity/integrity.h | 5 +++++ 4 files changed, 49 insertions(+), 2 deletions(-)security/integrity/digsig.c +26
-0@@ -13,7 +13,9 @@#define pr_fmt (fmt) KBUILD_MODNAME ": " fmt#include <linux/err.h> +#include <linux/sched.h> #include <linux/rbtree.h> +#include <linux/cred.h> #include <linux/key-type.h> #include <linux/digsig.h> @@ -24,7 +26,11 @@ static struct key *keyring[INTEGRITY_KEYRING_MAX];static const char *keyring_name[INTEGRITY_KEYRING_MAX ] = {"_evm" ,"_module" , +#ifndef CONFIG_IMA_TRUSTED_KEYRING"_ima" , +#else +".ima" , +#endif }; int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,@@ -56,3 +62,23 @@ int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,return -EOPNOTSUPP ; } + +int integrity_init_keyring (const unsigned int id) +{ +const struct cred *cred =current_cred (); + + keyring[id] =keyring_alloc (keyring_name[id],KUIDT_INIT (0 ), +KGIDT_INIT (0 ), cred, + ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | +KEY_USR_VIEW |KEY_USR_READ | +KEY_USR_WRITE |KEY_USR_SEARCH ), +KEY_ALLOC_NOT_IN_QUOTA ,NULL ); +if (!IS_ERR (keyring[id])) +set_bit (KEY_FLAG_TRUSTED_ONLY , &keyring[id]->flags); +else { +pr_info ("Can't allocate %s keyring (%ld)\n" , + keyring_name[id],PTR_ERR (keyring[id])); + keyring[id] =NULL ; + } +return 0 ; +}security/integrity/ima/Kconfig +8
-0@@ -123,3 +123,11 @@ config IMA_APPRAISE For more information on integrity appraisal refer to: <http://linux-ima.sourceforge.net> If unsure, say N. + +config IMA_TRUSTED_KEYRING + bool "Require all keys on the _ima keyring be signed" + depends on IMA_APPRAISE && SYSTEM_TRUSTED_KEYRING + default y + help + This option requires that all keys added to the _ima + keyring be signed by a key on the system trusted keyring.security/integrity/ima/ima_main.c +0
-0@@ -328,8 +328,16 @@ static int __init init_ima(void)Quoted 14 lines
security/integrity/ima/ima_main.c static int __init init_ima(void) · line 338
Quoted 12 lines
security/integrity/ima/ima_main.c +8
-2hash_setup (CONFIG_IMA_DEFAULT_HASH ); error =ima_init (); -if (!error) - ima_initialized =1 ; +if (error) + goto out; + +#ifdef CONFIG_IMA_TRUSTED_KEYRING + error =integrity_init_keyring (INTEGRITY_KEYRING_IMA ); +if (error) + goto out; +#endif
integrity_init_keyring()has variation in header file... Why do you need #ifdef in .c file? You you usually do not like it...Up to now, unsigned certificates could be added to the IMA keyring. We can not all of a sudden require all keys being added to the IMA keyring to be signed. Although there is a stub
integrity_init_keyring()function definition, it is based onCONFIG_INTEGRITY_SIGNATURE, notCONFIG_IMA_TRUSTED_KEYRING.
Quoted 5 lines
Right, ifdef's don't belong in C code. One solution would be to define
ima_init_keyring()as a wrapper forintegrity_init_keyring()and a stub function.Mimi
I think 'ima_init_keyring" could be a good approach.
Quoted 1 line
From other hand, if you look to
kernel/module.c, then you will find ~40
#ifdefs of the source code...
So it may be indeed clear from __init point of view what we initialize and what not...
- Dmitry
Quoted 43 lines
Quoted 27 lines
Quoted 27 lines
security/integrity/ima/ima_main.c +2
-0+ ima_initialized =1 ; +out:return error; }security/integrity/integrity.h +5
-0@@ -124,6 +124,7 @@ struct integrity_iint_cache *integrity_iint_find(struct inode *inode);int integrity_digsig_verify (const unsigned int id,const char *sig,int siglen,const char *digest,int digestlen); +int integrity_init_keyring (const unsigned int id);#else static inline int integrity_digsig_verify(const unsigned int id,@@ -133,6 +134,10 @@ static inline int integrity_digsig_verify(const unsigned int id, return -EOPNOTSUPP; } +static inline int integrity_init_keyring (const unsigned int id) +{ +return 0 ; +}#endif /* CONFIG_INTEGRITY_SIGNATURE */ Quoted 10 lines
Quoted 8 lines
security/integrity/integrity.h +0
-1#ifdef CONFIG_INTEGRITY_ASYMMETRIC_KEYS --1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC PATCH v5 4/4 KEYS: define an owner trusted keyring
In reply to Mimi ZoharInstead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function get_system_or_owner_trusted_keyring().
--- Documentation/kernel-parameters.txt | 5 ++ crypto/asymmetric_keys/x509_public_key.c | 4 +- include/keys/owner_keyring.h | 27 ++++++++++ init/Kconfig | 10 ++++ kernel/Makefile | 1 + kernel/owner_keyring.c | 85 ++++++++++++++++++++++++++++++++ 6 files changed, 131 insertions(+), 1 deletion(-) create mode 100644 include/keys/owner_keyring.h create mode 100644 kernel/owner_keyring.c
Documentation/kernel-parameters.txt +5 -0
@@ -1434,6 +1434,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. use the HighMem zone if it exists, and the Normal zone if it does not. + keys_ownerid=[KEYS] This parameter identifies a specific key on + the system trusted keyring to be added to the + owner trusted keyring. + format: id:<keyid> + kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port. Format: <Controller#>[,poll interval] The controller # is the number of the ehci usb debug
crypto/asymmetric_keys/x509_public_key.c +3 -1
@@ -19,6 +19,7 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> +#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h"
@@ -237,7 +238,8 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else { - ret =x509_validate_trust (cert,get_system_trusted_keyring ()); + ret =x509_validate_trust (cert, +get_system_or_owner_trusted_keyring ());if (!ret) prep->trusted =1 ; }
include/keys/owner_keyring.h new file +27 -0
@@ -0,0 +1,27 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#ifndef _KEYS_OWNER_KEYRING_H +#define _KEYS_OWNER_KEYRING_H + +#ifdef CONFIG_OWNER_TRUSTED_KEYRING + +#include <linux/key.h> + +extern struct key *owner_trusted_keyring; +extern struct key *get_system_or_owner_trusted_keyring (void ); + +#else +static inline struct key *get_system_or_owner_trusted_keyring (void ) +{ +return get_system_trusted_keyring (); +} + +#endif +#endif /* _KEYS_OWNER_KEYRING_H */
init/Kconfig +10 -0
@@ -1661,6 +1661,16 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. +config OWNER_TRUSTED_KEYRING + bool "Verify certificate signatures using a specific system key" + depends on SYSTEM_TRUSTED_KEYRING + help + Verify a certificate's signature, before adding the key to + a trusted keyring, using a specific key on the system trusted + keyring. The specific key on the system trusted keyring is + identified using the kernel boot command line option + "keys_ownerid" and is added to the owner_trusted_keyring. + menuconfig MODULES bool "Enable loadable module support" option modules
kernel/Makefile +1 -0
@@ -44,6 +44,7 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o +obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.o
kernel/owner_keyring.c new file +85 -0
85 lines not on this page · raw message
Signature · 1 line
1.8.1.4
Re: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
Quoted 5 lines · Mimi Zohar
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
Quoted 8 lines
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().
Hello,
The functionality of this entire patch can be replaced by only ~2 lines of code in x509_request_asymmetric_key()
if (keys_ownerid || strcmp(keys_ownerid, id))
return -EPERM;
Right?
- Dmitry
Quoted 207 lines
Signed-off-by Mimi Zohar<[email protected]>--- Documentation/kernel-parameters.txt | 5 ++ crypto/asymmetric_keys/x509_public_key.c | 4 +- include/keys/owner_keyring.h | 27 ++++++++++ init/Kconfig | 10 ++++ kernel/Makefile | 1 + kernel/owner_keyring.c | 85 ++++++++++++++++++++++++++++++++ 6 files changed, 131 insertions(+), 1 deletion(-) create mode 100644 include/keys/owner_keyring.h create mode 100644 kernel/owner_keyring.cDocumentation/kernel-parameters.txt +5
-0@@ -1434,6 +1434,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. use the HighMem zone if it exists, and the Normal zone if it does not. + keys_ownerid=[KEYS] This parameter identifies a specific key on + the system trusted keyring to be added to the + owner trusted keyring. + format: id:<keyid> + kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port. Format: <Controller#>[,poll interval] The controller # is the number of the ehci usb debugcrypto/asymmetric_keys/x509_public_key.c +3
-1@@ -19,6 +19,7 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> +#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" @@ -237,7 +238,8 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else { - ret =x509_validate_trust (cert,get_system_trusted_keyring ()); + ret =x509_validate_trust (cert, +get_system_or_owner_trusted_keyring ());if (!ret) prep->trusted =1 ; }include/keys/owner_keyring.h new file +27
-0@@ -0,0 +1,27 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#ifndef _KEYS_OWNER_KEYRING_H +#define _KEYS_OWNER_KEYRING_H + +#ifdef CONFIG_OWNER_TRUSTED_KEYRING + +#include <linux/key.h> + +extern struct key *owner_trusted_keyring; +extern struct key *get_system_or_owner_trusted_keyring (void ); + +#else +static inline struct key *get_system_or_owner_trusted_keyring (void ) +{ +return get_system_trusted_keyring (); +} + +#endif +#endif /* _KEYS_OWNER_KEYRING_H */ init/Kconfig +10
-0@@ -1661,6 +1661,16 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. +config OWNER_TRUSTED_KEYRING + bool "Verify certificate signatures using a specific system key" + depends on SYSTEM_TRUSTED_KEYRING + help + Verify a certificate's signature, before adding the key to + a trusted keyring, using a specific key on the system trusted + keyring. The specific key on the system trusted keyring is + identified using the kernel boot command line option + "keys_ownerid" and is added to the owner_trusted_keyring. + menuconfig MODULES bool "Enable loadable module support" option moduleskernel/Makefile +1
-0@@ -44,6 +44,7 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o +obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.okernel/owner_keyring.c new file +85
-0@@ -0,0 +1,85 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#include <linux/export.h> +#include <linux/kernel.h> +#include <linux/sched.h> +#include <linux/cred.h> +#include <linux/err.h> +#include <keys/asymmetric-type.h> +#include <keys/system_keyring.h> +#include "module-internal.h" + +struct key *owner_trusted_keyring; +static int use_owner_trusted_keyring; + +static char *owner_keyid; +static int __init default_owner_keyid_set (char *str) +{ +if (!str)/* default system keyring */ +return 1 ; + +if (strncmp (str,"id:" ,3 ) ==0 ) + owner_keyid = str;/* owner local key 'id:xxxxxx' */ + +return 1 ; +} + +__setup ("keys_ownerid=" , default_owner_keyid_set); + +struct key *get_system_or_owner_trusted_keyring (void ) +{ +return use_owner_trusted_keyring ? owner_trusted_keyring : +get_system_trusted_keyring (); +} + +static __init int owner_trusted_keyring_init (void ) +{ +pr_notice ("Initialize the owner trusted keyring\n" ); + + owner_trusted_keyring = +keyring_alloc (".owner_keyring" , +KUIDT_INIT (0 ),KGIDT_INIT (0 ),current_cred (), + ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | +KEY_USR_VIEW |KEY_USR_READ |KEY_USR_SEARCH ), +KEY_ALLOC_NOT_IN_QUOTA ,NULL ); +if (IS_ERR (owner_trusted_keyring)) +panic ("Can't allocate owner trusted keyring\n" ); + +set_bit (KEY_FLAG_TRUSTED_ONLY , &owner_trusted_keyring->flags); +return 0 ; +} + +device_initcall (owner_trusted_keyring_init); + +void load_owner_identified_key (void ) +{ +key_ref_t key_ref; +int ret; + +if (!owner_keyid) +return ; + + key_ref =keyring_search (make_key_ref (system_trusted_keyring,1 ), + &key_type_asymmetric, owner_keyid); +if (IS_ERR (key_ref)) { +pr_warn ("Request for unknown %s key\n" , owner_keyid); + goto out; + } + ret =key_link (owner_trusted_keyring,key_ref_to_ptr (key_ref)); +pr_info ("Loaded owner key %s %s\n" , owner_keyid, + ret <0 ?"failed" :"succeeded" ); +key_ref_put (key_ref); +if (!ret) + use_owner_trusted_keyring =1 ; +out: +return ; +} + +late_initcall (load_owner_identified_key);
Re: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
Quoted 17 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
Quoted 8 lines
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Hello,
Quoted 7 lines
The functionality of this entire patch can be replaced by only ~2 lines of code in
x509_request_asymmetric_key()if (
keys_ownerid||strcmp(keys_ownerid, id))return -EPERM;Right?
Are you suggesting only add the one matching key to the system keyring?
The original patch compared the builtin key being loaded onto the system keyring and, if it matched the requested key, also added the key to the owner keyring. This version waits for all the builtin keys to be loaded onto the system keyring, and in the future the UEFI DB keys, before adding the matched key to the owner keyring. In this version, the keys are already on the system keyring. So no, your two lines would not work.
Mimi
Re: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
Quoted 17 lines · Mimi Zohar
Quoted 16 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
Quoted 8 lines
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Hello,
Quoted 8 lines
Quoted 7 lines
The functionality of this entire patch can be replaced by only ~2 lines of code in
x509_request_asymmetric_key()if (
keys_ownerid||strcmp(keys_ownerid, id))return -EPERM;Right?
Are you suggesting only add the one matching key to the system keyring?
No. I am not suggesting this.
All built in keys are allocated with KEY_ALLOC_TRUSTED flag and prep.trusted is set to "true".
So the following statement has no effect.
#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
ret = x509_validate_trust(cert, system_trusted_keyring);
if (!ret)
prep->trusted = 1;#endif
Keys which come from user-space will check for
if (keys_ownerid && strcmp(keys_ownerid, id))
return -EPERM;
So 2 lines patch works fine..
- Dmitry
Quoted 21 lines
The original patch compared the builtin key being loaded onto the system keyring and, if it matched the requested key, also added the key to the owner keyring. This version waits for all the builtin keys to be loaded onto the system keyring, and in the future the UEFI DB keys, before adding the matched key to the owner keyring. In this version, the keys are already on the system keyring. So no, your two lines would not work.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
Quoted 25 lines · Dmitry Kasatkin
Quoted 24 lines · Mimi Zohar
Quoted 23 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
Quoted 8 lines
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Hello,
The functionality of this entire patch can be replaced by only ~2 lines of code in
x509_request_asymmetric_key()if (
keys_ownerid||strcmp(keys_ownerid, id))return -EPERM;Right?
Quoted 8 lines
Quoted 1 line
Are you suggesting only add the one matching key to the system keyring?
No. I am not suggesting this.
All built in keys are allocated with
KEY_ALLOC_TRUSTEDflag and prep.trusted is set to "true".So the following statement has no effect.
Ok, so it has no affect on adding builtin keys to the system keyring.
Quoted 6 lines
#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING ret = x509_validate_trust(cert, system_trusted_keyring); if (!ret) prep->trusted = 1;#endif
The last patch set changes the test to:
ret = x509_validate_trust(cert, get_system_or_owner_trusted_keyring());
Quoted 7 lines
Keys which come from user-space will check for
if (
keys_ownerid&&strcmp(keys_ownerid, id))return -EPERM;So 2 lines patch works fine..
It works based on the assumption, that you would ever only want a single key on the 'owner' keyring, which is probably not the case.
Mimi
Dmitry Kasatkin
maintainerRe: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
Quoted 38 lines · Mimi Zohar
Quoted 25 lines · Dmitry Kasatkin
Quoted 24 lines · Mimi Zohar
Quoted 23 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
Quoted 8 lines
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Hello,
The functionality of this entire patch can be replaced by only ~2 lines of code in
x509_request_asymmetric_key()if (
keys_ownerid||strcmp(keys_ownerid, id))return -EPERM;Right?
Quoted 8 lines
Quoted 1 line
Are you suggesting only add the one matching key to the system keyring?
No. I am not suggesting this.
All built in keys are allocated with
KEY_ALLOC_TRUSTEDflag and prep.trusted is set to "true".So the following statement has no effect.
Ok, so it has no affect on adding builtin keys to the system keyring.
Quoted 1 line
Quoted 9 lines
Quoted 5 lines
#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING ret = x509_validate_trust(cert, system_trusted_keyring); if (!ret) prep->trusted = 1;#endif
The last patch set changes the test to:
ret = x509_validate_trust(cert, get_system_or_owner_trusted_keyring());
It does not really mater. I just copied original code to my response.
Quoted 11 lines
Quoted 7 lines
Keys which come from user-space will check for
if (
keys_ownerid&&strcmp(keys_ownerid, id))return -EPERM;So 2 lines patch works fine..
It works based on the assumption, that you would ever only want a single key on the 'owner' keyring, which is probably not the case.
There is no any assumption here. I am discussing functionality of this patch. That is exactly what this patch does - loads single key on the owners keyring.
There is no need for additional keyring for a single key. That is just enough to limit verification to the owners key id.
- Dmitry
Quoted 6 lines
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
Thanks, Dmitry
Dmitry Kasatkin
maintainerRe: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
Quoted 63 lines · Dmitry Kasatkin
Quoted 38 lines · Mimi Zohar
Quoted 25 lines · Dmitry Kasatkin
Quoted 24 lines · Mimi Zohar
Quoted 23 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
Quoted 8 lines
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Hello,
The functionality of this entire patch can be replaced by only ~2 lines of code in
x509_request_asymmetric_key()if (
keys_ownerid||strcmp(keys_ownerid, id))return -EPERM;Right?
Quoted 8 lines
Quoted 1 line
Are you suggesting only add the one matching key to the system keyring?
No. I am not suggesting this.
All built in keys are allocated with
KEY_ALLOC_TRUSTEDflag and prep.trusted is set to "true".So the following statement has no effect.
Ok, so it has no affect on adding builtin keys to the system keyring.
Quoted 1 line
Quoted 9 lines
Quoted 5 lines
#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING ret = x509_validate_trust(cert, system_trusted_keyring); if (!ret) prep->trusted = 1;#endif
The last patch set changes the test to:
ret = x509_validate_trust(cert, get_system_or_owner_trusted_keyring());It does not really mater. I just copied original code to my response.
Quoted 11 lines
Quoted 7 lines
Keys which come from user-space will check for
if (
keys_ownerid&&strcmp(keys_ownerid, id))return -EPERM;So 2 lines patch works fine..
It works based on the assumption, that you would ever only want a single key on the 'owner' keyring, which is probably not the case.
Quoted 9 lines
There is no any assumption here. I am discussing functionality of this patch. That is exactly what this patch does - loads single key on the owners keyring.
There is no need for additional keyring for a single key. That is just enough to limit verification to the owners key id.
- Dmitry
There is no reason to have advanced bloated implementation for unsure, may be never coming use-cases.
It is always very easy to make new patches for the future cases.
- Dmitry
Quoted 2 lines
Quoted 2 lines
Mimi
Re: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
Quoted 67 lines · Dmitry Kasatkin
Quoted 66 lines · Dmitry Kasatkin
Quoted 38 lines · Mimi Zohar
Quoted 25 lines · Dmitry Kasatkin
Quoted 24 lines · Mimi Zohar
Quoted 23 lines · Dmitry Kasatkin
Quoted 5 lines · Mimi Zohar
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
Quoted 8 lines
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Hello,
The functionality of this entire patch can be replaced by only ~2 lines of code in
x509_request_asymmetric_key()if (
keys_ownerid||strcmp(keys_ownerid, id))return -EPERM;Right?
Quoted 8 lines
Quoted 1 line
Are you suggesting only add the one matching key to the system keyring?
No. I am not suggesting this.
All built in keys are allocated with
KEY_ALLOC_TRUSTEDflag and prep.trusted is set to "true".So the following statement has no effect.
Ok, so it has no affect on adding builtin keys to the system keyring.
Quoted 1 line
Quoted 9 lines
Quoted 5 lines
#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING ret = x509_validate_trust(cert, system_trusted_keyring); if (!ret) prep->trusted = 1;#endif
The last patch set changes the test to:
ret = x509_validate_trust(cert, get_system_or_owner_trusted_keyring());It does not really mater. I just copied original code to my response.
Quoted 11 lines
Quoted 7 lines
Keys which come from user-space will check for
if (
keys_ownerid&&strcmp(keys_ownerid, id))return -EPERM;So 2 lines patch works fine..
It works based on the assumption, that you would ever only want a single key on the 'owner' keyring, which is probably not the case.
There is no any assumption here. I am discussing functionality of this patch. That is exactly what this patch does - loads single key on the owners keyring.
Quoted 8 lines
Quoted 3 lines
There is no need for additional keyring for a single key. That is just enough to limit verification to the owners key id.
There is no reason to have advanced bloated implementation for unsure, may be never coming use-cases.
It is always very easy to make new patches for the future cases.
Normally I would agree with you, but in this case we already have multiple use case scenarios (eg. builtin keys, transitioning from one MOK key to another), but are simply waiting for the proposed UEFI key patches to be upstreamed. Basically, we need the UEFI key patches functionality, if not these specific patches, to safely identify the owner's key(s), without requiring the end user to rebuild the kernel to include their key(s).
Mimi
cover KEYS: validate key trust with owner and builtin keys only
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative patches not requiring to have additional keyring.
First patch are irrelevant minor fixes.
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once MODULE_SIG_UEFI is enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disabling MODULE_SIG_UEFI.
Josh, why such design decision was made?
Why not to provide kernel parameter to have more fine-tune control over the functionality? Unconfigured machines will not have MokIgnoreDb and will allow to load kernel modules signed with certain undesired keys. In fact, I beleive, it should be default behavior of the kernel. Bootloader can enable UEFI functionality by specifing it on the kernel command line.
Second patch allows to overcome keys coming from UEFI for key validation by specifing owner key id and is an alternative for v5 4/4 patch.
It was also a good idea presented in Mimi's v4 4/4 patch to have possibility to limit key trust valiation by only builtin keys. Third patch as an alternative. It uses keys->flags to specify origin of the key, but any additional field could be added as well.
Both key id and origin verification is done in x509_validate_trust().
Thanks,
Dmitry
Dmitry Kasatkin (3):
KEYS: fix couple of things
KEYS: validate key trust only with selected owner key
KEYS: validate key trust only with builtin keys
Mimi Zohar (1):
KEYS: define an owner trusted keyring
Documentation/kernel-parameters.txt | 5 +++++ crypto/asymmetric_keys/x509_public_key.c | 35 +++++++++++++++++++++++++++++--- include/linux/key.h | 1 + kernel/system_keyring.c | 1 + 4 files changed, 39 insertions(+), 3 deletions(-)
Signature · 1 line
1.9.1
PATCH 1/4 KEYS: define an owner trusted keyring
From: Mimi Zohar <[email protected]>
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function get_system_or_owner_trusted_keyring().
--- Documentation/kernel-parameters.txt | 5 ++ crypto/asymmetric_keys/x509_public_key.c | 4 +- include/keys/owner_keyring.h | 27 ++++++++++ init/Kconfig | 10 ++++ kernel/Makefile | 1 + kernel/owner_keyring.c | 85 ++++++++++++++++++++++++++++++++ 6 files changed, 131 insertions(+), 1 deletion(-) create mode 100644 include/keys/owner_keyring.h create mode 100644 kernel/owner_keyring.c
Documentation/kernel-parameters.txt +5 -0
@@ -1434,6 +1434,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. use the HighMem zone if it exists, and the Normal zone if it does not. + keys_ownerid=[KEYS] This parameter identifies a specific key on + the system trusted keyring to be added to the + owner trusted keyring. + format: id:<keyid> + kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port. Format: <Controller#>[,poll interval] The controller # is the number of the ehci usb debug
crypto/asymmetric_keys/x509_public_key.c +3 -1
@@ -19,6 +19,7 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> +#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h"
@@ -237,7 +238,8 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else { - ret =x509_validate_trust (cert,get_system_trusted_keyring ()); + ret =x509_validate_trust (cert, +get_system_or_owner_trusted_keyring ());if (!ret) prep->trusted =1 ; }
include/keys/owner_keyring.h new file +27 -0
@@ -0,0 +1,27 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#ifndef _KEYS_OWNER_KEYRING_H +#define _KEYS_OWNER_KEYRING_H + +#ifdef CONFIG_OWNER_TRUSTED_KEYRING + +#include <linux/key.h> + +extern struct key *owner_trusted_keyring; +extern struct key *get_system_or_owner_trusted_keyring (void ); + +#else +static inline struct key *get_system_or_owner_trusted_keyring (void ) +{ +return get_system_trusted_keyring (); +} + +#endif +#endif /* _KEYS_OWNER_KEYRING_H */
init/Kconfig +10 -0
@@ -1661,6 +1661,16 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. +config OWNER_TRUSTED_KEYRING + bool "Verify certificate signatures using a specific system key" + depends on SYSTEM_TRUSTED_KEYRING + help + Verify a certificate's signature, before adding the key to + a trusted keyring, using a specific key on the system trusted + keyring. The specific key on the system trusted keyring is + identified using the kernel boot command line option + "keys_ownerid" and is added to the owner_trusted_keyring. + menuconfig MODULES bool "Enable loadable module support" option modules
kernel/Makefile +1 -0
@@ -44,6 +44,7 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o +obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.o
kernel/owner_keyring.c new file +85 -0
85 lines not on this page · raw message
Signature · 1 line
1.9.1
Re: [PATCH 1/4] KEYS: define an owner trusted keyring
Quoted 33 lines · Dmitry Kasatkin
From: Mimi Zohar <[email protected]>
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Signed-off-by Mimi Zohar<[email protected]>--- Documentation/kernel-parameters.txt | 5 ++ crypto/asymmetric_keys/x509_public_key.c | 4 +- include/keys/owner_keyring.h | 27 ++++++++++ init/Kconfig | 10 ++++ kernel/Makefile | 1 + kernel/owner_keyring.c | 85 ++++++++++++++++++++++++++++++++ 6 files changed, 131 insertions(+), 1 deletion(-) create mode 100644 include/keys/owner_keyring.h create mode 100644 kernel/owner_keyring.cDocumentation/kernel-parameters.txt +0
-0
Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can also be entirely omitted. · line 1441
Quoted 8 lines
Documentation/kernel-parameters.txt +5
-0@@ -1434,6 +1434,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. use the HighMem zone if it exists, and the Normal zone if it does not. + keys_ownerid=[KEYS] This parameter identifies a specific key on + the system trusted keyring to be added to the + owner trusted keyring. + format: id:<keyid> +
I'm fairly sure this runs into the same problems I mentioned previously in the secure boot context. Namely that a remote attacker could modify keys_ownerid in the bootloader config file if they gained root access.
josh
Quoted 185 lines
Documentation/kernel-parameters.txt +0
-0kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port. Format: <Controller#>[,poll interval] The controller # is the number of the ehci usb debugcrypto/asymmetric_keys/x509_public_key.c +3
-1@@ -19,6 +19,7 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> +#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" @@ -237,7 +238,8 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else { - ret =x509_validate_trust (cert,get_system_trusted_keyring ()); + ret =x509_validate_trust (cert, +get_system_or_owner_trusted_keyring ());if (!ret) prep->trusted =1 ; }include/keys/owner_keyring.h new file +27
-0@@ -0,0 +1,27 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#ifndef _KEYS_OWNER_KEYRING_H +#define _KEYS_OWNER_KEYRING_H + +#ifdef CONFIG_OWNER_TRUSTED_KEYRING + +#include <linux/key.h> + +extern struct key *owner_trusted_keyring; +extern struct key *get_system_or_owner_trusted_keyring (void ); + +#else +static inline struct key *get_system_or_owner_trusted_keyring (void ) +{ +return get_system_trusted_keyring (); +} + +#endif +#endif /* _KEYS_OWNER_KEYRING_H */ init/Kconfig +10
-0@@ -1661,6 +1661,16 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. +config OWNER_TRUSTED_KEYRING + bool "Verify certificate signatures using a specific system key" + depends on SYSTEM_TRUSTED_KEYRING + help + Verify a certificate's signature, before adding the key to + a trusted keyring, using a specific key on the system trusted + keyring. The specific key on the system trusted keyring is + identified using the kernel boot command line option + "keys_ownerid" and is added to the owner_trusted_keyring. + menuconfig MODULES bool "Enable loadable module support" option moduleskernel/Makefile +1
-0@@ -44,6 +44,7 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o +obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.okernel/owner_keyring.c new file +85
-0@@ -0,0 +1,85 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#include <linux/export.h> +#include <linux/kernel.h> +#include <linux/sched.h> +#include <linux/cred.h> +#include <linux/err.h> +#include <keys/asymmetric-type.h> +#include <keys/system_keyring.h> +#include "module-internal.h" + +struct key *owner_trusted_keyring; +static int use_owner_trusted_keyring; + +static char *owner_keyid; +static int __init default_owner_keyid_set (char *str) +{ +if (!str)/* default system keyring */ +return 1 ; + +if (strncmp (str,"id:" ,3 ) ==0 ) + owner_keyid = str;/* owner local key 'id:xxxxxx' */ + +return 1 ; +} + +__setup ("keys_ownerid=" , default_owner_keyid_set); + +struct key *get_system_or_owner_trusted_keyring (void ) +{ +return use_owner_trusted_keyring ? owner_trusted_keyring : +get_system_trusted_keyring (); +} + +static __init int owner_trusted_keyring_init (void ) +{ +pr_notice ("Initialize the owner trusted keyring\n" ); + + owner_trusted_keyring = +keyring_alloc (".owner_keyring" , +KUIDT_INIT (0 ),KGIDT_INIT (0 ),current_cred (), + ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | +KEY_USR_VIEW |KEY_USR_READ |KEY_USR_SEARCH ), +KEY_ALLOC_NOT_IN_QUOTA ,NULL ); +if (IS_ERR (owner_trusted_keyring)) +panic ("Can't allocate owner trusted keyring\n" ); + +set_bit (KEY_FLAG_TRUSTED_ONLY , &owner_trusted_keyring->flags); +return 0 ; +} + +device_initcall (owner_trusted_keyring_init); + +void load_owner_identified_key (void ) +{ +key_ref_t key_ref; +int ret; + +if (!owner_keyid) +return ; + + key_ref =keyring_search (make_key_ref (system_trusted_keyring,1 ), + &key_type_asymmetric, owner_keyid); +if (IS_ERR (key_ref)) { +pr_warn ("Request for unknown %s key\n" , owner_keyid); + goto out; + } + ret =key_link (owner_trusted_keyring,key_ref_to_ptr (key_ref)); +pr_info ("Loaded owner key %s %s\n" , owner_keyid, + ret <0 ?"failed" :"succeeded" ); +key_ref_put (key_ref); +if (!ret) + use_owner_trusted_keyring =1 ; +out: +return ; +} + +late_initcall (load_owner_identified_key);Signature · 1 line
1.9.1
Re: [PATCH 1/4] KEYS: define an owner trusted keyring
Quoted 46 lines · Josh Boyer
Quoted 33 lines · Dmitry Kasatkin
From: Mimi Zohar <[email protected]>
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Signed-off-by Mimi Zohar<[email protected]>--- Documentation/kernel-parameters.txt | 5 ++ crypto/asymmetric_keys/x509_public_key.c | 4 +- include/keys/owner_keyring.h | 27 ++++++++++ init/Kconfig | 10 ++++ kernel/Makefile | 1 + kernel/owner_keyring.c | 85 ++++++++++++++++++++++++++++++++ 6 files changed, 131 insertions(+), 1 deletion(-) create mode 100644 include/keys/owner_keyring.h create mode 100644 kernel/owner_keyring.cDocumentation/kernel-parameters.txt +0
-0Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can also be entirely omitted. · line 1441
Quoted 8 lines
Documentation/kernel-parameters.txt +5
-0@@ -1434,6 +1434,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. use the HighMem zone if it exists, and the Normal zone if it does not. + keys_ownerid=[KEYS] This parameter identifies a specific key on + the system trusted keyring to be added to the + owner trusted keyring. + format: id:<keyid> +I'm fairly sure this runs into the same problems I mentioned previously in the secure boot context. Namely that a remote attacker could modify
keys_owneridin the bootloader config file if they gained root access.
Quoted 1 line
josh
This patch is original patch and actually I sent it by mistake providing HEAD~3 instead of HEAD~2 on git-send-email...
But anyway kernel parameter stays...
ok. case is "unprotected" boot loader.
Thanks.
Quoted 185 lines
Quoted 185 lines
Documentation/kernel-parameters.txt +0
-0kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port. Format: <Controller#>[,poll interval] The controller # is the number of the ehci usb debugcrypto/asymmetric_keys/x509_public_key.c +3
-1@@ -19,6 +19,7 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> +#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" @@ -237,7 +238,8 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else { - ret =x509_validate_trust (cert,get_system_trusted_keyring ()); + ret =x509_validate_trust (cert, +get_system_or_owner_trusted_keyring ());if (!ret) prep->trusted =1 ; }include/keys/owner_keyring.h new file +27
-0@@ -0,0 +1,27 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#ifndef _KEYS_OWNER_KEYRING_H +#define _KEYS_OWNER_KEYRING_H + +#ifdef CONFIG_OWNER_TRUSTED_KEYRING + +#include <linux/key.h> + +extern struct key *owner_trusted_keyring; +extern struct key *get_system_or_owner_trusted_keyring (void ); + +#else +static inline struct key *get_system_or_owner_trusted_keyring (void ) +{ +return get_system_trusted_keyring (); +} + +#endif +#endif /* _KEYS_OWNER_KEYRING_H */ init/Kconfig +10
-0@@ -1661,6 +1661,16 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. +config OWNER_TRUSTED_KEYRING + bool "Verify certificate signatures using a specific system key" + depends on SYSTEM_TRUSTED_KEYRING + help + Verify a certificate's signature, before adding the key to + a trusted keyring, using a specific key on the system trusted + keyring. The specific key on the system trusted keyring is + identified using the kernel boot command line option + "keys_ownerid" and is added to the owner_trusted_keyring. + menuconfig MODULES bool "Enable loadable module support" option moduleskernel/Makefile +1
-0@@ -44,6 +44,7 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o +obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.okernel/owner_keyring.c new file +85
-0@@ -0,0 +1,85 @@ +/* +* Copyright (C) 2014 IBM Corporation +* Author: Mimi Zohar <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation, version 2 of the License. +*/ + +#include <linux/export.h> +#include <linux/kernel.h> +#include <linux/sched.h> +#include <linux/cred.h> +#include <linux/err.h> +#include <keys/asymmetric-type.h> +#include <keys/system_keyring.h> +#include "module-internal.h" + +struct key *owner_trusted_keyring; +static int use_owner_trusted_keyring; + +static char *owner_keyid; +static int __init default_owner_keyid_set (char *str) +{ +if (!str)/* default system keyring */ +return 1 ; + +if (strncmp (str,"id:" ,3 ) ==0 ) + owner_keyid = str;/* owner local key 'id:xxxxxx' */ + +return 1 ; +} + +__setup ("keys_ownerid=" , default_owner_keyid_set); + +struct key *get_system_or_owner_trusted_keyring (void ) +{ +return use_owner_trusted_keyring ? owner_trusted_keyring : +get_system_trusted_keyring (); +} + +static __init int owner_trusted_keyring_init (void ) +{ +pr_notice ("Initialize the owner trusted keyring\n" ); + + owner_trusted_keyring = +keyring_alloc (".owner_keyring" , +KUIDT_INIT (0 ),KGIDT_INIT (0 ),current_cred (), + ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | +KEY_USR_VIEW |KEY_USR_READ |KEY_USR_SEARCH ), +KEY_ALLOC_NOT_IN_QUOTA ,NULL ); +if (IS_ERR (owner_trusted_keyring)) +panic ("Can't allocate owner trusted keyring\n" ); + +set_bit (KEY_FLAG_TRUSTED_ONLY , &owner_trusted_keyring->flags); +return 0 ; +} + +device_initcall (owner_trusted_keyring_init); + +void load_owner_identified_key (void ) +{ +key_ref_t key_ref; +int ret; + +if (!owner_keyid) +return ; + + key_ref =keyring_search (make_key_ref (system_trusted_keyring,1 ), + &key_type_asymmetric, owner_keyid); +if (IS_ERR (key_ref)) { +pr_warn ("Request for unknown %s key\n" , owner_keyid); + goto out; + } + ret =key_link (owner_trusted_keyring,key_ref_to_ptr (key_ref)); +pr_info ("Loaded owner key %s %s\n" , owner_keyid, + ret <0 ?"failed" :"succeeded" ); +key_ref_put (key_ref); +if (!ret) + use_owner_trusted_keyring =1 ; +out: +return ; +} + +late_initcall (load_owner_identified_key);Signature · 1 line
1.9.1
Re: [PATCH 1/4] KEYS: define an owner trusted keyring
In reply to Josh BoyerQuoted 37 lines · Josh Boyer
Quoted 36 lines · Dmitry Kasatkin
From: Mimi Zohar <[email protected]>
Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring.
When the UEFI secure boot keys are added to the system keyring, the platform owner will be able to load their key in one of the UEFI DBs (eg. Machine Owner Key(MOK) list) and select their key, without having to rebuild the kernel.
This patch defines an owner trusted keyring, a new boot command line option 'keys_ownerid=', and defines a new function
get_system_or_owner_trusted_keyring().Signed-off-by Mimi Zohar<[email protected]>--- Documentation/kernel-parameters.txt | 5 ++ crypto/asymmetric_keys/x509_public_key.c | 4 +- include/keys/owner_keyring.h | 27 ++++++++++ init/Kconfig | 10 ++++ kernel/Makefile | 1 + kernel/owner_keyring.c | 85 ++++++++++++++++++++++++++++++++ 6 files changed, 131 insertions(+), 1 deletion(-) create mode 100644 include/keys/owner_keyring.h create mode 100644 kernel/owner_keyring.cDocumentation/kernel-parameters.txt +0
-0@@ -1434,6 +1434,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. use the HighMem zone if it exists, and the Normal zone if it does not.
Quoted 9 lines
Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can also be entirely omitted. · line 1441
Quoted 5 lines
Documentation/kernel-parameters.txt +5
-0+ keys_ownerid=[KEYS] This parameter identifies a specific key on + the system trusted keyring to be added to the + owner trusted keyring. + format: id:<keyid> +I'm fairly sure this runs into the same problems I mentioned previously in the secure boot context. Namely that a remote attacker could modify
keys_owneridin the bootloader config file if they gained root access.
Yes, someone could specify a key not in the UEFI DB or builtin, but it would not do them much good. The "keys_ownerid" searches the UEFI/builtin keys for the keyid.
Mimi
PATCH 2/4 KEYS: fix couple of things
In reply to Dmitry Kasatkin--- crypto/asymmetric_keys/x509_public_key.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
crypto/asymmetric_keys/x509_public_key.c +2 -1
@@ -177,6 +177,7 @@ static int x509_validate_trust(struct x509_certificate *cert,if (!IS_ERR (key)) { pk = key->payload.data; ret =x509_check_signature (pk, cert); +key_put (key); }return ret; }
@@ -237,7 +238,7 @@ static int x509_key_preparse(struct key_preparsed_payload *prep) ret =x509_check_signature (cert->pub, cert);/* self-signed */ if (ret <0 ) goto error_free_cert; - }else { + }else if (!prep->trusted) { ret =x509_validate_trust (cert,get_system_or_owner_trusted_keyring ());if (!ret)
Signature · 1 line
1.9.1
PATCH 3/4 KEYS: validate key trust only with selected owner key
In reply to Dmitry KasatkinThis patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
--- crypto/asymmetric_keys/x509_public_key.c | 27 ++++++++-- include/keys/owner_keyring.h | 27 ---------- init/Kconfig | 10 ---- kernel/Makefile | 1 - kernel/owner_keyring.c | 85 -------------------------------- 5 files changed, 24 insertions(+), 126 deletions(-) delete mode 100644 include/keys/owner_keyring.h delete mode 100644 kernel/owner_keyring.c
crypto/asymmetric_keys/x509_public_key.c +24 -3
@@ -19,12 +19,24 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> -#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" +static char *owner_keyid; +static int __init default_owner_keyid_set (char *str) +{ +if (!str)/* default system keyring */ +return 1 ; + +if (strncmp (str,"id:" ,3 ) ==0 ) + owner_keyid = str;/* owner local key 'id:xxxxxx' */ + +return 1 ; +} +__setup ("keys_ownerid=" , default_owner_keyid_set); +/* * Find a key in the given keyring by issuer and authority. */
@@ -170,6 +182,16 @@ static int x509_validate_trust(struct x509_certificate *cert,if (!trust_keyring)return -EOPNOTSUPP ; +if (owner_keyid) { +/* validate trust only with the owner_keyid if specified */ +/* partial match of keyid according to the asymmetric_type.c */ +int idlen =strlen (owner_keyid) -3 ;/* - id: */ +int authlen =strlen (cert->authority); +char *auth = cert->authority + authlen - idlen; +if (idlen > authlen ||strcasecmp (owner_keyid +3 , auth)) +return -EPERM ; + } + key = x509_request_asymmetric_key(trust_keyring, cert->issuer, strlen(cert->issuer), cert->authority,
@@ -239,8 +261,7 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else if (!prep->trusted) { - ret =x509_validate_trust (cert, -get_system_or_owner_trusted_keyring ()); + ret =x509_validate_trust (cert,get_system_trusted_keyring ());if (!ret) prep->trusted =1 ; }
include/keys/owner_keyring.h deleted +0 -27
@@ -1,27 +0,0 @@ -/* -* Copyright (C) 2014 IBM Corporation -* Author: Mimi Zohar <[email protected]> -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License as published by -* the Free Software Foundation, version 2 of the License. -*/ - -#ifndef _KEYS_OWNER_KEYRING_H -#define _KEYS_OWNER_KEYRING_H - -#ifdef CONFIG_OWNER_TRUSTED_KEYRING - -#include <linux/key.h> - -extern struct key *owner_trusted_keyring; -extern struct key *get_system_or_owner_trusted_keyring (void ); - -#else -static inline struct key *get_system_or_owner_trusted_keyring (void ) -{ -return get_system_trusted_keyring (); -} - -#endif -#endif /* _KEYS_OWNER_KEYRING_H */
init/Kconfig +0 -10
@@ -1661,16 +1661,6 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. -config OWNER_TRUSTED_KEYRING - bool "Verify certificate signatures using a specific system key" - depends on SYSTEM_TRUSTED_KEYRING - help - Verify a certificate's signature, before adding the key to - a trusted keyring, using a specific key on the system trusted - keyring. The specific key on the system trusted keyring is - identified using the kernel boot command line option - "keys_ownerid" and is added to the owner_trusted_keyring. - menuconfig MODULES bool "Enable loadable module support" option modules
kernel/Makefile +0 -1
@@ -44,7 +44,6 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o -obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.o
kernel/owner_keyring.c deleted +0 -85
85 lines not on this page · raw message
Signature · 1 line
1.9.1
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>
Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in system_trusted_keyring.
I think the OS vendor key which signs the kernel signing key propagates to system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way to system_trusted_keyring).
So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in system_trusted_keyring, it should work.
Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Thanks
Vivek
Quoted 231 lines
--- crypto/asymmetric_keys/x509_public_key.c | 27 ++++++++-- include/keys/owner_keyring.h | 27 ---------- init/Kconfig | 10 ---- kernel/Makefile | 1 - kernel/owner_keyring.c | 85 -------------------------------- 5 files changed, 24 insertions(+), 126 deletions(-) delete mode 100644 include/keys/owner_keyring.h delete mode 100644 kernel/owner_keyring.ccrypto/asymmetric_keys/x509_public_key.c +24
-3@@ -19,12 +19,24 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> -#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" +static char *owner_keyid; +static int __init default_owner_keyid_set (char *str) +{ +if (!str)/* default system keyring */ +return 1 ; + +if (strncmp (str,"id:" ,3 ) ==0 ) + owner_keyid = str;/* owner local key 'id:xxxxxx' */ + +return 1 ; +} +__setup ("keys_ownerid=" , default_owner_keyid_set); +/* * Find a key in the given keyring by issuer and authority. */ @@ -170,6 +182,16 @@ static int x509_validate_trust(struct x509_certificate *cert,if (!trust_keyring)return -EOPNOTSUPP ; +if (owner_keyid) { +/* validate trust only with the owner_keyid if specified */ +/* partial match of keyid according to the asymmetric_type.c */ +int idlen =strlen (owner_keyid) -3 ;/* - id: */ +int authlen =strlen (cert->authority); +char *auth = cert->authority + authlen - idlen; +if (idlen > authlen ||strcasecmp (owner_keyid +3 , auth)) +return -EPERM ; + } + key = x509_request_asymmetric_key(trust_keyring, cert->issuer, strlen(cert->issuer), cert->authority,@@ -239,8 +261,7 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else if (!prep->trusted) { - ret =x509_validate_trust (cert, -get_system_or_owner_trusted_keyring ()); + ret =x509_validate_trust (cert,get_system_trusted_keyring ());if (!ret) prep->trusted =1 ; }include/keys/owner_keyring.h deleted +0
-27@@ -1,27 +0,0 @@ -/* -* Copyright (C) 2014 IBM Corporation -* Author: Mimi Zohar <[email protected]> -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License as published by -* the Free Software Foundation, version 2 of the License. -*/ - -#ifndef _KEYS_OWNER_KEYRING_H -#define _KEYS_OWNER_KEYRING_H - -#ifdef CONFIG_OWNER_TRUSTED_KEYRING - -#include <linux/key.h> - -extern struct key *owner_trusted_keyring; -extern struct key *get_system_or_owner_trusted_keyring (void ); - -#else -static inline struct key *get_system_or_owner_trusted_keyring (void ) -{ -return get_system_trusted_keyring (); -} - -#endif -#endif /* _KEYS_OWNER_KEYRING_H */ init/Kconfig +0
-10@@ -1661,16 +1661,6 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. -config OWNER_TRUSTED_KEYRING - bool "Verify certificate signatures using a specific system key" - depends on SYSTEM_TRUSTED_KEYRING - help - Verify a certificate's signature, before adding the key to - a trusted keyring, using a specific key on the system trusted - keyring. The specific key on the system trusted keyring is - identified using the kernel boot command line option - "keys_ownerid" and is added to the owner_trusted_keyring. - menuconfig MODULES bool "Enable loadable module support" option moduleskernel/Makefile +0
-1@@ -44,7 +44,6 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o -obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.okernel/owner_keyring.c deleted +0
-85@@ -1,85 +0,0 @@ -/* -* Copyright (C) 2014 IBM Corporation -* Author: Mimi Zohar <[email protected]> -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License as published by -* the Free Software Foundation, version 2 of the License. -*/ - -#include <linux/export.h> -#include <linux/kernel.h> -#include <linux/sched.h> -#include <linux/cred.h> -#include <linux/err.h> -#include <keys/asymmetric-type.h> -#include <keys/system_keyring.h> -#include "module-internal.h" - -struct key *owner_trusted_keyring; -static int use_owner_trusted_keyring; - -static char *owner_keyid; -static int __init default_owner_keyid_set (char *str) -{ -if (!str)/* default system keyring */ -return 1 ; - -if (strncmp (str,"id:" ,3 ) ==0 ) - owner_keyid = str;/* owner local key 'id:xxxxxx' */ - -return 1 ; -} - -__setup ("keys_ownerid=" , default_owner_keyid_set); - -struct key *get_system_or_owner_trusted_keyring (void ) -{ -return use_owner_trusted_keyring ? owner_trusted_keyring : -get_system_trusted_keyring (); -} - -static __init int owner_trusted_keyring_init (void ) -{ -pr_notice ("Initialize the owner trusted keyring\n" ); - - owner_trusted_keyring = -keyring_alloc (".owner_keyring" , -KUIDT_INIT (0 ),KGIDT_INIT (0 ),current_cred (), - ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | -KEY_USR_VIEW |KEY_USR_READ |KEY_USR_SEARCH ), -KEY_ALLOC_NOT_IN_QUOTA ,NULL ); -if (IS_ERR (owner_trusted_keyring)) -panic ("Can't allocate owner trusted keyring\n" ); - -set_bit (KEY_FLAG_TRUSTED_ONLY , &owner_trusted_keyring->flags); -return 0 ; -} - -device_initcall (owner_trusted_keyring_init); - -void load_owner_identified_key (void ) -{ -key_ref_t key_ref; -int ret; - -if (!owner_keyid) -return ; - - key_ref =keyring_search (make_key_ref (system_trusted_keyring,1 ), - &key_type_asymmetric, owner_keyid); -if (IS_ERR (key_ref)) { -pr_warn ("Request for unknown %s key\n" , owner_keyid); - goto out; - } - ret =key_link (owner_trusted_keyring,key_ref_to_ptr (key_ref)); -pr_info ("Loaded owner key %s %s\n" , owner_keyid, - ret <0 ?"failed" :"succeeded" ); -key_ref_put (key_ref); -if (!ret) - use_owner_trusted_keyring =1 ; -out: -return ; -} - -late_initcall (load_owner_identified_key);Signature · 6 lines
1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 13 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Quoted 6 lines
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).
The shim patches are here
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
Quoted 10 lines
So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Right, the current discussion is whether we need an owner trusted keyring or if just one key was enough. Thanks for chiming in.
The other option would be to sign the bzImage file creating a 'security.ima' extended attribute and verifying it. Have you created a security kexec hook?
thanks,
Mimi
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 35 lines · Mimi Zohar
Quoted 13 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Quoted 6 lines
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).The shim patches are here
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patchQuoted 10 lines
So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Quoted 6 lines
Right, the current discussion is whether we need an owner trusted keyring or if just one key was enough. Thanks for chiming in.
The other option would be to sign the bzImage file creating a 'security.ima' extended attribute and verifying it. Have you created a security kexec hook?
No, I have not created another hook. As bzImage is already signed it is much simpler to verify same signature instead of carrying another set of detached signatures and key management etc.
Thanks
Vivek
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 39 lines · Vivek Goyal
Quoted 38 lines · Mimi Zohar
Quoted 13 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Quoted 6 lines
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).The shim patches are here
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patchQuoted 10 lines
So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Right, the current discussion is whether we need an owner trusted keyring or if just one key was enough. Thanks for chiming in.
Quoted 7 lines
Quoted 3 lines
The other option would be to sign the bzImage file creating a 'security.ima' extended attribute and verifying it. Have you created a security kexec hook?
No, I have not created another hook. As bzImage is already signed it is much simpler to verify same signature instead of carrying another set of detached signatures and key management etc.
Fin (cc'ed) has patches that include the file signatures in the RPM header and installs them. There wouldn't be any need for a separate detached signature.
Mimi
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 44 lines · Mimi Zohar
Quoted 43 lines · Vivek Goyal
Quoted 41 lines · Mimi Zohar
Quoted 13 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Quoted 6 lines
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).The shim patches are here
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patchQuoted 10 lines
So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Right, the current discussion is whether we need an owner trusted keyring or if just one key was enough. Thanks for chiming in.
The other option would be to sign the bzImage file creating a 'security.ima' extended attribute and verifying it. Have you created a security kexec hook?
Quoted 7 lines
Quoted 3 lines
No, I have not created another hook. As bzImage is already signed it is much simpler to verify same signature instead of carrying another set of detached signatures and key management etc.
Fin (cc'ed) has patches that include the file signatures in the RPM header and installs them. There wouldn't be any need for a separate detached signature.
Currently distributions are already shipping bzImage signed with PE/COFF signature. If we go this way, now they will have to sign bzImage twice. And this time in IMA format and pack signatures in rpm. Managing two different signatures for same bzImage is just going to be an unnecessary headache for everybody, IMHO.
I am wondering how about coming up with x509_validate_trust_key() where you specify that validate trust against a specific key (instead of keyring). Another function will be x509_validate_trust() which will take keyring as input and will trust all keys in keyring.
As I am not adding a key, I can just use x509_validate_trust(system_keyring) for signature verification and in key add path you can continue to use x509_validate_trust_key() if somebody used command line keys_ownerid=.
Thanks
Vivek
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
In reply to Vivek GoyalQuoted 23 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.
Quoted 6 lines
Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of owner_keyid is limited to validate the trust of the loaded keys.
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
- Dmitry
Quoted 234 lines
Thanks
VivekQuoted 231 lines
--- crypto/asymmetric_keys/x509_public_key.c | 27 ++++++++-- include/keys/owner_keyring.h | 27 ---------- init/Kconfig | 10 ---- kernel/Makefile | 1 - kernel/owner_keyring.c | 85 -------------------------------- 5 files changed, 24 insertions(+), 126 deletions(-) delete mode 100644 include/keys/owner_keyring.h delete mode 100644 kernel/owner_keyring.ccrypto/asymmetric_keys/x509_public_key.c +24
-3@@ -19,12 +19,24 @@#include <keys/asymmetric-subtype.h> #include <keys/asymmetric-parser.h> #include <keys/system_keyring.h> -#include <keys/owner_keyring.h> #include <crypto/hash.h> #include "asymmetric_keys.h" #include "public_key.h" #include "x509_parser.h" +static char *owner_keyid; +static int __init default_owner_keyid_set (char *str) +{ +if (!str)/* default system keyring */ +return 1 ; + +if (strncmp (str,"id:" ,3 ) ==0 ) + owner_keyid = str;/* owner local key 'id:xxxxxx' */ + +return 1 ; +} +__setup ("keys_ownerid=" , default_owner_keyid_set); +/* * Find a key in the given keyring by issuer and authority. */ @@ -170,6 +182,16 @@ static int x509_validate_trust(struct x509_certificate *cert,if (!trust_keyring)return -EOPNOTSUPP ; +if (owner_keyid) { +/* validate trust only with the owner_keyid if specified */ +/* partial match of keyid according to the asymmetric_type.c */ +int idlen =strlen (owner_keyid) -3 ;/* - id: */ +int authlen =strlen (cert->authority); +char *auth = cert->authority + authlen - idlen; +if (idlen > authlen ||strcasecmp (owner_keyid +3 , auth)) +return -EPERM ; + } + key = x509_request_asymmetric_key(trust_keyring, cert->issuer, strlen(cert->issuer), cert->authority,@@ -239,8 +261,7 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)if (ret <0 ) goto error_free_cert; }else if (!prep->trusted) { - ret =x509_validate_trust (cert, -get_system_or_owner_trusted_keyring ()); + ret =x509_validate_trust (cert,get_system_trusted_keyring ());if (!ret) prep->trusted =1 ; }include/keys/owner_keyring.h deleted +0
-27@@ -1,27 +0,0 @@ -/* -* Copyright (C) 2014 IBM Corporation -* Author: Mimi Zohar <[email protected]> -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License as published by -* the Free Software Foundation, version 2 of the License. -*/ - -#ifndef _KEYS_OWNER_KEYRING_H -#define _KEYS_OWNER_KEYRING_H - -#ifdef CONFIG_OWNER_TRUSTED_KEYRING - -#include <linux/key.h> - -extern struct key *owner_trusted_keyring; -extern struct key *get_system_or_owner_trusted_keyring (void ); - -#else -static inline struct key *get_system_or_owner_trusted_keyring (void ) -{ -return get_system_trusted_keyring (); -} - -#endif -#endif /* _KEYS_OWNER_KEYRING_H */ init/Kconfig +0
-10@@ -1661,16 +1661,6 @@ config SYSTEM_TRUSTED_KEYRING Keys in this keyring are used by module signature checking. -config OWNER_TRUSTED_KEYRING - bool "Verify certificate signatures using a specific system key" - depends on SYSTEM_TRUSTED_KEYRING - help - Verify a certificate's signature, before adding the key to - a trusted keyring, using a specific key on the system trusted - keyring. The specific key on the system trusted keyring is - identified using the kernel boot command line option - "keys_ownerid" and is added to the owner_trusted_keyring. - menuconfig MODULES bool "Enable loadable module support" option moduleskernel/Makefile +0
-1@@ -44,7 +44,6 @@ obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o -obj-$(CONFIG_OWNER_TRUSTED_KEYRING) += owner_keyring.o obj-$(CONFIG_KALLSYMS) += kallsyms.o obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o obj-$(CONFIG_KEXEC) += kexec.okernel/owner_keyring.c deleted +0
-85@@ -1,85 +0,0 @@ -/* -* Copyright (C) 2014 IBM Corporation -* Author: Mimi Zohar <[email protected]> -* -* This program is free software; you can redistribute it and/or modify -* it under the terms of the GNU General Public License as published by -* the Free Software Foundation, version 2 of the License. -*/ - -#include <linux/export.h> -#include <linux/kernel.h> -#include <linux/sched.h> -#include <linux/cred.h> -#include <linux/err.h> -#include <keys/asymmetric-type.h> -#include <keys/system_keyring.h> -#include "module-internal.h" - -struct key *owner_trusted_keyring; -static int use_owner_trusted_keyring; - -static char *owner_keyid; -static int __init default_owner_keyid_set (char *str) -{ -if (!str)/* default system keyring */ -return 1 ; - -if (strncmp (str,"id:" ,3 ) ==0 ) - owner_keyid = str;/* owner local key 'id:xxxxxx' */ - -return 1 ; -} - -__setup ("keys_ownerid=" , default_owner_keyid_set); - -struct key *get_system_or_owner_trusted_keyring (void ) -{ -return use_owner_trusted_keyring ? owner_trusted_keyring : -get_system_trusted_keyring (); -} - -static __init int owner_trusted_keyring_init (void ) -{ -pr_notice ("Initialize the owner trusted keyring\n" ); - - owner_trusted_keyring = -keyring_alloc (".owner_keyring" , -KUIDT_INIT (0 ),KGIDT_INIT (0 ),current_cred (), - ((KEY_POS_ALL & ~KEY_POS_SETATTR ) | -KEY_USR_VIEW |KEY_USR_READ |KEY_USR_SEARCH ), -KEY_ALLOC_NOT_IN_QUOTA ,NULL ); -if (IS_ERR (owner_trusted_keyring)) -panic ("Can't allocate owner trusted keyring\n" ); - -set_bit (KEY_FLAG_TRUSTED_ONLY , &owner_trusted_keyring->flags); -return 0 ; -} - -device_initcall (owner_trusted_keyring_init); - -void load_owner_identified_key (void ) -{ -key_ref_t key_ref; -int ret; - -if (!owner_keyid) -return ; - - key_ref =keyring_search (make_key_ref (system_trusted_keyring,1 ), - &key_type_asymmetric, owner_keyid); -if (IS_ERR (key_ref)) { -pr_warn ("Request for unknown %s key\n" , owner_keyid); - goto out; - } - ret =key_link (owner_trusted_keyring,key_ref_to_ptr (key_ref)); -pr_info ("Loaded owner key %s %s\n" , owner_keyid, - ret <0 ?"failed" :"succeeded" ); -key_ref_put (key_ref); -if (!ret) - use_owner_trusted_keyring =1 ; -out: -return ; -} - -late_initcall (load_owner_identified_key);Signature · 6 lines
1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 28 lines · Dmitry Kasatkin
Quoted 27 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
Quoted 7 lines
Quoted 2 lines
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of
owner_keyidis limited to validate the trust of the loaded keys.
Hi Dmitry,
If owner_keyid scope is just limited to loading extra keys, then it should be fine as I don't want to load extra keys. I just want to verify already signed image whose key is supposed to be in system_trusted_keyring.
Quoted 4 lines
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
I have been told that mechanism to propagate they key in shim which is used to verify kernel signature is in place and that key should show up in system_trusted_keyring. I have never verified it though. I will check it out.
Thanks
Vivek
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 37 lines · Vivek Goyal
Quoted 28 lines · Dmitry Kasatkin
Quoted 27 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
Quoted 7 lines
Quoted 2 lines
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of
owner_keyidis limited to validate the trust of the loaded keys.
Quoted 6 lines
Hi Dmitry,
If
owner_keyidscope is just limited to loading extra keys, then it should be fine as I don't want to load extra keys. I just want to verify already signed image whose key is supposed to be insystem_trusted_keyring.
Yes, sorry my mistake.
Mimi
Quoted 13 lines
Quoted 4 lines
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
I have been told that mechanism to propagate they key in shim which is used to verify kernel signature is in place and that key should show up in
system_trusted_keyring. I have never verified it though. I will check it out.Thanks
Vivek
Dmitry Kasatkin
maintainerRe: [PATCH 3/4] KEYS: validate key trust only with selected owner key
In reply to Vivek GoyalQuoted 49 lines · Vivek Goyal
Quoted 28 lines · Dmitry Kasatkin
Quoted 27 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
Quoted 7 lines
Quoted 2 lines
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of
owner_keyidis limited to validate the trust of the loaded keys.Hi Dmitry,
If
owner_keyidscope is just limited to loading extra keys, then it should be fine as I don't want to load extra keys. I just want to verify already signed image whose key is supposed to be insystem_trusted_keyring.Quoted 4 lines
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
Quoted 7 lines
I have been told that mechanism to propagate they key in shim which is used to verify kernel signature is in place and that key should show up in
system_trusted_keyring. I have never verified it though. I will check it out.Thanks
Vivek
Hi Vivek,
The easiest way to get OS Vendor ker/certificate is just embed it into the kernel along with
ephemeral (or not) module signing key... They all appears on .system keyring...
This solution would work also for ARM based HW which does not have UEFI and MOK...
We also use mini-os with linux kernel as boot loader which in turn boots other kernels.
It is for R&D purpose but with kexec signing support we could think about other use-cases..
Thanks,
Dmitry
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 59 lines · Dmitry Kasatkin
Quoted 49 lines · Vivek Goyal
Quoted 28 lines · Dmitry Kasatkin
Quoted 27 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
Quoted 7 lines
Quoted 2 lines
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of
owner_keyidis limited to validate the trust of the loaded keys.Hi Dmitry,
If
owner_keyidscope is just limited to loading extra keys, then it should be fine as I don't want to load extra keys. I just want to verify already signed image whose key is supposed to be insystem_trusted_keyring.Quoted 4 lines
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
Quoted 7 lines
I have been told that mechanism to propagate they key in shim which is used to verify kernel signature is in place and that key should show up in
system_trusted_keyring. I have never verified it though. I will check it out.Thanks
Vivek
Quoted 5 lines
Hi Vivek,
The easiest way to get OS Vendor ker/certificate is just embed it into the kernel along with
ephemeral (or not) module signing key... They all appears on .system keyring...
I think it will be tricky as in current setup, signing happens on a different server and build server does not have access to keys.
Thanks
Vivek
Dmitry Kasatkin
maintainerRe: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 66 lines · Vivek Goyal
Quoted 59 lines · Dmitry Kasatkin
Quoted 49 lines · Vivek Goyal
Quoted 28 lines · Dmitry Kasatkin
Quoted 27 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
Quoted 7 lines
Quoted 2 lines
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of
owner_keyidis limited to validate the trust of the loaded keys.Hi Dmitry,
If
owner_keyidscope is just limited to loading extra keys, then it should be fine as I don't want to load extra keys. I just want to verify already signed image whose key is supposed to be insystem_trusted_keyring.Quoted 4 lines
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
Quoted 7 lines
I have been told that mechanism to propagate they key in shim which is used to verify kernel signature is in place and that key should show up in
system_trusted_keyring. I have never verified it though. I will check it out.Thanks
VivekQuoted 5 lines
Hi Vivek,
The easiest way to get OS Vendor ker/certificate is just embed it into the kernel along with
ephemeral (or not) module signing key... They all appears on .system keyring...
Quoted 5 lines
I think it will be tricky as in current setup, signing happens on a different server and build server does not have access to keys.
Thanks
Vivek
It should not be tricky... Signing is done with private key... Security measure has to be considered.
Certificate is public and is not a secret.. It can be on any build machine in the world...
Signature · 2 lines
Thanks, Dmitry
Re: [PATCH 3/4] KEYS: validate key trust only with selected owner key
In reply to Vivek GoyalQuoted 60 lines · Vivek Goyal
Quoted 59 lines · Dmitry Kasatkin
Quoted 56 lines · Vivek Goyal
Quoted 28 lines · Dmitry Kasatkin
Quoted 27 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
Quoted 7 lines
Quoted 2 lines
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of
owner_keyidis limited to validate the trust of the loaded keys.Hi Dmitry,
If
owner_keyidscope is just limited to loading extra keys, then it should be fine as I don't want to load extra keys. I just want to verify already signed image whose key is supposed to be insystem_trusted_keyring.Quoted 4 lines
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
I have been told that mechanism to propagate they key in shim which is used to verify kernel signature is in place and that key should show up in
system_trusted_keyring. I have never verified it though. I will check it out.Thanks
Vivek
Quoted 8 lines
Quoted 5 lines
Hi Vivek,
The easiest way to get OS Vendor ker/certificate is just embed it into the kernel along with
ephemeral (or not) module signing key... They all appears on .system keyring...I think it will be tricky as in current setup, signing happens on a different server and build server does not have access to keys.
Apart from this, all the builds might not signed. And at build time it is might not known if a particular build will be signed with final keys or not. One might decide to sign kernel based on testing results post build. So embedding the kernel signing key in the kernel during build is little tricky from process point of view.
Thanks
Vivek
Dmitry Kasatkin
maintainerRe: [PATCH 3/4] KEYS: validate key trust only with selected owner key
Quoted 70 lines · Vivek Goyal
Quoted 60 lines · Vivek Goyal
Quoted 59 lines · Dmitry Kasatkin
Quoted 56 lines · Vivek Goyal
Quoted 28 lines · Dmitry Kasatkin
Quoted 27 lines · Vivek Goyal
Quoted 5 lines · Dmitry Kasatkin
This patch provides kernel parameter to specify owner's key id which must be used for trust validate of keys. Keys signed with other keys are not trusted.
Signed-off-by Dmitry Kasatkin <[email protected]>Hi,
I am continuing to work on verifying kernel signature for kexec/kdump. I am planning to take david howell's patches for pkcs7 signature verification and verify bzImage signature.
Part of that process will boil down to verifying a certificate in pkcs7 x509 cert chain using a key in
system_trusted_keyring.I think the OS vendor key which signs the kernel signing key propagates to
system_trusted_keyring. (shim has that and I am not sure how shim makes it propogate all they way tosystem_trusted_keyring).So I was planning to use same functionality where I look for any key which can verify the signing cert of kernel. As OS vendor key will be in
system_trusted_keyring, it should work.Now with this change where you will trust only one selected owner key. That means you will not even trust the OS vendor key which signs kernel signing key. I think this will stop working with keys_ownerid=<....>
Quoted 7 lines
Quoted 2 lines
As I am doing that work in parallel and I saw these patches, I thought I will bring it up.
Hi Vivek,
All keys stays in the keyring. Usage of
owner_keyidis limited to validate the trust of the loaded keys.Hi Dmitry,
If
owner_keyidscope is just limited to loading extra keys, then it should be fine as I don't want to load extra keys. I just want to verify already signed image whose key is supposed to be insystem_trusted_keyring.Quoted 4 lines
Do you really see OS verndor key (Fedora) on the system keyring? shim is UEFI binary and can add it to the MOK database..
I have been told that mechanism to propagate they key in shim which is used to verify kernel signature is in place and that key should show up in
system_trusted_keyring. I have never verified it though. I will check it out.Thanks
VivekQuoted 8 lines
Quoted 5 lines
Hi Vivek,
The easiest way to get OS Vendor ker/certificate is just embed it into the kernel along with
ephemeral (or not) module signing key... They all appears on .system keyring...I think it will be tricky as in current setup, signing happens on a different server and build server does not have access to keys.
Quoted 8 lines
Apart from this, all the builds might not signed. And at build time it is might not known if a particular build will be signed with final keys or not. One might decide to sign kernel based on testing results post build. So embedding the kernel signing key in the kernel during build is little tricky from process point of view.
Thanks
Vivek
Please note, kernel signing key is not embedded to the kernel.. It is certificate/public key.
bootloader has embedded OS vendor certificate.
It is "well known" and public.
Distro might have multiple kernels installed and all of them must boot. Kernel updates will come signed with the same key...
So all kernels probably signed with the same distro private key or multiple public keys need to be embedded into the bootloader.
So kernel signing key is not ephemeral but managed and stored somewhere secretly.
There is no problem to distribute public key...
Signature · 2 lines
Thanks, Dmitry
PATCH 4/4 KEYS: validate key trust only with builtin keys
In reply to Dmitry KasatkinThis patch allows to specify kernel parameter 'keys_ownerid=builtin' to allow trust validation only using builtin keys.
--- crypto/asymmetric_keys/x509_public_key.c | 9 +++++++-- include/linux/key.h | 1 + kernel/system_keyring.c | 1 + 3 files changed, 9 insertions(+), 2 deletions(-)
crypto/asymmetric_keys/x509_public_key.c +7 -2
@@ -24,6 +24,7 @@#include "public_key.h" #include "x509_parser.h" +static bool builtin_keys;static char *owner_keyid;static int __init default_owner_keyid_set (char *str) {
@@ -32,6 +33,8 @@ static int __init default_owner_keyid_set(char *str)if (strncmp (str,"id:" ,3 ) ==0 ) owner_keyid = str;/* owner local key 'id:xxxxxx' */ +else if (strcmp (str,"builtin" ) ==0 ) + builtin_keys = true;return 1 ; }
@@ -197,8 +200,10 @@ static int x509_validate_trust(struct x509_certificate *cert, cert->authority, strlen(cert->authority));if (!IS_ERR (key)) { - pk = key->payload.data; - ret =x509_check_signature (pk, cert); +if (!builtin_keys ||test_bit (KEY_FLAG_BUILTIN , &key->flags)) { + pk = key->payload.data; + ret =x509_check_signature (pk, cert); + }key_put (key); }return ret;
include/linux/key.h +1 -0
@@ -170,6 +170,7 @@ struct key {#define KEY_FLAG_INVALIDATED 7/* set if key has been invalidated */ #define KEY_FLAG_TRUSTED 8/* set if key is trusted */ #define KEY_FLAG_TRUSTED_ONLY 9/* set if keyring only accepts links to trusted keys */ +#define KEY_FLAG_BUILTIN 10/* set if key is builtin */ /* the key type and key description string * - the desc is used to match a key against search criteria
kernel/system_keyring.c +1 -0
@@ -89,6 +89,7 @@ static __init int load_system_certificate_list(void)pr_err ("Problem loading in-kernel X.509 certificate (%ld)\n" ,PTR_ERR (key)); }else { +set_bit (KEY_FLAG_BUILTIN , &key_ref_to_ptr (key)->flags);pr_notice ("Loaded X.509 cert '%s'\n" ,key_ref_to_ptr (key)->description);key_ref_put (key);
Signature · 1 line
1.9.1
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
In reply to Dmitry KasatkinQuoted 20 lines · Dmitry Kasatkin
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative patches not requiring to have additional keyring.
First patch are irrelevant minor fixes.
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once
MODULE_SIG_UEFIis enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disablingMODULE_SIG_UEFI.
Quoted 1 line
Josh, why such design decision was made?
IIRC, it's because kernel parameters can be added programmatically from a remote user if they gain root access. Having a kernel parameter to disable a key piece of secure boot isn't all that great. We disable other kernel parameters like acpi_rspd as well.
Quoted 3 lines
Why not to provide kernel parameter to have more fine-tune control over the functionality? Unconfigured machines will not have MokIgnoreDb and will allow to load kernel modules signed with certain undesired keys. In fact,
Undesired by whom? If SB is enabled, your machine's firmware already trusts those keys.
Quoted 2 lines
I beleive, it should be default behavior of the kernel. Bootloader can enable UEFI functionality by specifing it on the kernel command line.
If it was enabled via boot params, or done in the early setup code that might be possible. I don't think a kernel parameter is the right solution though. I've added Matthew on CC.
josh
Quoted 30 lines
Second patch allows to overcome keys coming from UEFI for key validation by specifing owner key id and is an alternative for v5 4/4 patch.
It was also a good idea presented in Mimi's v4 4/4 patch to have possibility to limit key trust valiation by only builtin keys. Third patch as an alternative. It uses
keys->flagsto specify origin of the key, but any additional field could be added as well.Both key id and origin verification is done in
x509_validate_trust().Thanks,
DmitryDmitry Kasatkin (3):
KEYS: fix couple of things
KEYS: validate key trust only with selected owner key
KEYS: validate key trust only with builtin keysMimi Zohar (1):
KEYS: define an owner trusted keyringDocumentation/kernel-parameters.txt | 5 +++++ crypto/asymmetric_keys/x509_public_key.c | 35 +++++++++++++++++++++++++++++--- include/linux/key.h | 1 + kernel/system_keyring.c | 1 + 4 files changed, 39 insertions(+), 3 deletions(-)Signature · 1 line
1.9.1
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 15 lines · Josh Boyer
Quoted 13 lines · Dmitry Kasatkin
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once
MODULE_SIG_UEFIis enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disablingMODULE_SIG_UEFI.
Quoted 6 lines
Quoted 1 line
Josh, why such design decision was made?
IIRC, it's because kernel parameters can be added programmatically from a remote user if they gain root access. Having a kernel parameter to disable a key piece of secure boot isn't all that great. We disable other kernel parameters like
acpi_rspdas well.
In this case, there shouldn't be a problem as the kernel parameters would further limit the keys usage.
Mimi
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 16 lines · Mimi Zohar
Quoted 15 lines · Josh Boyer
Quoted 14 lines · Dmitry Kasatkin
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once
MODULE_SIG_UEFIis enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disablingMODULE_SIG_UEFI.Josh, why such design decision was made?
Quoted 8 lines
Quoted 4 lines
IIRC, it's because kernel parameters can be added programmatically from a remote user if they gain root access. Having a kernel parameter to disable a key piece of secure boot isn't all that great. We disable other kernel parameters like
acpi_rspdas well.In this case, there shouldn't be a problem as the kernel parameters would further limit the keys usage.
Mimi
Josh probably means that it can be removed and restriction is lifted.. And after reboot, all keys come to the keyring..
Quoted 1 line
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 21 lines · Dmitry Kasatkin
Quoted 20 lines · Mimi Zohar
Quoted 19 lines · Josh Boyer
Quoted 13 lines · Dmitry Kasatkin
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once
MODULE_SIG_UEFIis enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disablingMODULE_SIG_UEFI.Quoted 1 line
Josh, why such design decision was made?
IIRC, it's because kernel parameters can be added programmatically from a remote user if they gain root access. Having a kernel parameter to disable a key piece of secure boot isn't all that great. We disable other kernel parameters like
acpi_rspdas well.
Quoted 7 lines
Quoted 4 lines
In this case, there shouldn't be a problem as the kernel parameters would further limit the keys usage.
Mimi
Josh probably means that it can be removed and restriction is lifted.. And after reboot, all keys come to the keyring..
Right. Or if we went with your suggestion of the default being "do not load UEFI keys", then they could conversely add the parameter instead. This might not be an immediate threat to the SB attack vector itself (thought it could be if I thought about it harder), but it's certainly a change in system behavior that would catch a user unaware.
At any rate, I'm likely not the best person to weigh in on this aspect. Matthew has certainly done more thinking about these kinds of problems.
josh
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 27 lines · Josh Boyer
Quoted 26 lines · Dmitry Kasatkin
Quoted 24 lines · Mimi Zohar
Quoted 14 lines · Josh Boyer
Quoted 13 lines · Dmitry Kasatkin
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once
MODULE_SIG_UEFIis enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disablingMODULE_SIG_UEFI.Quoted 5 lines
Quoted 1 line
Josh, why such design decision was made?
IIRC, it's because kernel parameters can be added programmatically from a remote user if they gain root access. Having a kernel parameter to disable a key piece of secure boot isn't all that great. We disable other kernel parameters like
acpi_rspdas well.In this case, there shouldn't be a problem as the kernel parameters would further limit the keys usage.
Mimi
Quoted 8 lines
Quoted 2 lines
Josh probably means that it can be removed and restriction is lifted.. And after reboot, all keys come to the keyring..
Right. Or if we went with your suggestion of the default being "do not load UEFI keys", then they could conversely add the parameter instead. This might not be an immediate threat to the SB attack vector itself (thought it could be if I thought about it harder), but it's certainly a change in system behavior that would catch a user unaware.
Agreed, it could catch the user unaware of the change, but always allowing all the UEFI keys, is not a better alternative. Perhaps, requiring the option, would at least prevent the user from being unaware of the change.
Mimi
Quoted 4 lines
At any rate, I'm likely not the best person to weigh in on this aspect. Matthew has certainly done more thinking about these kinds of problems.
josh
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
In reply to Josh BoyerQuoted 21 lines · Josh Boyer
Quoted 20 lines · Dmitry Kasatkin
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative patches not requiring to have additional keyring.
First patch are irrelevant minor fixes.
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once
MODULE_SIG_UEFIis enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disablingMODULE_SIG_UEFI.
Quoted 5 lines
Quoted 1 line
Josh, why such design decision was made?
IIRC, it's because kernel parameters can be added programmatically from a remote user if they gain root access. Having a kernel parameter to disable a key piece of secure boot isn't all that great. We disable other kernel parameters like
acpi_rspdas well.
I see the point, as we have unprotected boot loader configuration.
Quoted 5 lines
Quoted 3 lines
Why not to provide kernel parameter to have more fine-tune control over the functionality? Unconfigured machines will not have MokIgnoreDb and will allow to load kernel modules signed with certain undesired keys. In fact,
Undesired by whom? If SB is enabled, your machine's firmware already trusts those keys.
It is tricky issue. But yes and no... If I forced to trust MS key to run SHIM, it does not mean
that I want to trust MS key to run kernel and load modules or use MS key to valid other keys on system keyring.
Personally I took ownership of my laptop laptop by enrolling my key. I also re-signed SHIM...
But for convenience I keep MS key to boot from any USB stick, though booting is password protected...
-> So the only point I trust MS key is when I type my password to boot...
And next when system is running, I do not want MS or Lenovo key would be used to verify kernel modules or signed files...
Quoted 5 lines
Quoted 2 lines
I beleive, it should be default behavior of the kernel. Bootloader can enable UEFI functionality by specifing it on the kernel command line.
If it was enabled via boot params, or done in the early setup code that might be possible. I don't think a kernel parameter is the right solution though. I've added Matthew on CC.
Thanks for reply.
Quoted 37 lines
josh
Quoted 18 lines
Second patch allows to overcome keys coming from UEFI for key validation by specifing owner key id and is an alternative for v5 4/4 patch.
It was also a good idea presented in Mimi's v4 4/4 patch to have possibility to limit key trust valiation by only builtin keys. Third patch as an alternative. It uses
keys->flagsto specify origin of the key, but any additional field could be added as well.Both key id and origin verification is done in
x509_validate_trust().Thanks,
DmitryDmitry Kasatkin (3):
KEYS: fix couple of things
KEYS: validate key trust only with selected owner key
KEYS: validate key trust only with builtin keysQuoted 12 lines
Mimi Zohar (1):
KEYS: define an owner trusted keyringDocumentation/kernel-parameters.txt | 5 +++++ crypto/asymmetric_keys/x509_public_key.c | 35 +++++++++++++++++++++++++++++--- include/linux/key.h | 1 + kernel/system_keyring.c | 1 + 4 files changed, 39 insertions(+), 3 deletions(-)Signature · 1 line
1.9.1--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 4 lines · Dmitry Kasatkin
It is tricky issue. But yes and no... If I forced to trust MS key to run SHIM, it does not mean
that I want to trust MS key to run kernel and load modules or use MS key to valid other keys on system keyring.
A kernel parameter that refuses to trust the contents of DB would be acceptable, but DBX needs to be used unconditionally.
Signature · 1 line
Matthew Garrett | [email protected]
Dmitry Kasatkin
maintainerRe: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
In reply to Josh BoyerQuoted 21 lines · Josh Boyer
Quoted 20 lines · Dmitry Kasatkin
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative patches not requiring to have additional keyring.
First patch are irrelevant minor fixes.
Also I want to discuss here Fedora UEFI patches as they are the reason for the these original patchset.
http://pkgs.fedoraproject.org/cgit/kernel.git/tree/modsign-uefi.patch
They provide functionality to specify MokIgnoreDb variable to limit loading of UEFI keys only from MOK List, while ignoring DB. This is certainly a good functionality. But once
MODULE_SIG_UEFIis enabled, it looks there is no way to prevent loading keys from UEFI at all. And this might not be a good default functionality. Someone might want not allow loading of keys from UEFI unless kernel parameter is specified to allow it without recompiling the kernel and disablingMODULE_SIG_UEFI.
Quoted 7 lines
Quoted 1 line
Josh, why such design decision was made?
IIRC, it's because kernel parameters can be added programmatically from a remote user if they gain root access. Having a kernel parameter to disable a key piece of secure boot isn't all that great. We disable other kernel parameters like
acpi_rspdas well.
(repost in plain text)
It just was in my mind. And Mathew uncovered it.
Parameter does not disable security....
Preventing loading keys from uefi except dbx by default actually improves security.
Adding kernel parameter to read db we make system more vulnerable.
So default should be to read dbx but not db.
Based on kernel parameter to read also db.
- Dmitry
Quoted 46 lines
Quoted 3 lines
Why not to provide kernel parameter to have more fine-tune control over the functionality? Unconfigured machines will not have MokIgnoreDb and will allow to load kernel modules signed with certain undesired keys. In fact,
Undesired by whom? If SB is enabled, your machine's firmware already trusts those keys.
Quoted 2 lines
I beleive, it should be default behavior of the kernel. Bootloader can enable UEFI functionality by specifing it on the kernel command line.
If it was enabled via boot params, or done in the early setup code that might be possible. I don't think a kernel parameter is the right solution though. I've added Matthew on CC.
josh
Quoted 30 lines
Second patch allows to overcome keys coming from UEFI for key validation by specifing owner key id and is an alternative for v5 4/4 patch.
It was also a good idea presented in Mimi's v4 4/4 patch to have possibility to limit key trust valiation by only builtin keys. Third patch as an alternative. It uses
keys->flagsto specify origin of the key, but any additional field could be added as well.Both key id and origin verification is done in
x509_validate_trust().Thanks,
DmitryDmitry Kasatkin (3):
KEYS: fix couple of things
KEYS: validate key trust only with selected owner key
KEYS: validate key trust only with builtin keysMimi Zohar (1):
KEYS: define an owner trusted keyringDocumentation/kernel-parameters.txt | 5 +++++ crypto/asymmetric_keys/x509_public_key.c | 35 +++++++++++++++++++++++++++++--- include/linux/key.h | 1 + kernel/system_keyring.c | 1 + 4 files changed, 39 insertions(+), 3 deletions(-)--
1.9.1
Signature · 2 lines
Thanks, Dmitry
A message that is not in the archive (sent off-list or not yet received): CACE9dm9Ff6b3J=05QfcgBv-c_y=5qGNq1-ZSfo4smtj34i1e-A@mail.gmail.com
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 3 lines · Dmitry Kasatkin
Preventing loading keys from uefi except dbx by default actually improves security. Adding kernel parameter to read db we make system more vulnerable.
It only adds security if you're performing a measured boot and remote attestation. Otherwise you implicitly trust that key anyway. In almost all cases refusing to trust db gives you a false sense of security without any real improvement. I don't think it's obvious it should be the default.
Signature · 1 line
Matthew Garrett | [email protected]
Dmitry Kasatkin
maintainerRe: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 6 lines · Matthew Garrett
Quoted 3 lines · Dmitry Kasatkin
Preventing loading keys from uefi except dbx by default actually improves security. Adding kernel parameter to read db we make system more vulnerable.
Quoted 8 lines
It only adds security if you're performing a measured boot and remote attestation. Otherwise you implicitly trust that key anyway. In almost all cases refusing to trust db gives you a false sense of security without any real improvement. I don't think it's obvious it should be the default.
--
Matthew Garrett | [email protected]
May be you are right... "in almost all cases"...
It does not mater if one trust DB or not... It's all about distro/system configuration...
Normal user even will not know what is default behavior and what kernel parameter disables or enables...
And distro will have it by default or will use kernel parameter... It does not change anything...
I am just discussing kernel configuration...
Without kind of looking to it I cannot be sure if UEFI keys will appear on system keyring or not.
Now I have to be aware how kernel is compiled... If it is compiled with CONFIG_KEYS_UEFI or so
I need to remember may be to supply addition kernel parameters to limit key UEFI usage...
It is may be not a big deal...
Signature · 2 lines
Thanks, Dmitry
Dmitry Kasatkin
maintainerRe: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 34 lines · Dmitry Kasatkin
Quoted 6 lines · Matthew Garrett
Quoted 3 lines · Dmitry Kasatkin
Preventing loading keys from uefi except dbx by default actually improves security. Adding kernel parameter to read db we make system more vulnerable.
Quoted 8 lines
It only adds security if you're performing a measured boot and remote attestation. Otherwise you implicitly trust that key anyway. In almost all cases refusing to trust db gives you a false sense of security without any real improvement. I don't think it's obvious it should be the default.
--
Matthew Garrett | [email protected]May be you are right... "in almost all cases"...
It does not mater if one trust DB or not... It's all about distro/system configuration...
Normal user even will not know what is default behavior and what kernel parameter disables or enables...
And distro will have it by default or will use kernel parameter... It does not change anything...I am just discussing kernel configuration...
Without kind of looking to it I cannot be sure if UEFI keys will appear on system keyring or not.
Now I have to be aware how kernel is compiled... If it is compiled withCONFIG_KEYS_UEFIor so
I need to remember may be to supply addition kernel parameters to limit key UEFI usage...
Quoted 5 lines
It is may be not a big deal...
--
Thanks,
Dmitry
It is probably just a paranoia...Kconfig MODULE_SIG_UEFI should tell about threat of loading kernel modules from NSA or Lenovo signed by MS or Lenovo keys..
This hole is opened without warning...
:)
Signature · 2 lines
Thanks, Dmitry
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 5 lines · Dmitry Kasatkin
It is probably just a paranoia...
KconfigMODULE_SIG_UEFIshould tell about threat of loading kernel modules from NSA or Lenovo signed by MS or Lenovo keys..This hole is opened without warning...
It's not typically a hole. If an attacker has root they can just replace your bootloader with one signed by a trusted key and then have that modify the kernel before booting it.
If you're using a TPM then you can mitigate this, but if you have a TPM then you're already performing some extra steps during the boot process. Just add a sysfs knob that lets you drop the db keys and incorporate that into the TPM management code.
Signature · 1 line
Matthew Garrett | [email protected]
Dmitry Kasatkin
maintainerRe: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 12 lines · Matthew Garrett
Quoted 5 lines · Dmitry Kasatkin
It is probably just a paranoia...
KconfigMODULE_SIG_UEFIshould tell about threat of loading kernel modules from NSA or Lenovo signed by MS or Lenovo keys..This hole is opened without warning...
It's not typically a hole. If an attacker has root they can just replace your bootloader with one signed by a trusted key and then have that modify the kernel before booting it.
Quoted 7 lines
If you're using a TPM then you can mitigate this, but if you have a TPM then you're already performing some extra steps during the boot process. Just add a sysfs knob that lets you drop the db keys and incorporate that into the TPM management code.
--
Matthew Garrett | [email protected]
I was expecting this boot loader answer.
Indeed, if system is design to prevent online modification of bootloader then kernel parameters are protected as well...
My statement is still valid. It is a hole...
To prevent the hole it should be explained that one might follow certain instructions
to take ownership of your PC. Generate your own keys and remove MS and Vendor ones...
It is paranoia? May be not.
- Dmitry
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 6 lines · Dmitry Kasatkin
My statement is still valid. It is a hole...
To prevent the hole it should be explained that one might follow certain instructions
to take ownership of your PC. Generate your own keys and remove MS and Vendor ones...
The hole is that the system trusts keys that you don't trust. The appropriate thing to do is to remove that trust from the entire system, not just one layer of the system. If people gain the impression that they can simply pass a kernel parameter and avoid trusting the vendor keys, they'll be upset to discover that it's easily circumvented.
Signature · 1 line
Matthew Garrett | [email protected]
Dmitry Kasatkin
maintainerRe: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 9 lines · Matthew Garrett
Quoted 6 lines · Dmitry Kasatkin
My statement is still valid. It is a hole...
To prevent the hole it should be explained that one might follow certain instructions
to take ownership of your PC. Generate your own keys and remove MS and Vendor ones...
Quoted 8 lines
The hole is that the system trusts keys that you don't trust. The appropriate thing to do is to remove that trust from the entire system, not just one layer of the system. If people gain the impression that they can simply pass a kernel parameter and avoid trusting the vendor keys, they'll be upset to discover that it's easily circumvented.
--
Matthew Garrett | [email protected]
Yes. There is no reason to trust anything except your own... Vendor keys, like Lenovo and OS keys like MS are not trusted.
They need to be completely replaced.
Probably we share the same view but talk about a bit different things..
- Dmitry
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
In reply to Matthew GarrettQuoted 9 lines · Matthew Garrett
Quoted 6 lines · Dmitry Kasatkin
My statement is still valid. It is a hole...
To prevent the hole it should be explained that one might follow certain instructions
to take ownership of your PC. Generate your own keys and remove MS and Vendor ones...
Quoted 5 lines
The hole is that the system trusts keys that you don't trust. The appropriate thing to do is to remove that trust from the entire system, not just one layer of the system. If people gain the impression that they can simply pass a kernel parameter and avoid trusting the vendor keys, they'll be upset to discover that it's easily circumvented.
Assuming I remove all the keys I don't trust, there are still keys that are trusted while booting, but are not necessary afterwards. We should be able to limit the scope of where and when keys are trusted.
Mimi
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 10 lines · Mimi Zohar
Quoted 5 lines · Matthew Garrett
The hole is that the system trusts keys that you don't trust. The appropriate thing to do is to remove that trust from the entire system, not just one layer of the system. If people gain the impression that they can simply pass a kernel parameter and avoid trusting the vendor keys, they'll be upset to discover that it's easily circumvented.
Assuming I remove all the keys I don't trust, there are still keys that are trusted while booting, but are not necessary afterwards. We should be able to limit the scope of where and when keys are trusted.
Providing a userspace mechanism for selectively dropping keys from the kernel seems like a good thing?
Signature · 1 line
Matthew Garrett | [email protected]
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 8 lines · Matthew Garrett
Quoted 7 lines · Mimi Zohar
Quoted 5 lines · Matthew Garrett
The hole is that the system trusts keys that you don't trust. The appropriate thing to do is to remove that trust from the entire system, not just one layer of the system. If people gain the impression that they can simply pass a kernel parameter and avoid trusting the vendor keys, they'll be upset to discover that it's easily circumvented.
Quoted 6 lines
Quoted 3 lines
Assuming I remove all the keys I don't trust, there are still keys that are trusted while booting, but are not necessary afterwards. We should be able to limit the scope of where and when keys are trusted.
Providing a userspace mechanism for selectively dropping keys from the kernel seems like a good thing?
No, patch "KEYS: verify a certificate is signed by a 'trusted' key" adds signed public keys.
Mimi
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 6 lines · Mimi Zohar
Quoted 2 lines · Matthew Garrett
Providing a userspace mechanism for selectively dropping keys from the kernel seems like a good thing?
No, patch "KEYS: verify a certificate is signed by a 'trusted' key" adds signed public keys.
Yes. Wouldn't having a mechanism to allow userspace to drop keys that have otherwise been imported be a generally useful solution to the issue you have with that?
Signature · 1 line
Matthew Garrett | [email protected]
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 3 lines · Matthew Garrett
Yes. Wouldn't having a mechanism to allow userspace to drop keys that have otherwise been imported be a generally useful solution to the issue you have with that?
There are issues removing a key from both the local system(eg. cache, running apps) and the attestation server (eg. ima-sig template verification) perspectives. We would need to address these concerns before supporting key removal.
Mimi
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 9 lines · Mimi Zohar
Quoted 3 lines · Matthew Garrett
Yes. Wouldn't having a mechanism to allow userspace to drop keys that have otherwise been imported be a generally useful solution to the issue you have with that?
There are issues removing a key from both the local system(eg. cache, running apps) and the attestation server (eg. ima-sig template verification) perspectives. We would need to address these concerns before supporting key removal.
For your use-case you'd want to do this before running any significant quantity of userspace. The firmware keys are going to be hashed into PCR 7, so they're already part of your attestation.
Signature · 1 line
Matthew Garrett | [email protected]
David Howells
maintainerRe: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
In reply to Matthew GarrettQuoted 3 lines · Matthew Garrett
Yes. Wouldn't having a mechanism to allow userspace to drop keys that have otherwise been imported be a generally useful solution to the issue you have with that?
"keyctl invalidate" could be a way to drop keys.
David
Dmitry Kasatkin
maintainerRe: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
In reply to Dmitry KasatkinQuoted 28 lines · Dmitry Kasatkin
Quoted 12 lines · Matthew Garrett
Quoted 5 lines · Dmitry Kasatkin
It is probably just a paranoia...
KconfigMODULE_SIG_UEFIshould tell about threat of loading kernel modules from NSA or Lenovo signed by MS or Lenovo keys..This hole is opened without warning...
It's not typically a hole. If an attacker has root they can just replace your bootloader with one signed by a trusted key and then have that modify the kernel before booting it.
Quoted 7 lines
If you're using a TPM then you can mitigate this, but if you have a TPM then you're already performing some extra steps during the boot process. Just add a sysfs knob that lets you drop the db keys and incorporate that into the TPM management code.
--
Matthew Garrett | [email protected]I was expecting this boot loader answer.
Indeed, if system is design to prevent online modification of bootloader then kernel parameters are protected as well...
My statement is still valid. It is a hole...
Quoted 8 lines
To prevent the hole it should be explained that one might follow certain instructions
to take ownership of your PC. Generate your own keys and remove MS and Vendor ones...It is paranoia? May be not.
- Dmitry
I must admit that bootloader replacement is not related to kernel...
It is just paranoia...
- dmitry
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
In reply to Dmitry KasatkinQuoted 4 lines · Dmitry Kasatkin
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative patches not requiring to have additional keyring.
Please indicate which branch these patches apply to.
thanks,
Mimi
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 12 lines · Mimi Zohar
Quoted 4 lines · Dmitry Kasatkin
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative patches not requiring to have additional keyring.
Please indicate which branch these patches apply to.
thanks,
Mimi
on the top of your tree #next-trusted-keys-experimental, excluding 1/4 patch, which is yours.
I included it by mistake because patches were on the top of that and I used HEAD~3 instead of HEAD~2 to send them...
- Dmitry
Re: [PATCH 0/4] KEYS: validate key trust with owner and builtin keys only
Quoted 10 lines · Dmitry Kasatkin
Quoted 9 lines · Mimi Zohar
Quoted 4 lines · Dmitry Kasatkin
Hi Mimi,
As you asked ofline , here is possible equivalent and simpler alternative patches not requiring to have additional keyring.
Please indicate which branch these patches apply to.
thanks,
Quoted 8 lines
Quoted 3 lines
Mimi
on the top of your tree #next-trusted-keys-experimental, excluding 1/4 patch, which is yours.
I included it by mistake because patches were on the top of that and I used HEAD~3 instead of HEAD~2 to send them...
This patch set removes the separate 'owner' trusted keyring. Please rebase your patches without the HEAD patch - "f5b4ced KEYS: define an owner trusted keyring" and re-post.
thanks,
Mimi