From: Rusty Russell <rusty@ozlabs.org>
To: David Howells <dhowells@redhat.com>
Cc: dhowells@redhat.com, keyrings@linux-nfs.org,
linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, dmitry.kasatkin@intel.com,
zohar@linux.vnet.ibm.com, arjan.van.de.ven@intel.com,
alan.cox@intel.com
Cc: Jon Masters <jcm@jonmasters.org>
Subject: Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]
Date: Sat, 10 Dec 2011 17:31:15 +1030 [thread overview]
Message-ID: <8739csq5ac.fsf@rustcorp.com.au> (raw)
In-Reply-To: <2657.1323456206@redhat.com>
On Fri, 09 Dec 2011 18:43:26 +0000, David Howells <dhowells@redhat.com> wrote:
> Rusty Russell <rusty@ozlabs.org> wrote:
>
> > And adds a great deal of code in a supposedly security-sensitive path to
> > achieve it.
> >
> > How about simply append a signature to the module? That'd be about 20 lines
> > of code to carefully check the bounds of the module to figure out where the
> > signature is. You could even allow multiple signatures, then have one for
> > stripped, and one for non-stripped versions.
>
> A big chunk of the code is dealing with the cryptographic bits - and you need
> those anyway - and if it's done right it can be shared with other things
> (eCryptfs for example; maybe CIFS from what Steve French said) and auxiliary
> keys can be stored in places other than the kernel (the TPM for
> example).
Sure, I was only commenting on the module parts, which are my
responsibility.
> > Sure, you now need to re-append that after stripping, but that's not the
> > kernel's problem.
>
> You may also have to remove the signature before passing it to any
> binutils tool lest it malfunction on the trailer
Well, you're already on your own if you're using non-module-init-tools
tools on modules. But objdump doesn't care about appended data.
objcopy and strip will remove it, of course, but without complaining.
> - and would you also
> have to modify insmod and modprobe? I suspect they parse the ELF to
> find out about parameters and things.
No. modprobe needs to read .modinfo for --force, and modinfo does too.
depmod is the worst: it actually looks through symtab and strtab, etc.
And again, they're all fine.
But even if they weren't, it wouldn't be an argument for putting all
this in the kernel!
(We'll want to enhance modinfo, at least, to show the signatures).
> I've found that rpmbuild and mkinitrd alter the module files at
> various times, so you'd need a bunch of signatures, one for each (may
> just be two, but I can't guarantee that). This means the kernel build
> process needs to know what transformations are going to be applied to
> a module - something that has changed occasionally within the
> distribution I use and may vary between distributions (or even just
> someone building for themselves).
Yes, there may be more than stripped and unstripped. You may need to
do fancy things. But now, adding a signature is so easy that it's not a
real problem. And we can always have a hook, like:
if VARIANTS=`make-module-variants $MOD`; then
for m in $VARIANTS; do sign $m >> $MOD; rm $m; done
fi
Cheers,
Rusty.
next prev parent reply other threads:[~2011-12-10 7:05 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 18:42 [RFC][PATCH 00/21] Crypto keys and module signing [ver #3] David Howells
2011-12-02 18:42 ` [PATCH 01/21] MPILIB: Export some more symbols " David Howells
2011-12-02 18:42 ` [PATCH 02/21] MPILIB: Add a missing ENOMEM check " David Howells
2011-12-02 18:43 ` [PATCH 03/21] KEYS: Permit key_serial() to be called with a const key pointer " David Howells
2011-12-02 18:43 ` [PATCH 04/21] KEYS: Move the key config into security/keys/Kconfig " David Howells
2011-12-02 18:43 ` [PATCH 05/21] KEYS: Announce key type (un)registration " David Howells
2011-12-02 18:43 ` [PATCH 06/21] KEYS: Reorganise keys Makefile " David Howells
2011-12-02 18:43 ` [PATCH 07/21] KEYS: Create a key type that can be used for general cryptographic operations " David Howells
2012-01-16 12:53 ` Mimi Zohar
2012-01-17 15:32 ` David Howells
2012-01-18 10:56 ` Kasatkin, Dmitry
2011-12-02 18:44 ` [PATCH 08/21] KEYS: Add signature verification facility " David Howells
2012-01-18 11:20 ` Kasatkin, Dmitry
2012-01-18 12:26 ` David Howells
2012-01-18 13:26 ` Kasatkin, Dmitry
2012-01-18 15:13 ` David Howells
2012-01-18 15:20 ` Kasatkin, Dmitry
2012-01-18 15:20 ` Kasatkin, Dmitry
2012-01-18 19:59 ` David Howells
2012-01-20 1:52 ` Herbert Xu
2012-01-20 1:52 ` Herbert Xu
2011-12-02 18:44 ` [PATCH 09/21] KEYS: Asymmetric public-key algorithm crypto key subtype " David Howells
2011-12-02 18:44 ` [PATCH 10/21] KEYS: DSA signature verification algorithm " David Howells
2011-12-02 18:44 ` [PATCH 11/21] KEYS: RSA " David Howells
2011-12-02 18:44 ` [PATCH 12/21] PGPLIB: PGP definitions (RFC 4880) " David Howells
2011-12-02 18:45 ` [PATCH 13/21] PGPLIB: Basic packet parser " David Howells
2011-12-02 18:45 ` [PATCH 14/21] PGPLIB: Signature " David Howells
2011-12-02 18:45 ` [PATCH 15/21] KEYS: PGP data " David Howells
2011-12-02 18:45 ` [PATCH 16/21] KEYS: PGP-based public key signature verification " David Howells
2012-01-18 11:36 ` Kasatkin, Dmitry
2012-01-18 12:49 ` David Howells
2012-01-18 13:34 ` Kasatkin, Dmitry
2012-01-18 13:34 ` Kasatkin, Dmitry
2011-12-02 18:46 ` [PATCH 17/21] KEYS: PGP format signature parser " David Howells
2011-12-02 18:46 ` [PATCH 18/21] KEYS: Provide a function to load keys from a PGP keyring blob " David Howells
2011-12-02 18:46 ` [PATCH 19/21] MODSIGN: Add indications of module ELF types " David Howells
2011-12-02 18:46 ` [PATCH 20/21] MODSIGN: Module ELF verifier " David Howells
2011-12-02 18:46 ` [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load " David Howells
2011-12-09 11:18 ` Rusty Russell
2011-12-09 18:43 ` David Howells
2011-12-10 7:01 ` Rusty Russell [this message]
2011-12-10 14:08 ` David Howells
2011-12-11 4:57 ` Rusty Russell
2011-12-12 1:21 ` David Howells
2011-12-12 9:09 ` Rusty Russell
2011-12-12 16:11 ` David Howells
2011-12-13 2:15 ` Rusty Russell
2011-12-15 0:14 ` David Howells
2011-12-16 0:41 ` Rusty Russell
2011-12-10 18:37 ` Arjan van de Ven
2011-12-11 4:59 ` Rusty Russell
2012-01-08 22:02 ` [RFC][PATCH 00/21] Crypto keys and module signing " Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8739csq5ac.fsf@rustcorp.com.au \
--to=rusty@ozlabs.org \
--cc=alan.cox@intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@intel.com \
--cc=keyrings@linux-nfs.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.