1. 14 8月, 2015 5 次提交
  2. 13 8月, 2015 13 次提交
    • D
      sign-file: Fix warning about BIO_reset() return value · e9a5e8cc
      David Howells 提交于
      Fix the following warning:
      
      	scripts/sign-file.c: In function ‘main’:
      	scripts/sign-file.c:188: warning: value computed is not used
      
      whereby the result of BIO_ctrl() is cast inside of BIO_reset() to an
      integer of a different size - which we're not checking but probably should.
      Reported-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      e9a5e8cc
    • D
      PKCS#7: Add MODULE_LICENSE() to test module · 772111ab
      David Howells 提交于
      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: NJames Morris <jmorris@namei.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      772111ab
    • C
      Smack - Fix build error with bringup unconfigured · 3d04c924
      Casey Schaufler 提交于
      The changes for mounting binary filesystems was allied
      improperly, with the list of tokens being in an ifdef that
      it shouldn't have been. Fix that, and a couple style issues
      that were bothering me.
      Reported-by: NJim Davis <jim.epost@gmail.com>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      3d04c924
    • D
      sign-file: Document dependency on OpenSSL devel libraries · 228c37ff
      David Howells 提交于
      The revised sign-file program is no longer a script that wraps the openssl
      program, but now rather a program that makes use of OpenSSL's crypto
      library.  This means that to build the sign-file program, the kernel build
      process now has a dependency on the OpenSSL development packages in
      addition to OpenSSL itself.
      
      Document this in Kconfig and in module-signing.txt.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      228c37ff
    • 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
    • D
      KEYS: Add a name for PKEY_ID_PKCS7 · f29299b4
      David Howells 提交于
      Add a name for PKEY_ID_PKCS7 into the pkey_id_type_name array.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f29299b4
    • D
      PKCS#7: Improve and export the X.509 ASN.1 time object decoder · fd19a3d1
      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: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      fd19a3d1
    • D
      modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS · 770f2b98
      David Woodhouse 提交于
      Fix up the dependencies somewhat too, while we're at it.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      770f2b98
    • D
      extract-cert: Cope with multiple X.509 certificates in a single file · 84706caa
      David Woodhouse 提交于
      This is not required for the module signing key, although it doesn't do any
      harm — it just means that any additional certs in the PEM file are also
      trusted by the kernel.
      
      But it does allow us to use the extract-cert tool for processing the extra
      certs from CONFIG_SYSTEM_TRUSTED_KEYS, instead of that horrid awk|base64
      hack.
      
      Also cope with being invoked with no input file, creating an empty output
      file as a result.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      84706caa
    • D
      sign-file: Generate CMS message as signature instead of PKCS#7 · ed8c2076
      David Howells 提交于
      Make sign-file use the OpenSSL CMS routines to generate a message to be
      used as the signature blob instead of the PKCS#7 routines.  This allows us
      to change how the matching X.509 certificate is selected.  With PKCS#7 the
      only option is to match on the serial number and issuer fields of an X.509
      certificate; with CMS, we also have the option of matching by subjectKeyId
      extension.  The new behaviour is selected with the "-k" flag.
      
      Without the -k flag specified, the output is pretty much identical to the
      PKCS#7 output.
      
      Whilst we're at it, don't include the S/MIME capability list in the message
      as it's irrelevant to us.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-By: David Woodhouse <David.Woodhouse@intel.com
      ed8c2076
    • D
      PKCS#7: Support CMS messages also [RFC5652] · 60d65cac
      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: NDavid Howells <dhowells@redhat.com>
      Reviewed-By: NDavid Woodhouse <David.Woodhouse@intel.com>
      60d65cac
    • D
      X.509: Change recorded SKID & AKID to not include Subject or Issuer · a4c6e57f
      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: NDavid Howells <dhowells@redhat.com>
      Reviewed-By: NDavid Woodhouse <David.Woodhouse@intel.com>
      a4c6e57f
    • D
      PKCS#7: Check content type and versions · 2c7fd367
      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: NDavid Howells <dhowells@redhat.com>
      Reviewed-By: NDavid Woodhouse <David.Woodhouse@intel.com>
      2c7fd367
  3. 12 8月, 2015 1 次提交
  4. 11 8月, 2015 2 次提交
  5. 07 8月, 2015 18 次提交
  6. 05 8月, 2015 1 次提交
    • D
      ASN.1: Handle 'ANY OPTIONAL' in grammar · 233ce79d
      David Howells 提交于
      An ANY object in an ASN.1 grammar that is marked OPTIONAL should be skipped
      if there is no more data to be had.
      
      This can be tested by editing X.509 certificates or PKCS#7 messages to
      remove the NULL from subobjects that look like the following:
      
      	SEQUENCE {
      	  OBJECT(2a864886f70d01010b);
      	  NULL();
      	}
      
      This is an algorithm identifier plus an optional parameter.
      
      The modified DER can be passed to one of:
      
      	keyctl padd asymmetric "" @s </tmp/modified.x509
      	keyctl padd pkcs7_test foo @s </tmp/modified.pkcs7
      
      It should work okay with the patch and produce EBADMSG without.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      233ce79d