Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 24 6月, 2016 2 次提交
  3. 23 6月, 2016 7 次提交
  5. 20 6月, 2016 5 次提交
  7. 15 6月, 2016 5 次提交
  9. 07 6月, 2016 1 次提交
  11. 02 6月, 2016 1 次提交
  13. 31 5月, 2016 1 次提交
  15. 19 5月, 2016 1 次提交
    • A
      crypto: public_key: select CRYPTO_AKCIPHER · bad6a185
      由 Arnd Bergmann 提交于 
      In some rare randconfig builds, we can end up with
ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled,
which fails to link because of the reference to crypto_alloc_akcipher:

crypto/built-in.o: In function `public_key_verify_signature':
:(.text+0x110e4): undefined reference to `crypto_alloc_akcipher'

This adds a Kconfig 'select' statement to ensure the dependency
is always there.

Cc: <stable@vger.kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bad6a185
  17. 11 5月, 2016 1 次提交
  19. 09 5月, 2016 1 次提交
  21. 05 5月, 2016 3 次提交
  23. 15 4月, 2016 2 次提交
  25. 12 4月, 2016 6 次提交
    • D
      KEYS: Move the point of trust determination to __key_link() · a511e1af
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
      a511e1af
    • D
      KEYS: Make the system trusted keyring depend on the asymmetric key type · 99716b7c
      由 David Howells 提交于 
      Make the system trusted keyring depend on the asymmetric key type as
there's not a lot of point having it if you can't then load asymmetric keys
onto it.

This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as
the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to
'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'.

Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't
work as the Kconfig interpreter then wrongly complains about dependency
loops.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      99716b7c
    • D
      X.509: Move the trust validation code out to its own file · cfb664ff
      由 David Howells 提交于 
      Move the X.509 trust validation code out to its own file so that it can be
generalised.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cfb664ff
    • D
      X.509: Use verify_signature() if we have a struct key * to use · 5f7f5c81
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
      5f7f5c81
    • D
      KEYS: Generalise x509_request_asymmetric_key() · 9eb02989
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
      9eb02989
    • D
      KEYS: Move x509_request_asymmetric_key() to asymmetric_type.c · 983023f2
      由 David Howells 提交于 
      Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be
generalised.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
      983023f2
  27. 06 4月, 2016 4 次提交
    • D
      PKCS#7: Make trust determination dependent on contents of trust keyring · bda850cd
      由 David Howells 提交于 
      Make the determination of the trustworthiness of a key dependent on whether
a key that can verify it is present in the supplied 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: NDavid Howells <dhowells@redhat.com>
      bda850cd
    • D
      KEYS: Generalise system_verify_data() to provide access to internal content · e68503bd
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
      e68503bd
    • D
      X.509: Fix self-signed determination · ad3043fd
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
      ad3043fd
    • D
      X.509: Extract signature digest and make self-signed cert checks earlier · 6c2dc5ae
      由 David Howells 提交于 
      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: NDavid Howells <dhowells@redhat.com>
      6c2dc5ae