16 Sep, 2015

1 commit

  • Pull crypto fixes from Herbert Xu:
    "This fixes the following issues:

    - The selftest overreads the IV test vector.

    - Fix potential infinite loop in sunxi-ss driver.

    - Fix powerpc build failure when VMX is set without VSX"

    * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
    crypto: testmgr - don't copy from source IV too much
    crypto: sunxi-ss - Fix a possible driver hang with ciphers
    crypto: vmx - VMX crypto should depend on CONFIG_VSX

    Linus Torvalds
     

11 Sep, 2015

1 commit


09 Sep, 2015

1 commit

  • Pull security subsystem updates from James Morris:
    "Highlights:

    - PKCS#7 support added to support signed kexec, also utilized for
    module signing. See comments in 3f1e1bea.

    ** NOTE: this requires linking against the OpenSSL library, which
    must be installed, e.g. the openssl-devel on Fedora **

    - Smack
    - add IPv6 host labeling; ignore labels on kernel threads
    - support smack labeling mounts which use binary mount data

    - SELinux:
    - add ioctl whitelisting (see
    http://kernsec.org/files/lss2015/vanderstoep.pdf)
    - fix mprotect PROT_EXEC regression caused by mm change

    - Seccomp:
    - add ptrace options for suspend/resume"

    * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (57 commits)
    PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use them
    Documentation/Changes: Now need OpenSSL devel packages for module signing
    scripts: add extract-cert and sign-file to .gitignore
    modsign: Handle signing key in source tree
    modsign: Use if_changed rule for extracting cert from module signing key
    Move certificate handling to its own directory
    sign-file: Fix warning about BIO_reset() return value
    PKCS#7: Add MODULE_LICENSE() to test module
    Smack - Fix build error with bringup unconfigured
    sign-file: Document dependency on OpenSSL devel libraries
    PKCS#7: Appropriately restrict authenticated attributes and content type
    KEYS: Add a name for PKEY_ID_PKCS7
    PKCS#7: Improve and export the X.509 ASN.1 time object decoder
    modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS
    extract-cert: Cope with multiple X.509 certificates in a single file
    sign-file: Generate CMS message as signature instead of PKCS#7
    PKCS#7: Support CMS messages also [RFC5652]
    X.509: Change recorded SKID & AKID to not include Subject or Issuer
    PKCS#7: Check content type and versions
    MAINTAINERS: The keyrings mailing list has moved
    ...

    Linus Torvalds
     

03 Sep, 2015

1 commit

  • Pull SG updates from Jens Axboe:
    "This contains a set of scatter-gather related changes/fixes for 4.3:

    - Add support for limited chaining of sg tables even for
    architectures that do not set ARCH_HAS_SG_CHAIN. From Christoph.

    - Add sg chain support to target_rd. From Christoph.

    - Fixup open coded sg->page_link in crypto/omap-sham. From
    Christoph.

    - Fixup open coded crypto ->page_link manipulation. From Dan.

    - Also from Dan, automated fixup of manual sg_unmark_end()
    manipulations.

    - Also from Dan, automated fixup of open coded sg_phys()
    implementations.

    - From Robert Jarzmik, addition of an sg table splitting helper that
    drivers can use"

    * 'for-4.3/sg' of git://git.kernel.dk/linux-block:
    lib: scatterlist: add sg splitting function
    scatterlist: use sg_phys()
    crypto/omap-sham: remove an open coded access to ->page_link
    scatterlist: remove open coded sg_unmark_end instances
    crypto: replace scatterwalk_sg_chain with sg_chain
    target/rd: always chain S/G list
    scatterlist: allow limited chaining without ARCH_HAS_SG_CHAIN

    Linus Torvalds
     

01 Sep, 2015

1 commit

  • Add OIDs for sha224, sha284 and sha512 hash algos and use them to select
    the hashing algorithm. Without this, something like the following error
    might get written to dmesg:

    [ 31.829322] PKCS7: Unknown OID: [32] 2.16.840.1.101.3.4.2.3
    [ 31.829328] PKCS7: Unknown OID: [180] 2.16.840.1.101.3.4.2.3
    [ 31.829330] Unsupported digest algo: 55

    Where the 55 on the third line is OID__NR indicating an unknown OID.

    Reported-by: Valdis Kletnieks
    Signed-off-by: David Howells
    Tested-By: Valdis Kletnieks
    Signed-off-by: James Morris

    David Howells
     

25 Aug, 2015

1 commit


21 Aug, 2015

2 commits

  • This patch replaces uses of blkcipher and ablkcipher with the
    new skcipher interface.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • This patch introduces the crypto skcipher interface which aims
    to replace both blkcipher and ablkcipher.

    It's very similar to the existing ablkcipher interface. The
    main difference is the removal of the givcrypt interface. In
    order to make the transition easier for blkcipher users, there
    is a helper SKCIPHER_REQUEST_ON_STACK which can be used to place
    a request on the stack for synchronous transforms.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

19 Aug, 2015

1 commit


17 Aug, 2015

14 commits


14 Aug, 2015

1 commit


13 Aug, 2015

7 commits

  • Add a MODULE_LICENSE() line to the PKCS#7 test key module to fix this
    warning:

    WARNING: modpost: missing MODULE_LICENSE() in
    crypto/asymmetric_keys/pkcs7_test_key.o

    Whilst we're at it, also add a module description.

    Reported-by: James Morris
    Signed-off-by: David Howells

    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
    Signed-off-by: David Howells
    Reviewed-by: Marcel Holtmann
    Reviewed-by: David Woodhouse

    David Howells
     
  • Add a name for PKEY_ID_PKCS7 into the pkey_id_type_name array.

    Signed-off-by: David Howells

    David Howells
     
  • Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a
    struct tm to make comparison easier (unfortunately, this makes readable
    display less easy) and export it so that it can be used by the PKCS#7 code
    too.

    Further, tighten up its parsing to reject invalid dates (eg. weird
    characters, non-existent hour numbers) and unsupported dates (eg. timezones
    other than 'Z' or dates earlier than 1970).

    Signed-off-by: David Howells
    Reviewed-by: David Woodhouse

    David Howells
     
  • Since CMS is an evolution of PKCS#7, with much of the ASN.1 being
    compatible, add support for CMS signed-data messages also [RFC5652 sec 5].

    Signed-off-by: David Howells
    Reviewed-By: David Woodhouse

    David Howells
     
  • The key identifiers fabricated from an X.509 certificate are currently:

    (A) Concatenation of serial number and issuer

    (B) Concatenation of subject and subjectKeyID (SKID)

    When verifying one X.509 certificate with another, the AKID in the target
    can be used to match the authoritative certificate. The AKID can specify
    the match in one or both of two ways:

    (1) Compare authorityCertSerialNumber and authorityCertIssuer from the AKID
    to identifier (A) above.

    (2) Compare keyIdentifier from the AKID plus the issuer from the target
    certificate to identifier (B) above.

    When verifying a PKCS#7 message, the only available comparison is between
    the IssuerAndSerialNumber field and identifier (A) above.

    However, a subsequent patch adds CMS support. Whilst CMS still supports a
    match on IssuerAndSerialNumber as for PKCS#7, it also supports an
    alternative - which is the SubjectKeyIdentifier field. This is used to
    match to an X.509 certificate on the SKID alone. No subject information is
    available to be used.

    To this end change the fabrication of (B) above to be from the X.509 SKID
    alone. The AKID in keyIdentifier form then only matches on that and does
    not include the issuer.

    Signed-off-by: David Howells
    Reviewed-By: David Woodhouse

    David Howells
     
  • We only support PKCS#7 signed-data [RFC2315 sec 9] content at the top level,
    so reject anything else. Further, check that the version numbers in
    SignedData and SignerInfo are 1 in both cases.

    Note that we don't restrict the inner content type. In the PKCS#7 code we
    don't parse the data attached there, but merely verify the signature over
    it.

    Signed-off-by: David Howells
    Reviewed-By: David Woodhouse

    David Howells
     

10 Aug, 2015

3 commits


07 Aug, 2015

3 commits

  • It is possible for a PKCS#7 message to have detached data. However, to verify
    the signatures on a PKCS#7 message, we have to be able to digest the data.
    Provide a function to supply that data. An error is given if the PKCS#7
    message included embedded data.

    This is used in a subsequent patch to supply the data to module signing where
    the signature is in the form of a PKCS#7 message with detached data, whereby
    the detached data is the module content that is signed.

    Signed-off-by: David Howells
    Tested-by: Vivek Goyal

    David Howells
     
  • If an X.509 certificate has an AuthorityKeyIdentifier extension that provides
    an issuer and serialNumber, then make it so that these are used in preference
    to the keyIdentifier field also held therein for searching for the signing
    certificate.

    If both the issuer+serialNumber and the keyIdentifier are supplied, then the
    certificate is looked up by the former but the latter is checked as well. If
    the latter doesn't match the subjectKeyIdentifier of the parent certificate,
    EKEYREJECTED is returned.

    This makes it possible to chain X.509 certificates based on the issuer and
    serialNumber fields rather than on subjectKeyIdentifier. This is necessary as
    we are having to deal with keys that are represented by X.509 certificates
    that lack a subjectKeyIdentifier.

    Signed-off-by: David Howells
    Tested-by: Vivek Goyal

    David Howells
     
  • Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier,
    as the second part can be used to match X.509 certificates by issuer and
    serialNumber.

    Signed-off-by: David Howells
    Tested-by: Vivek Goyal

    David Howells
     

05 Aug, 2015

1 commit


04 Aug, 2015

2 commits