Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 9月, 2015 1 次提交
  3. 28 8月, 2015 1 次提交
  5. 27 8月, 2015 1 次提交
  7. 26 8月, 2015 1 次提交
  9. 15 8月, 2015 1 次提交
  11. 14 8月, 2015 5 次提交
  13. 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
  15. 12 8月, 2015 1 次提交
  17. 11 8月, 2015 2 次提交
  19. 07 8月, 2015 14 次提交