Skip to content

L
linux
Switch branch/tag
  1. 08 Jan, 2016 11 commits
    • David Howells's avatar
      KEYS: Remove KEY_FLAG_TRUSTED · 40482bb4
      David Howells authored 
      Remove KEY_FLAG_TRUSTED as it's no longer meaningful.

Given this, we no longer need to pass the key flags through to
restrict_link().

Further, we can now get rid of keyring_restrict_trusted_only() also.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      40482bb4
    • David Howells's avatar
      KEYS: Move the point of trust determination to __key_link() · cbf44a8c
      David Howells authored 
      Move the point at which a key is determined to be trustworthy to
__key_link() so that we use the contents of the keyring being linked in to
to determine whether the key being linked in is trusted or not.

What is 'trusted' then becomes a matter of what's in the keyring.

Currently, the test is done when the key is parsed, but given that at that
point we can only sensibly refer to the contents of the system trusted
keyring, we can only use that as the basis for working out the
trustworthiness of a new key.

With this change, a trusted keyring is a set of keys that once the
trusted-only flag is set cannot be added to except by verification through
one of the contained keys.

Further, adding a key into a trusted keyring, whilst it might grant
trustworthiness in the context of that keyring, does not automatically
grant trustworthiness in the context of a second keyring to which it could
be secondarily linked.

To accomplish this, the authentication data associated with the key source
must now be retained.  For an X.509 cert, this means the contents of the
AuthorityKeyIdentifier and the signature data.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cbf44a8c
    • David Howells's avatar
      KEYS: Generalise x509_request_asymmetric_key() · 340cd3a2
      David Howells authored 
      Generalise x509_request_asymmetric_key().  It doesn't really have any
dependencies on X.509 features as it uses generalised IDs and the
public_key structs that contain data extracted from X.509.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      340cd3a2
    • David Howells's avatar
      X.509: Move the trust validation code out to its own file · 4a54d9d3
      David Howells authored 
      Move the X.509 trust validation code out to its own file so that it can be
generalised.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      4a54d9d3
    • David Howells's avatar
      PKCS#7: Make the signature a pointer rather than embedding it · ed732bfe
      David Howells authored 
      Point to the public_key_signature struct from the pkcs7_signed_info struct
rather than embedding it.  This makes it easier to have it take an
arbitrary number of MPIs in future.

We also save a copy of the digest in the signature without sharing the
memory with the crypto layer metadata.  This means we can use
public_key_free() to get rid of the signature record.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      ed732bfe
    • David Howells's avatar
      X.509: Extract signature digest and make self-signed cert checks earlier · b5cd0dcf
      David Howells authored 
      Extract the signature digest for an X.509 certificate earlier, at the end
of x509_cert_parse() rather than leaving it to the callers thereof.

Further, immediately after that, check the signature on self-signed
certificates, also rather in the callers of x509_cert_parse().

This we need to determine whether or not the X.509 cert requires crypto
that we don't support before we do the above two steps.

We note in the x509_certificate struct the following bits of information:

 (1) Whether the signature is self-signed (even if we can't check the
     signature due to missing crypto).

 (2) Whether the key held in the certificate needs unsupported crypto to be
     used.  We may get a PKCS#7 message with X.509 certs that we can't make
     use of - we just ignore them and give ENOPKG at the end it we couldn't
     verify anything if at least one of these unusable certs are in the
     chain of trust.

 (3) Whether the signature held in the certificate needs unsupported crypto
     to be checked.  We can still use the key held in this certificate,
     even if we can't check the signature on it - if it is held in the
     system trusted keyring, for instance.  We just can't add it to a ring
     of trusted keys or follow it further up the chain of trust.

Making these checks earlier allows x509_check_signature() to be removed and
replaced with direct calls to public_key_verify_signature().
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b5cd0dcf
    • David Howells's avatar
      X.509: Retain the key verification data · 55390f38
      David Howells authored 
      Retain the key verification data (ie. the struct public_key_signature)
including the digest and the key identifiers.

Note that this means that we need to take a separate copy of the digest in
x509_get_sig_params() rather than lumping it in with the crypto layer data.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      55390f38
    • David Howells's avatar
      KEYS: Add identifier pointers to public_key_signature struct · ff07c803
      David Howells authored 
      Add key identifier pointers to public_key_signature struct so that they can
be used to retain the identifier of the key to be used to verify the
signature in both PKCS#7 and X.509.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      ff07c803
    • David Howells's avatar
      KEYS: Allow authentication data to be stored in an asymmetric key · 9fb4c491
      David Howells authored 
      Allow authentication data to be stored in an asymmetric key in the 4th
element of the key payload and provide a way for it to be destroyed.

For the public key subtype, this will be a public_key_signature struct.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      9fb4c491
    • David Howells's avatar
      KEYS: Add a facility to restrict new links into a keyring · 5417b29d
      David Howells authored 
      Add a facility whereby proposed new links to be added to a keyring can be
vetted, permitting them to be rejected if necessary.  This can be used to
block public keys from which the signature cannot be verified or for which
the signature verification fails.  It could also be used to provide
blacklisting.

This affects operations like add_key(), KEYCTL_LINK and KEYCTL_INSTANTIATE.

To this end:

 (1) A function pointer is added to the key struct that, if set, points to
     the vetting function.  This is called as:

	int (*restrict_link)(struct key *keyring,
			     const struct key_type *key_type,
			     unsigned long key_flags,
			     const union key_payload *key_payload),

     where 'keyring' will be the keyring being added to, key_type and
     key_payload will describe the key being added and key_flags[*] can be
     AND'ed with KEY_FLAG_TRUSTED.

     [*] This parameter will be removed in a later patch when
     	 KEY_FLAG_TRUSTED is removed.

     The function should return 0 to allow the link to take place or an
     error (typically -ENOKEY, -ENOPKG or -EKEYREJECTED) to reject the
     link.

     The pointer should not be set directly, but rather should be set
     through keyring_alloc().

     Note that if called during add_key(), preparse is called before this
     method, but a key isn't actually allocated until after this function
     is called.

 (2) KEY_ALLOC_BYPASS_RESTRICTION is added.  This can be passed to
     key_create_or_update() or key_instantiate_and_link() to bypass the
     restriction check.

 (3) KEY_FLAG_TRUSTED_ONLY is removed.  The entire contents of a keyring
     with this restriction emplaced can be considered 'trustworthy' by
     virtue of being in the keyring when that keyring is consulted.

 (4) key_alloc() and keyring_alloc() take an extra argument that will be
     used to set restrict_link in the new key.  This ensures that the
     pointer is set before the key is published, thus preventing a window
     of unrestrictedness.  Normally this argument will be NULL.

 (5) As a temporary affair, keyring_restrict_trusted_only() is added.  It
     should be passed to keyring_alloc() as the extra argument instead of
     setting KEY_FLAG_TRUSTED_ONLY on a keyring.  This will be replaced in
     a later patch with functions that look in the appropriate places for
     authoritative keys.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      5417b29d
    • David Howells's avatar
      KEYS: Add an alloc flag to convey the builtinness of a key · 05919216
      David Howells authored 
      Add KEY_ALLOC_BUILT_IN to convey that a key should have KEY_FLAG_BUILTIN
set rather than setting it after the fact.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      05919216
  3. 07 Jan, 2016 3 commits
    • David Howells's avatar
      PKCS#7: Make trust determination dependent on contents of trust keyring · f917093e
      David Howells authored 
      Make the determination of the trustworthiness of a key dependent on whether
a key that can verify it is present in the ring of trusted keys rather than
whether or not the verifying key has KEY_FLAG_TRUSTED set.

verify_pkcs7_signature() will return -ENOKEY if the PKCS#7 message trust
chain cannot be verified.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      f917093e
    • David Howells's avatar
      KEYS: Generalise system_verify_data() to provide access to internal content · 2f576f9a
      David Howells authored 
      Generalise system_verify_data() to provide access to internal content
through a callback.  This allows all the PKCS#7 stuff to be hidden inside
this function and removed from the PE file parser and the PKCS#7 test key.

If external content is not required, NULL should be passed as data to the
function.  If the callback is not required, that can be set to NULL.

The function is now called verify_pkcs7_signature() to contrast with
verify_pefile_signature() and the definitions of both have been moved into
linux/verification.h along with the key_being_used_for enum.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      2f576f9a
    • David Howells's avatar
      X.509: Don't treat self-signed keys specially · adbb7787
      David Howells authored 
      Trust for a self-signed certificate can normally only be determined by
whether we obtained it from a trusted location (ie. it was built into the
kernel at compile time), so there's not really any point in checking it -
we could verify that the signature is valid, but it doesn't really tell us
anything if the signature checks out.

However, there's a bug in the code determining whether a certificate is
self-signed or not - if they have neither AKID nor SKID then we just assume
that the cert is self-signed, which may not be true.

Given this, remove the code that treats self-signed certs specially when it
comes to evaluating trustability and attempt to evaluate them as ordinary
signed certificates.  We then expect self-signed certificates to fail the
trustability check and be marked as untrustworthy in x509_key_preparse().

Note that there is the possibility of the trustability check on a
self-signed cert then succeeding.  This is most likely to happen when a
duplicate of the certificate is already on the trust keyring - in which
case it shouldn't be a problem.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
cc: David Woodhouse <David.Woodhouse@intel.com>
cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      adbb7787
  5. 06 Jan, 2016 1 commit
    • David Howells's avatar
      X.509: Partially revert patch to add validation against IMA MOK keyring · aa9eeca6
      David Howells authored 
      Partially revert commit 41c89b64:

	Author: Petko Manolov <petkan@mip-labs.com>
	Date:   Wed Dec 2 17:47:55 2015 +0200
	IMA: create machine owner and blacklist keyrings
 
The problem is that prep->trusted is a simple boolean and the additional
x509_validate_trust() call doesn't therefore distinguish levels of
trustedness, but is just OR'd with the result of validation against the
system trusted keyring.

However, setting the trusted flag means that this key may be added to *any*
trusted-only keyring - including the system trusted keyring.

Whilst I appreciate what the patch is trying to do, I don't think this is
quite the right solution.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
cc: Petko Manolov <petkan@mip-labs.com>
cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
cc: keyrings@vger.kernel.org
      aa9eeca6
  7. 26 Dec, 2015 3 commits
  9. 24 Dec, 2015 10 commits
  11. 20 Dec, 2015 10 commits
  13. 17 Dec, 2015 1 commit
  15. 15 Dec, 2015 1 commit
    • Paul Gortmaker's avatar
      security/integrity: make ima/ima_mok.c explicitly non-modular · 92cc9166
      Paul Gortmaker authored 
      The Kconfig currently controlling compilation of this code is:

ima/Kconfig:config IMA_MOK_KEYRING
ima/Kconfig: bool "Create IMA machine owner keys (MOK) and blacklist keyrings"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple of traces of modularity so that when reading the
driver there is no doubt it really is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-ima-devel@lists.sourceforge.net
Cc: linux-ima-user@lists.sourceforge.net
Cc: linux-security-module@vger.kernel.org
Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      92cc9166
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7