1. 12 4月, 2016 4 次提交
    • D
      certs: Add a secondary system keyring that can be added to dynamically · d3bfe841
      David Howells 提交于
      Add a secondary system keyring that can be added to by root whilst the
      system is running - provided the key being added is vouched for by a key
      built into the kernel or already added to the secondary keyring.
      
      Rename .system_keyring to .builtin_trusted_keys to distinguish it more
      obviously from the new keyring (called .secondary_trusted_keys).
      
      The new keyring needs to be enabled with CONFIG_SECONDARY_TRUSTED_KEYRING.
      
      If the secondary keyring is enabled, a link is created from that to
      .builtin_trusted_keys so that the the latter will automatically be searched
      too if the secondary keyring is searched.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      d3bfe841
    • D
      KEYS: Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED · 77f68bac
      David Howells 提交于
      Remove KEY_FLAG_TRUSTED and KEY_ALLOC_TRUSTED as they're no longer
      meaningful.  Also we can drop the trusted flag from the preparse structure.
      
      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: NDavid Howells <dhowells@redhat.com>
      77f68bac
    • 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: Add a facility to restrict new links into a keyring · 5ac7eace
      David Howells 提交于
      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: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      5ac7eace
  2. 06 4月, 2016 2 次提交
    • 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
  3. 10 2月, 2016 1 次提交
  4. 14 8月, 2015 1 次提交
  5. 13 8月, 2015 1 次提交
    • D
      PKCS#7: Appropriately restrict authenticated attributes and content type · 99db4435
      David Howells 提交于
      A PKCS#7 or CMS message can have per-signature authenticated attributes
      that are digested as a lump and signed by the authorising key for that
      signature.  If such attributes exist, the content digest isn't itself
      signed, but rather it is included in a special authattr which then
      contributes to the signature.
      
      Further, we already require the master message content type to be
      pkcs7_signedData - but there's also a separate content type for the data
      itself within the SignedData object and this must be repeated inside the
      authattrs for each signer [RFC2315 9.2, RFC5652 11.1].
      
      We should really validate the authattrs if they exist or forbid them
      entirely as appropriate.  To this end:
      
       (1) Alter the PKCS#7 parser to reject any message that has more than one
           signature where at least one signature has authattrs and at least one
           that does not.
      
       (2) Validate authattrs if they are present and strongly restrict them.
           Only the following authattrs are permitted and all others are
           rejected:
      
           (a) contentType.  This is checked to be an OID that matches the
           	 content type in the SignedData object.
      
           (b) messageDigest.  This must match the crypto digest of the data.
      
           (c) signingTime.  If present, we check that this is a valid, parseable
           	 UTCTime or GeneralTime and that the date it encodes fits within
           	 the validity window of the matching X.509 cert.
      
           (d) S/MIME capabilities.  We don't check the contents.
      
           (e) Authenticode SP Opus Info.  We don't check the contents.
      
           (f) Authenticode Statement Type.  We don't check the contents.
      
           The message is rejected if (a) or (b) are missing.  If the message is
           an Authenticode type, the message is rejected if (e) is missing; if
           not Authenticode, the message is rejected if (d) - (f) are present.
      
           The S/MIME capabilities authattr (d) unfortunately has to be allowed
           to support kernels already signed by the pesign program.  This only
           affects kexec.  sign-file suppresses them (CMS_NOSMIMECAP).
      
           The message is also rejected if an authattr is given more than once or
           if it contains more than one element in its set of values.
      
       (3) Add a parameter to pkcs7_verify() to select one of the following
           restrictions and pass in the appropriate option from the callers:
      
           (*) VERIFYING_MODULE_SIGNATURE
      
      	 This requires that the SignedData content type be pkcs7-data and
      	 forbids authattrs.  sign-file sets CMS_NOATTR.  We could be more
      	 flexible and permit authattrs optionally, but only permit minimal
      	 content.
      
           (*) VERIFYING_FIRMWARE_SIGNATURE
      
      	 This requires that the SignedData content type be pkcs7-data and
      	 requires authattrs.  In future, this will require an attribute
      	 holding the target firmware name in addition to the minimal set.
      
           (*) VERIFYING_UNSPECIFIED_SIGNATURE
      
      	 This requires that the SignedData content type be pkcs7-data but
      	 allows either no authattrs or only permits the minimal set.
      
           (*) VERIFYING_KEXEC_PE_SIGNATURE
      
      	 This only supports the Authenticode SPC_INDIRECT_DATA content type
      	 and requires at least an SpcSpOpusInfo authattr in addition to the
      	 minimal set.  It also permits an SPC_STATEMENT_TYPE authattr (and
      	 an S/MIME capabilities authattr because the pesign program doesn't
      	 remove these).
      
           (*) VERIFYING_KEY_SIGNATURE
           (*) VERIFYING_KEY_SELF_SIGNATURE
      
      	 These are invalid in this context but are included for later use
      	 when limiting the use of X.509 certs.
      
       (4) The pkcs7_test key type is given a module parameter to select between
           the above options for testing purposes.  For example:
      
      	echo 1 >/sys/module/pkcs7_test_key/parameters/usage
      	keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7
      
           will attempt to check the signature on stuff.pkcs7 as if it contains a
           firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).
      Suggested-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      99db4435
  6. 07 8月, 2015 2 次提交
  7. 17 7月, 2014 1 次提交
    • D
      KEYS: validate certificate trust only with builtin keys · 32c4741c
      Dmitry Kasatkin 提交于
      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: NDmitry Kasatkin <d.kasatkin@samsung.com>
      Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
      32c4741c
  8. 11 12月, 2013 1 次提交
    • H
      KEYS: correct alignment of system_certificate_list content in assembly file · 62226983
      Hendrik Brueckner 提交于
      Apart from data-type specific alignment constraints, there are also
      architecture-specific alignment requirements.
      For example, on s390 symbols must be on even addresses implying a 2-byte
      alignment.  If the system_certificate_list_end symbol is on an odd address
      and if this address is loaded, the least-significant bit is ignored.  As a
      result, the load_system_certificate_list() fails to load the certificates
      because of a wrong certificate length calculation.
      
      To be safe, align system_certificate_list on an 8-byte boundary.  Also improve
      the length calculation of the system_certificate_list content.  Introduce a
      system_certificate_list_size (8-byte aligned because of unsigned long) variable
      that stores the length.  Let the linker calculate this size by introducing
      a start and end label for the certificate content.
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      62226983
  9. 26 9月, 2013 3 次提交