1. 03 4月, 2017 2 次提交
    • D
      PKCS#7: Handle blacklisted certificates · 03bb7931
      David Howells 提交于
      PKCS#7: Handle certificates that are blacklisted when verifying the chain
      of trust on the signatures on a PKCS#7 message.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      03bb7931
    • D
      X.509: Allow X.509 certs to be blacklisted · 43652956
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      43652956
  2. 14 12月, 2016 1 次提交
  3. 25 11月, 2016 1 次提交
    • A
      X.509: Fix double free in x509_cert_parse() [ver #3] · 2b95fda2
      Andrey Ryabinin 提交于
      We shouldn't free cert->pub->key in x509_cert_parse() because
      x509_free_certificate() also does this:
      	BUG: Double free or freeing an invalid pointer
      	...
      	Call Trace:
      	 [<ffffffff81896c20>] dump_stack+0x63/0x83
      	 [<ffffffff81356571>] kasan_object_err+0x21/0x70
      	 [<ffffffff81356ed9>] kasan_report_double_free+0x49/0x60
      	 [<ffffffff813561ad>] kasan_slab_free+0x9d/0xc0
      	 [<ffffffff81350b7a>] kfree+0x8a/0x1a0
      	 [<ffffffff81844fbf>] public_key_free+0x1f/0x30
      	 [<ffffffff818455d4>] x509_free_certificate+0x24/0x90
      	 [<ffffffff818460bc>] x509_cert_parse+0x2bc/0x300
      	 [<ffffffff81846cae>] x509_key_preparse+0x3e/0x330
      	 [<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100
      	 [<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0
      	 [<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0
      	 [<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad
      	Object at ffff880110bd1900, in cache kmalloc-512 size: 512
      	....
      	Freed:
      	PID = 2579
      	[<ffffffff8104283b>] save_stack_trace+0x1b/0x20
      	[<ffffffff813558f6>] save_stack+0x46/0xd0
      	[<ffffffff81356183>] kasan_slab_free+0x73/0xc0
      	[<ffffffff81350b7a>] kfree+0x8a/0x1a0
      	[<ffffffff818460a3>] x509_cert_parse+0x2a3/0x300
      	[<ffffffff81846cae>] x509_key_preparse+0x3e/0x330
      	[<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100
      	[<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0
      	[<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0
      	[<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad
      
      Fixes: db6c43bd ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
      Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      2b95fda2
  4. 18 7月, 2016 3 次提交
    • M
      KEYS: Fix for erroneous trust of incorrectly signed X.509 certs · acddc720
      Mat Martineau 提交于
      Arbitrary X.509 certificates without authority key identifiers (AKIs)
      can be added to "trusted" keyrings, including IMA or EVM certs loaded
      from the filesystem. Signature verification is currently bypassed for
      certs without AKIs.
      
      Trusted keys were recently refactored, and this bug is not present in
      4.6.
      
      restrict_link_by_signature should return -ENOKEY (no matching parent
      certificate found) if the certificate being evaluated has no AKIs,
      instead of bypassing signature checks and returning 0 (new certificate
      accepted).
      Reported-by: NPetko Manolov <petkan@mip-labs.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      acddc720
    • L
      pefile: Fix the failure of calculation for digest · d128471a
      Lans Zhang 提交于
      Commit e68503bd forgot to set digest_len and thus cause the following
      error reported by kexec when launching a crash kernel:
      
      	kexec_file_load failed: Bad message
      
      Fixes: e68503bd (KEYS: Generalise system_verify_data() to provide access to internal content)
      Signed-off-by: NLans Zhang <jia.zhang@windriver.com>
      Tested-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      cc: kexec@lists.infradead.org
      cc: linux-crypto@vger.kernel.org
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      d128471a
    • L
      PKCS#7: Fix panic when referring to the empty AKID when DEBUG defined · a46e6678
      Lans Zhang 提交于
      This fix resolves the following kernel panic if an empty or missing
      AuthorityKeyIdentifier is encountered and DEBUG is defined in
      pkcs7_verify.c.
      
      [  459.041989] PKEY: <==public_key_verify_signature() = 0
      [  459.041993] PKCS7: Verified signature 1
      [  459.041995] PKCS7: ==> pkcs7_verify_sig_chain()
      [  459.041999] PKCS7: verify Sample DB Certificate for SCP: 01
      [  459.042002] PKCS7: - issuer Sample KEK Certificate for SCP
      [  459.042014] BUG: unable to handle kernel NULL pointer dereference at           (null)
      [  459.042135] IP: [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0
      [  459.042217] PGD 739e6067 PUD 77719067 PMD 0
      [  459.042286] Oops: 0000 [#1] PREEMPT SMP
      [  459.042328] Modules linked in:
      [  459.042368] CPU: 0 PID: 474 Comm: kexec Not tainted 4.7.0-rc7-WR8.0.0.0_standard+ #18
      [  459.042462] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 10/09/2014
      [  459.042586] task: ffff880073a50000 ti: ffff8800738e8000 task.ti: ffff8800738e8000
      [  459.042675] RIP: 0010:[<ffffffff813e7b4c>]  [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0
      [  459.042784] RSP: 0018:ffff8800738ebd58  EFLAGS: 00010246
      [  459.042845] RAX: 0000000000000000 RBX: ffff880076b7da80 RCX: 0000000000000006
      [  459.042929] RDX: 0000000000000001 RSI: ffffffff81c85001 RDI: ffffffff81ca00a9
      [  459.043014] RBP: ffff8800738ebd98 R08: 0000000000000400 R09: ffff8800788a304c
      [  459.043098] R10: 0000000000000000 R11: 00000000000060ca R12: ffff8800769a2bc0
      [  459.043182] R13: ffff880077358300 R14: 0000000000000000 R15: ffff8800769a2dc0
      [  459.043268] FS:  00007f24cc741700(0000) GS:ffff880074e00000(0000) knlGS:0000000000000000
      [  459.043365] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  459.043431] CR2: 0000000000000000 CR3: 0000000073a36000 CR4: 00000000001006f0
      [  459.043514] Stack:
      [  459.043530]  0000000000000000 ffffffbf00000020 31ffffff813e68b0 0000000000000002
      [  459.043644]  ffff8800769a2bc0 0000000000000000 00000000007197b8 0000000000000002
      [  459.043756]  ffff8800738ebdd8 ffffffff81153fb1 0000000000000000 0000000000000000
      [  459.043869] Call Trace:
      [  459.043898]  [<ffffffff81153fb1>] verify_pkcs7_signature+0x61/0x140
      [  459.043974]  [<ffffffff813e7f0b>] verify_pefile_signature+0x2cb/0x830
      [  459.044052]  [<ffffffff813e8470>] ? verify_pefile_signature+0x830/0x830
      [  459.044134]  [<ffffffff81048e25>] bzImage64_verify_sig+0x15/0x20
      [  459.046332]  [<ffffffff81046e09>] arch_kexec_kernel_verify_sig+0x29/0x40
      [  459.048552]  [<ffffffff810f10e4>] SyS_kexec_file_load+0x1f4/0x6c0
      [  459.050768]  [<ffffffff81050e36>] ? __do_page_fault+0x1b6/0x550
      [  459.052996]  [<ffffffff8199241f>] entry_SYSCALL_64_fastpath+0x17/0x93
      [  459.055242] Code: e8 0a d6 ff ff 85 c0 0f 88 7a fb ff ff 4d 39 fd 4d 89 7d 08 74 45 4d 89 fd e9 14 fe ff ff 4d 8b 76 08 31 c0 48 c7 c7 a9 00 ca 81 <41> 0f b7 36 49 8d 56 02 e8 d0 91 d6 ff 4d 8b 3c 24 4d 85 ff 0f
      [  459.060535] RIP  [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0
      [  459.063040]  RSP <ffff8800738ebd58>
      [  459.065456] CR2: 0000000000000000
      [  459.075998] ---[ end trace c15f0e897cda28dc ]---
      Signed-off-by: NLans Zhang <jia.zhang@windriver.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      cc: linux-crypto@vger.kernel.org
      cc: kexec@lists.infradead.org
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      a46e6678
  5. 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
  6. 11 5月, 2016 1 次提交
  7. 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
  8. 06 4月, 2016 9 次提交
    • 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
    • D
      PKCS#7: Make the signature a pointer rather than embedding it · 566a117a
      David Howells 提交于
      Point to the public_key_signature struct from the pkcs7_signed_info struct
      rather than embedding it.  This makes the code consistent with the X.509
      signature handling and makes it possible to have a common cleanup function.
      
      We also save a copy of the digest in the signature without sharing the
      memory with the crypto layer metadata.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      566a117a
    • D
      X.509: Retain the key verification data · 77d0910d
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      77d0910d
    • D
      KEYS: Add identifier pointers to public_key_signature struct · a022ec02
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      a022ec02
    • D
      KEYS: Allow authentication data to be stored in an asymmetric key · 3b764563
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      3b764563
    • D
      X.509: Whitespace cleanup · 864e7a81
      David Howells 提交于
      Clean up some whitespace.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      864e7a81
  9. 05 4月, 2016 1 次提交
  10. 23 3月, 2016 1 次提交
    • N
      PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument · e5435891
      Nicolai Stange 提交于
      Despite what the DocBook comment to pkcs7_validate_trust() says, the
      *_trusted argument is never set to false.
      
      pkcs7_validate_trust() only positively sets *_trusted upon encountering
      a trusted PKCS#7 SignedInfo block.
      
      This is quite unfortunate since its callers, system_verify_data() for
      example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust.
      
      Indeed, UBSAN splats when attempting to load the uninitialized local
      variable 'trusted' from system_verify_data() in pkcs7_validate_trust():
      
        UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14
        load of value 82 is not a valid value for type '_Bool'
        [...]
        Call Trace:
          [<ffffffff818c4d35>] dump_stack+0xbc/0x117
          [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169
          [<ffffffff8194113b>] ubsan_epilogue+0xd/0x4e
          [<ffffffff819419fa>] __ubsan_handle_load_invalid_value+0x111/0x158
          [<ffffffff819418e9>] ? val_to_string.constprop.12+0xcf/0xcf
          [<ffffffff818334a4>] ? x509_request_asymmetric_key+0x114/0x370
          [<ffffffff814b83f0>] ? kfree+0x220/0x370
          [<ffffffff818312c2>] ? public_key_verify_signature_2+0x32/0x50
          [<ffffffff81835e04>] pkcs7_validate_trust+0x524/0x5f0
          [<ffffffff813c391a>] system_verify_data+0xca/0x170
          [<ffffffff813c3850>] ? top_trace_array+0x9b/0x9b
          [<ffffffff81510b29>] ? __vfs_read+0x279/0x3d0
          [<ffffffff8129372f>] mod_verify_sig+0x1ff/0x290
          [...]
      
      The implication is that pkcs7_validate_trust() effectively grants trust
      when it really shouldn't have.
      
      Fix this by explicitly setting *_trusted to false at the very beginning
      of pkcs7_validate_trust().
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NNicolai Stange <nicstange@gmail.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      e5435891
  11. 04 3月, 2016 2 次提交
    • D
      X.509: Make algo identifiers text instead of enum · 4e8ae72a
      David Howells 提交于
      Make the identifier public key and digest algorithm fields text instead of
      enum.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4e8ae72a
    • D
      akcipher: Move the RSA DER encoding check to the crypto layer · d43de6c7
      David Howells 提交于
      Move the RSA EMSA-PKCS1-v1_5 encoding from the asymmetric-key public_key
      subtype to the rsa crypto module's pkcs1pad template.  This means that the
      public_key subtype no longer has any dependencies on public key type.
      
      To make this work, the following changes have been made:
      
       (1) The rsa pkcs1pad template is now used for RSA keys.  This strips off the
           padding and returns just the message hash.
      
       (2) In a previous patch, the pkcs1pad template gained an optional second
           parameter that, if given, specifies the hash used.  We now give this,
           and pkcs1pad checks the encoded message E(M) for the EMSA-PKCS1-v1_5
           encoding and verifies that the correct digest OID is present.
      
       (3) The crypto driver in crypto/asymmetric_keys/rsa.c is now reduced to
           something that doesn't care about what the encryption actually does
           and and has been merged into public_key.c.
      
       (4) CONFIG_PUBLIC_KEY_ALGO_RSA is gone.  Module signing must set
           CONFIG_CRYPTO_RSA=y instead.
      
      Thoughts:
      
       (*) Should the encoding style (eg. raw, EMSA-PKCS1-v1_5) also be passed to
           the padding template?  Should there be multiple padding templates
           registered that share most of the code?
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      d43de6c7
  12. 29 2月, 2016 4 次提交
    • D
      X.509: Handle midnight alternative notation in GeneralizedTime · 7650cb80
      David Howells 提交于
      The ASN.1 GeneralizedTime object carries an ISO 8601 format date and time.
      The time is permitted to show midnight as 00:00 or 24:00 (the latter being
      equivalent of 00:00 of the following day).
      
      The permitted value is checked in x509_decode_time() but the actual
      handling is left to mktime64().
      
      Without this patch, certain X.509 certificates will be rejected and could
      lead to an unbootable kernel.
      
      Note that with this patch we also permit any 24:mm:ss time and extend this
      to UTCTime, which whilst not strictly correct don't permit much leeway in
      fiddling date strings.
      Reported-by: NRudolf Polzer <rpolzer@google.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      cc: David Woodhouse <David.Woodhouse@intel.com>
      cc: John Stultz <john.stultz@linaro.org>
      7650cb80
    • D
      X.509: Support leap seconds · da02559c
      David Howells 提交于
      The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601
      [X.680 46.3] and this apparently supports leap seconds (ie. the seconds
      field is 60).  It's not entirely clear that ASN.1 expects it, but we can
      relax the seconds check slightly for GeneralizedTime.
      
      This results in us passing a time with sec as 60 to mktime64(), which
      handles it as being a duplicate of the 0th second of the next minute.
      
      We can't really do otherwise without giving the kernel much greater
      knowledge of where all the leap seconds are.  Unfortunately, this would
      require change the mapping of the kernel's current-time-in-seconds.
      
      UTCTime, however, only supports a seconds value in the range 00-59, but for
      the sake of simplicity allow this with UTCTime also.
      
      Without this patch, certain X.509 certificates will be rejected,
      potentially making a kernel unbootable.
      Reported-by: NRudolf Polzer <rpolzer@google.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      cc: David Woodhouse <David.Woodhouse@intel.com>
      cc: John Stultz <john.stultz@linaro.org>
      da02559c
    • D
      X.509: Fix leap year handling again · ac4cbedf
      David Howells 提交于
      There are still a couple of minor issues in the X.509 leap year handling:
      
       (1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
           determining whether the year is a leap year or not, I divided the year
           by 100 after doing the modulus-by-100, thereby letting the compiler do
           one instruction for both, and then did a modulus-by-4.
      
           Unfortunately, I then passed the now-modified year value to mktime64()
           to construct a time value.
      
           Since this isn't a fast path and since mktime64() does a bunch of
           divisions, just condense down to "% 400".  It's also easier to read.
      
       (2) The default month length for any February where the year doesn't
           divide by four exactly is obtained from the month_length[] array where
           the value is 29, not 28.
      
           This is fixed by altering the table.
      Reported-by: NRudolf Polzer <rpolzer@google.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      cc: stable@vger.kernel.org
      ac4cbedf
    • C
      PKCS#7: fix unitialized boolean 'want' · 06aae592
      Colin Ian King 提交于
      The boolean want is not initialized and hence garbage. The default should
      be false (later it is only set to true on tne sinfo->authattrs check).
      
      Found with static analysis using CoverityScan
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      06aae592
  13. 10 2月, 2016 1 次提交
  14. 09 2月, 2016 1 次提交
  15. 06 2月, 2016 1 次提交
  16. 25 1月, 2016 1 次提交
    • P
      PKCS#7: Don't require SpcSpOpusInfo in Authenticode pkcs7 signatures · 7ee7014d
      Peter Jones 提交于
      Dave Young reported:
      > Hi,
      >
      > I saw the warning "Missing required AuthAttr" when testing kexec,
      > known issue?  Idea about how to fix it?
      >
      > The kernel is latest linus tree plus sevral patches from Toshi to
      > cleanup io resource structure.
      >
      > in function pkcs7_sig_note_set_of_authattrs():
      >         if (!test_bit(sinfo_has_content_type, &sinfo->aa_set) ||
      >             !test_bit(sinfo_has_message_digest, &sinfo->aa_set) ||
      >             (ctx->msg->data_type == OID_msIndirectData &&
      >              !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))) {
      >                 pr_warn("Missing required AuthAttr\n");
      >                 return -EBADMSG;
      >         }
      >
      > The third condition below is true:
      > (ctx->msg->data_type == OID_msIndirectData &&
      >              !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))
      >
      > I signed the kernel with redhat test key like below:
      > pesign -c 'Red Hat Test Certificate' -i arch/x86/boot/bzImage -o /boot/vmlinuz-4.4.0-rc8+ -s --force
      
      And right he is!  The Authenticode specification is a paragon amongst
      technical documents, and has this pearl of wisdom to offer:
      
      ---------------------------------
      Authenticode-Specific SignerInfo UnauthenticatedAttributes Structures
      
        The following Authenticode-specific data structures are present in
        SignerInfo authenticated attributes.
      
        SpcSpOpusInfo
        SpcSpOpusInfo is identified by SPC_SP_OPUS_INFO_OBJID
        (1.3.6.1.4.1.311.2.1.12) and is defined as follows:
        SpcSpOpusInfo ::= SEQUENCE {
          programName  [0] EXPLICIT SpcString OPTIONAL,
          moreInfo     [1] EXPLICIT SpcLink OPTIONAL,
        } --#public--
      
        SpcSpOpusInfo has two fields:
          programName
            This field contains the program description:
            If publisher chooses not to specify a description, the SpcString
            structure contains a zero-length program name.
            If the publisher chooses to specify a
            description, the SpcString structure contains a Unicode string.
          moreInfo
            This field is set to an SPCLink structure that contains a URL for
            a Web site with more information about the signer. The URL is an
            ASCII string.
      ---------------------------------
      
      Which is to say that this is an optional *unauthenticated* field which
      may be present in the Authenticated Attribute list.  This is not how
      pkcs7 is supposed to work, so when David implemented this, he didn't
      appreciate the subtlety the original spec author was working with, and
      missed the part of the sublime prose that says this Authenticated
      Attribute is an Unauthenticated Attribute.  As a result, the code in
      question simply takes as given that the Authenticated Attributes should
      be authenticated.
      
      But this one should not, individually.  Because it says it's not
      authenticated.
      
      It still has to hash right so the TBS digest is correct.  So it is both
      authenticated and unauthenticated, all at once.  Truly, a wonder of
      technical accomplishment.
      
      Additionally, pesign's implementation has always attempted to be
      compatible with the signatures emitted from contemporary versions of
      Microsoft's signtool.exe.  During the initial implementation, Microsoft
      signatures always produced the same values for SpcSpOpusInfo -
      {U"Microsoft Windows", "http://www.microsoft.com"} - without regard to
      who the signer was.
      
      Sometime between Windows 8 and Windows 8.1 they stopped including the
      field in their signatures altogether, and as such pesign stopped
      producing them in commits c0c4da6 and d79cb0c, sometime around June of
      2012.  The theory here is that anything that breaks with
      pesign signatures would also be breaking with signtool.exe sigs as well,
      and that'll be a more noticed problem for firmwares parsing it, so it'll
      get fixed.  The fact that we've done exactly this bug in Linux code is
      first class, grade A irony.
      
      So anyway, we should not be checking this field for presence or any
      particular value: if the field exists, it should be at the right place,
      but aside from that, as long as the hash matches the field is good.
      Signed-off-by: NPeter Jones <pjones@redhat.com>
      Tested-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7ee7014d
  17. 15 12月, 2015 1 次提交
    • P
      IMA: create machine owner and blacklist keyrings · 41c89b64
      Petko Manolov 提交于
      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: NPetko Manolov <petkan@mip-labs.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      41c89b64
  18. 11 12月, 2015 1 次提交
  19. 12 11月, 2015 1 次提交
    • D
      X.509: Fix the time validation [ver #2] · cc25b994
      David Howells 提交于
      This fixes CVE-2015-5327.  It affects kernels from 4.3-rc1 onwards.
      
      Fix the X.509 time validation to use month number-1 when looking up the
      number of days in that month.  Also put the month number validation before
      doing the lookup so as not to risk overrunning the array.
      
      This can be tested by doing the following:
      
      cat <<EOF | openssl x509 -outform DER | keyctl padd asymmetric "" @s
      -----BEGIN CERTIFICATE-----
      MIIDbjCCAlagAwIBAgIJAN/lUld+VR4hMA0GCSqGSIb3DQEBCwUAMCkxETAPBgNV
      BAoMCGxvY2FsLWNhMRQwEgYDVQQDDAtzaWduaW5nIGtleTAeFw0xNTA5MDEyMTMw
      MThaFw0xNjA4MzEyMTMwMThaMCkxETAPBgNVBAoMCGxvY2FsLWNhMRQwEgYDVQQD
      DAtzaWduaW5nIGtleTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANrn
      crcMfMeG67nagX4+m02Xk9rkmsMKI5XTUxbikROe7GSUVJ27sPVPZp4mgzoWlvhh
      jfK8CC/qhEhwep8Pgg4EJZyWOjhZb7R97ckGvLIoUC6IO3FC2ZnR7WtmWDgo2Jcj
      VlXwJdHhKU1VZwulh81O61N8IBKqz2r/kDhIWiicUCUkI/Do/RMRfKAoDBcSh86m
      gOeIAGfq62vbiZhVsX5dOE8Oo2TK5weAvwUIOR7OuGBl5AqwFlPnXQolewiHzKry
      THg9e44HfzG4Mi6wUvcJxVaQT1h5SrKD779Z5+8+wf1JLaooetcEUArvWyuxCU59
      qxA4lsTjBwl4cmEki+cCAwEAAaOBmDCBlTAMBgNVHRMEBTADAQH/MAsGA1UdDwQE
      AwIHgDAdBgNVHQ4EFgQUyND/eKUis7ep/hXMJ8iZMdUhI+IwWQYDVR0jBFIwUIAU
      yND/eKUis7ep/hXMJ8iZMdUhI+KhLaQrMCkxETAPBgNVBAoMCGxvY2FsLWNhMRQw
      EgYDVQQDDAtzaWduaW5nIGtleYIJAN/lUld+VR4hMA0GCSqGSIb3DQEBCwUAA4IB
      AQAMqm1N1yD5pimUELLhT5eO2lRdGUfTozljRxc7e2QT3RLk2TtGhg65JFFN6eml
      XS58AEPVcAsSLDlR6WpOpOLB2giM0+fV/eYFHHmh22yqTJl4YgkdUwyzPdCHNOZL
      hmSKeY9xliHb6PNrNWWtZwhYYvRaO2DX4GXOMR0Oa2O4vaYu6/qGlZOZv3U6qZLY
      wwHEJSrqeBDyMuwN+eANHpoSpiBzD77S4e+7hUDJnql4j6xzJ65+nWJ89fCrQypR
      4sN5R3aGeIh3QAQUIKpHilwek0CtEaYERgc5m+jGyKSc1rezJW62hWRTaitOc+d5
      G5hh+9YpnYcxQHEKnZ7rFNKJ
      -----END CERTIFICATE-----
      EOF
      
      If it works, it emit a key ID; if it fails, it should give a bad message
      error.
      Reported-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      Acked-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      cc25b994
  20. 21 10月, 2015 1 次提交
    • D
      KEYS: Merge the type-specific data with the payload data · 146aa8b1
      David Howells 提交于
      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: NDavid 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