Module signing with PKCS#7
PKCS#7: Appropriately require or forbid authenticated attributes

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 three options:

     (A) Require pkcs7_data type content and forbid authattrs entirely.

     (B) Require pkcs7_data type content and require authattrs but to
     	 reject Microsoft Authenticode authattrs.

     (C) Require an Authenticode type content (only indirect data is
     	 currently supported) and permit/require certain Authenticode
     	 authattrs.

 (4) Have module verification choose option (A) above.  This means that
     with module signing, the signature is over the content digest only.
     sign-file sets CMS_NOATTR to suppress authattrs.  We could be more
     flexible and permit (A) or (B) for module signing.

 (5) Have kexec verification of PE executables choose option (C) above.  We
     may need to relax this if signed PE files may be encountered that
     don't have authattrs in their PKCS#7 message.

     Kexec does not currently verify non-PE executables - but if this is
     added in the future it should probably use option (A).

 (6) The pkcs7_test key type is given a module parameter to select between
     the above options for testing purposes.

Future patches add firmware signing support.  Firmware signing will require
a signed authattr containing the firmware name as passed to
request_firmware() and so would pick option (B) above, but we would also
need to permit the firmware name authattr.

Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
10 files changed