Subject: [PATCH 0/3] MODSIGN: Use PKCS#7 cert to avoid SKIDs
From: David Howells <dhowells@redhat.com>
To: rusty@rustcorp.com.au
Cc: dhowells@redhat.com, linux-security-module@vger.kernel.org,
        keyrings@linux-nfs.org, linux-kernel@vger.kernel.org
Date: Fri, 03 Oct 2014 15:30:12 +0100
Message-ID: <20141003143012.26457.54004.stgit@warthog.procyon.org.uk>
User-Agent: StGit/0.17-dirty
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org


Hi Rusty,

In the current module signing code, we try to use the subject and subjKeyId
fields from X.509 certificate representing the key used to sign the modules to
locate the X.509 certificate containing the public key required to verify the
signature.

Unfortunately, we have situations where we have to deal with signatures
generated from keys that don't have a subjKeyId (it is, after all, optional in
the X.509 spec for none CA keys).

Now that we have PKCS#7 message handling code in the kernel for kexec(), we can
make use of this for module signing.  By using a PKCS#7 message with detached
data and no embedded X.509 certs as the signature blob, we can forgo specifying
all the signature parameters (eg. hash algo, pubkey algo, name, id) elsewhere
and rely instead on the PKCS#7 message to supply all of those.

PKCS#7 doesn't use the subjKeyId, but rather matches issuer name and
certificate serial number, both of which are mandatory in an X.509 certificate.

We leave out the embedded X.509 certs to make the signature smaller and use
detached data so that we don't have to put the module content in there.

The patches are as follows:

 (1) Provide a function to pass detached data to the PKCS#7 verifier, rather
     than always requiring the data to be contained therein.

 (2) Provide a utility to sign modules (a drop-in replacement for
     scripts/sign-file).  This does need to be built against -lcrypto from
     OpenSSL.  I couldn't work out how to make a PKCS#7 message with no
     embedded X.509 certs from the openssl command line.

     I also haven't provided a way to externally specify the signature - that's
     something that will need to be worked out.  Quite likely it will involve
     taking a PKCS#7 message rather than generating one.

 (3) Make use of the above and the PKCS#7 handling to sign modules and verify
     signatures.

Note that this does make signatures generated by previous kernels incompatible
with newer kernels, but since the modules being signed may no longer be
compatible anyway for other reasons, I'm not sure how much of a problem that
will actually be.

I have provided a function, mod_verify_pkcs7(), that takes a buffer containing
the actual module data, sans signature, and a buffer containing the PKCS#7
message that does the actual work.  This could be called, for instance, if
modules are ever loaded with detached signatures.

The patches can be found here also:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7

This is based on James Morris's security/next branch as there are some keyring
and PKCS#7 changes in there that are prerequisites for this.

David
---
David Howells (3):
      PKCS#7: Allow detached data to be supplied for signature checking purposes
      MODSIGN: Provide a utility to append a PKCS#7 signature to a module
      MODSIGN: Use PKCS#7 messages as module signatures


 crypto/asymmetric_keys/pkcs7_verify.c |   26 ++
 include/crypto/pkcs7.h                |    3 
 include/crypto/public_key.h           |    1 
 init/Kconfig                          |    1 
 kernel/module_signing.c               |  220 +++--------------
 scripts/Makefile                      |    2 
 scripts/sign-file                     |  421 ---------------------------------
 scripts/sign-file.c                   |  189 +++++++++++++++
 8 files changed, 266 insertions(+), 597 deletions(-)
 delete mode 100755 scripts/sign-file
 create mode 100755 scripts/sign-file.c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/