| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20160120172401.GF9900@localhost> Date: Wed, 20 Jan 2016 19:24:01 +0200 From: Petko Manolov <petkan@...-labs.com> To: David Howells <dhowells@...hat.com> Cc: zohar@...ux.vnet.ibm.com, linux-security-module@...r.kernel.org, keyrings@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH 00/20] KEYS: Restrict additions to 'trusted' keyrings [ver #2] I assume this is intended for 4.6 or later, correct? Petko On 16-01-19 11:30:26, David Howells wrote: > > Here's a set of patches that changes how certificates/keys are determined > to be trusted. That's currently a two-step process: > > (1) Up until recently, when an X.509 certificate was parsed - no matter > the source - it was judged against the keys in .system_keyring, > assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set > upon them. > > This has just been changed such that any key in the .ima_mok keyring > may also be used to judge the trustwortiness of a new certificate, > whether or not the .ima_mok keyring is meant to be consulted for > whatever process is being undertaken. > > If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED > will be set upon a key it is loaded into (if it is loaded into one), > no matter what the key is going to be loaded for. > > (2) If an X.509 certificate is loaded into a key, then that key - if > KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring > with KEY_FLAG_TRUSTED_ONLY set upon it. This was meant to be the > system keyring only, but has been extended to various IMA keyrings. > > A user can at will link any key marked KEY_FLAG_TRUSTED into any > keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks > permit it. > > These patches change that: > > (1) Trust becomes a matter of consulting the ring of trusted keys supplied > when the trust is evaluated only. > > (2) Asymmetric keys retain the source certificate signature information > for future evaluation rather than discarding it. > > (3) Every keyring can be supplied with its own manager function to > restrict what may be added to that keyring. This is called whenever a > key is to be linked into the keyring to guard against a key being > created in one keyring and then linked across. > > This function is supplied with the keyring and the key type and > payload[*] of the key being linked in for use in its evaluation. It > is permitted to use other data also, such as the contents of other > keyrings such as the system keyrings. > > [*] The type and payload are supplied instead of a key because as an > optimisation this function may be called whilst creating a key and > so may reject the proposed key between preparse and allocation. > > (4) A default manager function is provided that permits keys to be > restricted to only asymmetric keys that are vouched for by the > contents of the system keyring. > > (5) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available > so that the kernel can initialise keyrings with keys that form the > root of the trust relationship. > > (6) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with > key_preparsed_payload::trusted. > > This change also makes it possible for userspace to create a private set of > trusted keys and then to seal it by setting a manager function where the > private set is wholly independent of the kernel's trust relationships. > > Further changes in the set involve extracting certain IMA special keyrings > and making them generally global: > > (*) .system_keyring is renamed to .builtin_trusted_keys and remains read > only. It carries only keys built in to the kernel. It may be where > UEFI keys should be loaded - though that could better be the new > secondary keyring (see below). > > (*) An optional system blacklist keyring is created to replace the IMA > keyring. > > (*) A 'blacklist' key type is created that may contain a hex string in > its description (it carries no payload). When an X.509 > certificate is parsed, the system blacklist is searched for a > blacklist key that matches the TBS hash of the X.509 certificate > and if one is found, the certificate is considered blacklisted. > > (*) A list of blacklisted hashes can be added to the system blacklist > keyring at compile time. In the future it should also be possible > to load this up from such as the UEFI blacklist. > > (*) Keys can be added to the blacklist keyring by root if the keys are > signed by a key in the builtin system keyring. These can then be > searched for by asymmetric key ID. This allows the functionality > of the IMA blacklist keyring to be replicated. > > It might be worth making an asymmetric key subtype that carries no > data to be used here as the cryptographic material is then just > dead weight since the IDs are what matter. > > (*) An optional secondary system keyring (called .secondary_trusted_keys) > is added to replace the IMA MOK keyring. > > (*) Keys can be added to the secondary keyring by root if the keys can > be vouched for by either ring of system keys. > > (*) Module signing and kexec only use .builtin_trusted_keys and do not use > the new secondary keyring, but they do consult the system blacklist. > > (*) If the kernel sees a PKCS#7 message with more than one signature, at > least one of which is blacklisted, it will permit the message if at > least one of the non-blacklisted signature chains is vouched for. If > none are, then EKEYREJECTED will be given. This error takes priority > over giving ENOPKG for unsupported encryption. > > The patches can be found here also: > > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-trust > > David > --- > David Howells (20): > KEYS: Add an alloc flag to convey the builtinness of a key > KEYS: Add a system blacklist keyring > X.509: Allow X.509 certs to be blacklisted > X.509: Don't treat self-signed keys specially > KEYS: Generalise system_verify_data() to provide access to internal content > PKCS#7: Make trust determination dependent on contents of trust keyring > KEYS: Add a facility to restrict new links into a keyring > KEYS: Allow authentication data to be stored in an asymmetric key > KEYS: Add identifier pointers to public_key_signature struct > X.509: Retain the key verification data > X.509: Extract signature digest and make self-signed cert checks earlier > PKCS#7: Make the signature a pointer rather than embedding it > X.509: Move the trust validation code out to its own file > KEYS: Generalise x509_request_asymmetric_key() > KEYS: Move the point of trust determination to __key_link() > KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED > PKCS#7: Handle blacklisted certificates > IMA: Use the system blacklist keyring > certs: Add a secondary system keyring that can be added to dynamically > IMA: Replace the .ima_mok keyring with the secondary system keyring > > > Documentation/security/keys.txt | 14 + > arch/x86/kernel/kexec-bzimage64.c | 18 -- > certs/Kconfig | 26 ++ > certs/Makefile | 6 + > certs/blacklist.c | 184 +++++++++++++++++ > certs/blacklist.h | 3 > certs/blacklist_hashes.c | 6 + > certs/blacklist_nohashes.c | 5 > certs/system_keyring.c | 141 ++++++++++--- > crypto/asymmetric_keys/Kconfig | 1 > crypto/asymmetric_keys/Makefile | 2 > crypto/asymmetric_keys/asymmetric_keys.h | 2 > crypto/asymmetric_keys/asymmetric_type.c | 7 - > crypto/asymmetric_keys/mscode_parser.c | 21 +- > crypto/asymmetric_keys/pkcs7_key_type.c | 66 +++--- > crypto/asymmetric_keys/pkcs7_parser.c | 59 +++-- > crypto/asymmetric_keys/pkcs7_parser.h | 12 - > crypto/asymmetric_keys/pkcs7_trust.c | 44 ++-- > crypto/asymmetric_keys/pkcs7_verify.c | 141 ++++++------- > crypto/asymmetric_keys/public_key.c | 24 ++ > crypto/asymmetric_keys/public_key.h | 6 + > crypto/asymmetric_keys/public_key_trust.c | 209 +++++++++++++++++++ > crypto/asymmetric_keys/verify_pefile.c | 40 +--- > crypto/asymmetric_keys/verify_pefile.h | 5 > crypto/asymmetric_keys/x509_cert_parser.c | 51 +++-- > crypto/asymmetric_keys/x509_parser.h | 13 + > crypto/asymmetric_keys/x509_public_key.c | 318 +++++++++-------------------- > fs/cifs/cifsacl.c | 2 > fs/nfs/nfs4idmap.c | 2 > include/crypto/pkcs7.h | 6 - > include/crypto/public_key.h | 35 +-- > include/keys/asymmetric-subtype.h | 2 > include/keys/asymmetric-type.h | 8 - > include/keys/system_keyring.h | 52 ++--- > include/linux/key-type.h | 1 > include/linux/key.h | 39 +++- > include/linux/verification.h | 49 ++++ > include/linux/verify_pefile.h | 22 -- > kernel/module_signing.c | 7 - > net/dns_resolver/dns_key.c | 2 > net/rxrpc/ar-key.c | 4 > security/integrity/digsig.c | 10 + > security/integrity/digsig_asymmetric.c | 18 +- > security/integrity/ima/Kconfig | 18 -- > security/integrity/ima/Makefile | 1 > security/integrity/ima/ima_mok.c | 55 ----- > security/keys/key.c | 44 +++- > security/keys/keyring.c | 26 ++ > security/keys/persistent.c | 4 > security/keys/process_keys.c | 16 + > security/keys/request_key.c | 4 > security/keys/request_key_auth.c | 2 > 52 files changed, 1131 insertions(+), 722 deletions(-) > create mode 100644 certs/blacklist.c > create mode 100644 certs/blacklist.h > create mode 100644 certs/blacklist_hashes.c > create mode 100644 certs/blacklist_nohashes.c > create mode 100644 crypto/asymmetric_keys/public_key_trust.c > create mode 100644 include/linux/verification.h > delete mode 100644 include/linux/verify_pefile.h > delete mode 100644 security/integrity/ima/ima_mok.c > > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists