Skip to content

L
linux
Switch branch/tag
  1. 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
  3. 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
  5. 26 Dec, 2015 3 commits
  7. 24 Dec, 2015 10 commits
  9. 20 Dec, 2015 10 commits
  11. 17 Dec, 2015 1 commit
  13. 15 Dec, 2015 12 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7