1. 08 Dec, 2017 2 commits
  2. 15 Nov, 2017 1 commit
  3. 03 Apr, 2017 1 commit
    • David Howells's avatar
      X.509: Allow X.509 certs to be blacklisted · 43652956
      David Howells authored
      Allow X.509 certs to be blacklisted based on their TBSCertificate hash.
      This is convenient since we have to determine this anyway to be able to
      check the signature on an X.509 certificate.  This is also what UEFI uses
      in its blacklist.
      
      If a certificate built into the kernel is blacklisted, something like the
      following might then be seen during boot:
      
      	X.509: Cert 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46 is blacklisted
      	Problem loading in-kernel X.509 certificate (-129)
      
      where the hex string shown is the blacklisted hash.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      43652956
  4. 11 Apr, 2016 5 commits
    • David Howells's avatar
      KEYS: Move the point of trust determination to __key_link() · a511e1af
      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.
      
      
      If system keyrings are disabled then restrict_link_by_builtin_trusted()
      resolves to restrict_link_reject().  The integrity digital signature code
      still works correctly with this as it was previously using
      KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there
      is no system keyring against which trust can be determined.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      a511e1af
    • David Howells's avatar
      X.509: Move the trust validation code out to its own file · cfb664ff
      David Howells authored
      Move the X.509 trust validation code out to its own file so that it can be
      generalised.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      cfb664ff
    • David Howells's avatar
      X.509: Use verify_signature() if we have a struct key * to use · 5f7f5c81
      David Howells authored
      We should call verify_signature() rather than directly calling
      public_key_verify_signature() if we have a struct key to use as we
      shouldn't be poking around in the private data of the key struct as that's
      subtype dependent.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      5f7f5c81
    • David Howells's avatar
      KEYS: Generalise x509_request_asymmetric_key() · 9eb02989
      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: 's avatarDavid Howells <dhowells@redhat.com>
      9eb02989
    • David Howells's avatar
      KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c · 983023f2
      David Howells authored
      Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
      generalised.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      983023f2
  5. 06 Apr, 2016 4 commits
    • David Howells's avatar
      X.509: Fix self-signed determination · ad3043fd
      David Howells authored
      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.
      
      Fix this by checking that the raw subject name matches the raw issuer name
      and that the public key algorithm for the key and signature are both the
      same in addition to requiring that the AKID bits match.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      ad3043fd
    • David Howells's avatar
      X.509: Extract signature digest and make self-signed cert checks earlier · 6c2dc5ae
      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 since it
      has to be called anyway.
      
      Further, immediately after that, check the signature on self-signed
      certificates, also rather in the callers of x509_cert_parse().
      
      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: 's avatarDavid Howells <dhowells@redhat.com>
      6c2dc5ae
    • David Howells's avatar
      X.509: Retain the key verification data · 77d0910d
      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: 's avatarDavid Howells <dhowells@redhat.com>
      77d0910d
    • David Howells's avatar
      X.509: Whitespace cleanup · 864e7a81
      David Howells authored
      Clean up some whitespace.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      864e7a81
  6. 03 Mar, 2016 1 commit
  7. 10 Feb, 2016 1 commit
  8. 09 Feb, 2016 1 commit
  9. 06 Feb, 2016 1 commit
  10. 15 Dec, 2015 1 commit
    • Petko Manolov's avatar
      IMA: create machine owner and blacklist keyrings · 41c89b64
      Petko Manolov authored
      This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
      intermediate keyring that sits between .system and .ima keyrings,
      effectively forming a simple CA hierarchy.  To successfully import a key
      into .ima_mok it must be signed by a key which CA is in .system keyring.
      On turn any key that needs to go in .ima keyring must be signed by CA in
      either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.
      
      IMA blacklist keyring contains all revoked IMA keys.  It is consulted
      before any other keyring.  If the search is successful the requested
      operation is rejected and error is returned to the caller.
      Signed-off-by: 's avatarPetko Manolov <petkan@mip-labs.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      41c89b64
  11. 21 Oct, 2015 1 commit
    • David Howells's avatar
      KEYS: Merge the type-specific data with the payload data · 146aa8b1
      David Howells authored
      Merge the type-specific data with the payload data into one four-word chunk
      as it seems pointless to keep them separate.
      
      Use user_key_payload() for accessing the payloads of overloaded
      user-defined keys.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      cc: linux-cifs@vger.kernel.org
      cc: ecryptfs@vger.kernel.org
      cc: linux-ext4@vger.kernel.org
      cc: linux-f2fs-devel@lists.sourceforge.net
      cc: linux-nfs@vger.kernel.org
      cc: ceph-devel@vger.kernel.org
      cc: linux-ima-devel@lists.sourceforge.net
      146aa8b1
  12. 20 Oct, 2015 1 commit
  13. 25 Sep, 2015 1 commit
    • David Howells's avatar
      X.509: Don't strip leading 00's from key ID when constructing key description · e7c87bef
      David Howells authored
      Don't strip leading zeros from the crypto key ID when using it to construct
      the struct key description as the signature in kernels up to and including
      4.2 matched this aspect of the key.  This means that 1 in 256 keys won't
      actually match if their key ID begins with 00.
      
      The key ID is stored in the module signature as binary and so must be
      converted to text in order to invoke request_key() - but it isn't stripped
      at this point.
      
      Something like this is likely to be observed in dmesg when the key is loaded:
      
      [    1.572423] Loaded X.509 cert 'Build time autogenerated kernel
          key: 62a7c3d2da278be024da4af8652c071f3fea33'
      
      followed by this when we try and use it:
      
        [    1.646153] Request for unknown module key 'Build time autogenerated
          kernel key: 0062a7c3d2da278be024da4af8652c071f3fea33' err -11
      
      The 'Loaded' line should show an extra '00' on the front of the hex string.
      
      This problem should not affect 4.3-rc1 and onwards because there the key
      should be matched on one of its auxiliary identities rather than the key
      struct's description string.
      Reported-by: 's avatarArjan van de Ven <arjan@linux.intel.com>
      Reported-by: 's avatarAndy Whitcroft <apw@canonical.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      e7c87bef
  14. 12 Aug, 2015 1 commit
  15. 07 Aug, 2015 2 commits
  16. 21 May, 2015 1 commit
    • Mimi Zohar's avatar
      KEYS: fix "ca_keys=" partial key matching · f2b3dee4
      Mimi Zohar authored
      The call to asymmetric_key_hex_to_key_id() from ca_keys_setup()
      silently fails with -ENOMEM.  Instead of dynamically allocating
      memory from a __setup function, this patch defines a variable
      and calls __asymmetric_key_hex_to_key_id(), a new helper function,
      directly.
      
      This bug was introduced by 'commit 46963b77 ("KEYS: Overhaul
      key identification when searching for asymmetric keys")'.
      
      Changelog:
      - for clarification, rename hexlen to asciihexlen in
        asymmetric_key_hex_to_key_id()
      - add size argument to __asymmetric_key_hex_to_key_id() - David Howells
      - inline __asymmetric_key_hex_to_key_id() - David Howells
      - remove duplicate strlen() calls
      Acked-by: 's avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org # 3.18
      f2b3dee4
  17. 06 Oct, 2014 2 commits
  18. 03 Oct, 2014 1 commit
  19. 16 Sep, 2014 2 commits
    • David Howells's avatar
      PKCS#7: Better handling of unsupported crypto · 41559420
      David Howells authored
      Provide better handling of unsupported crypto when verifying a PKCS#7 message.
      If we can't bridge the gap between a pair of X.509 certs or between a signed
      info block and an X.509 cert because it involves some crypto we don't support,
      that's not necessarily the end of the world as there may be other ways points
      at which we can intersect with a ring of trusted keys.
      
      Instead, only produce ENOPKG immediately if all the signed info blocks in a
      PKCS#7 message require unsupported crypto to bridge to the first X.509 cert.
      Otherwise, we defer the generation of ENOPKG until we get ENOKEY during trust
      validation.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Acked-by: 's avatarVivek Goyal <vgoyal@redhat.com>
      41559420
    • David Howells's avatar
      KEYS: Overhaul key identification when searching for asymmetric keys · 46963b77
      David Howells authored
      Make use of the new match string preparsing to overhaul key identification
      when searching for asymmetric keys.  The following changes are made:
      
       (1) Use the previously created asymmetric_key_id struct to hold the following
           key IDs derived from the X.509 certificate or PKCS#7 message:
      
      	id: serial number + issuer
      	skid: subjKeyId + subject
      	authority: authKeyId + issuer
      
       (2) Replace the hex fingerprint attached to key->type_data[1] with an
           asymmetric_key_ids struct containing the id and the skid (if present).
      
       (3) Make the asymmetric_type match data preparse select one of two searches:
      
           (a) An iterative search for the key ID given if prefixed with "id:".  The
           	 prefix is expected to be followed by a hex string giving the ID to
           	 search for.  The criterion key ID is checked against all key IDs
           	 recorded on the key.
      
           (b) A direct search if the key ID is not prefixed with "id:".  This will
           	 look for an exact match on the key description.
      
       (4) Make x509_request_asymmetric_key() take a key ID.  This is then converted
           into "id:<hex>" and passed into keyring_search() where match preparsing
           will turn it back into a binary ID.
      
       (5) X.509 certificate verification then takes the authority key ID and looks
           up a key that matches it to find the public key for the certificate
           signature.
      
       (6) PKCS#7 certificate verification then takes the id key ID and looks up a
           key that matches it to find the public key for the signed information
           block signature.
      
      Additional changes:
      
       (1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
           cert to be rejected with -EBADMSG.
      
       (2) The 'fingerprint' ID is gone.  This was primarily intended to convey PGP
           public key fingerprints.  If PGP is supported in future, this should
           generate a key ID that carries the fingerprint.
      
       (3) Th ca_keyid= kernel command line option is now converted to a key ID and
           used to match the authority key ID.  Possibly this should only match the
           actual authKeyId part and not the issuer as well.
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Acked-by: 's avatarVivek Goyal <vgoyal@redhat.com>
      46963b77
  20. 03 Aug, 2014 1 commit
  21. 29 Jul, 2014 1 commit
  22. 28 Jul, 2014 1 commit
  23. 22 Jul, 2014 1 commit
  24. 17 Jul, 2014 3 commits
    • Dmitry Kasatkin's avatar
      KEYS: validate certificate trust only with builtin keys · 32c4741c
      Dmitry Kasatkin authored
      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 only by
      builtin keys on the system keyring.
      
      This patch defines a new option 'builtin' for the kernel parameter
      'keys_ownerid' to allow trust validation using builtin keys.
      
      Simplified Mimi's "KEYS: define an owner trusted keyring" patch
      
      Changelog v7:
      - rename builtin_keys to use_builtin_keys
      Signed-off-by: 's avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      32c4741c
    • Dmitry Kasatkin's avatar
      KEYS: validate certificate trust only with selected key · ffb70f61
      Dmitry Kasatkin authored
      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.
      
      This patch defines a new kernel parameter 'ca_keys' to identify the
      specific key which must be used for trust validation of certificates.
      
      Simplified Mimi's "KEYS: define an owner trusted keyring" patch.
      
      Changelog:
      - support for builtin x509 public keys only
      - export "asymmetric_keyid_match"
      - remove ifndefs MODULE
      - rename kernel boot parameter from keys_ownerid to ca_keys
      Signed-off-by: 's avatarDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      ffb70f61
    • Mimi Zohar's avatar
      KEYS: verify a certificate is signed by a 'trusted' key · 3be4beaf
      Mimi Zohar authored
      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.
      
      This is derived from David Howells pkcs7_request_asymmetric_key() patch.
      
      Changelog v6:
      - on error free key - Dmitry
      - validate trust only for not already trusted keys - Dmitry
      - formatting cleanup
      
      Changelog:
      - define get_system_trusted_keyring() to fix kbuild issues
      Signed-off-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarDavid Howells <dhowells@redhat.com>
      Acked-by: 's avatarDmitry Kasatkin <dmitry.kasatkin@gmail.com>
      3be4beaf
  25. 24 Nov, 2013 1 commit
    • Linus Torvalds's avatar
      Revert "KEYS: verify a certificate is signed by a 'trusted' key" · 4c1cc40a
      Linus Torvalds authored
      This reverts commit 09fbc473, which
      caused the following build errors:
      
        crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’:
        crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function)
         ret = x509_validate_trust(cert, system_trusted_keyring);
                                         ^
        crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in
      
      reported by Jim Davis. Mimi says:
      
       "I made the classic mistake of requesting this patch to be upstreamed
        at the last second, rather than waiting until the next open window.
      
        At this point, the best course would probably be to revert the two
        commits and fix them for the next open window"
      Reported-by: 's avatarJim Davis <jim.epost@gmail.com>
      Acked-by: 's avatarMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      4c1cc40a
  26. 25 Oct, 2013 2 commits