Message-ID: <25337.1340362993@redhat.com>
Date:	Fri, 22 Jun 2012 12:03:13 +0100
From:	David Howells <dhowells@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	dhowells@...hat.com, Greg KH <gregkh@...uxfoundation.org>,
	kyle@...artin.ca, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Re: [PATCH 00/23] Crypto keys and module signing

Rusty Russell <rusty@...tcorp.com.au> wrote:

> 1) No userspace needs to be modified to use the appended signature.
>    modprobe doesn't.  depmod doesn't.  Even strip doesn't (not that
>    that's much use).

Anything that currently automatically strips the module: mkinitrd perhaps?

If we use a new system call, then the list includes a few more things.

Your idea of providing multiple variants of the module, each signed and each
with different levels of strippedness makes things more complicated - both at
build/package generation time and at usage time (where 'use' may be loading
the module or packaging it into a initrd).

> 2) It's far easier to add an appended signature than to add an elf
>    section.

That's not true.  That bit of complexity in my implementation comes because
I'm adding it as an ELF Note - which someone suggested I should do instead of
just using an unstructured section.

If we reverted to an unstructured section, it's just one objcopy command, eg:

	objcopy \
		--add-section .modsign=/etc/redhat-release \
		--set-section-flags .modsign=load \
		/bin/ls /tmp/ls

And for debugging purposes, removing it is:

	objcopy \
		-R .modsign \
		/bin/ls /tmp/ls

> 3) It's far easier to generate an appended signature than to generate
>    a signature for the module which will change when you add the
>    signature section (roughly: gpg --sign module.ko > sig && echo
>    '@@sig@@ >> module.ko && cat sig >> module.ko).

You would be better off putting the magic number last and including a length
field right before.  That's much more efficient and much simpler.

> 4) It's trivial to verify a module with an appended signature before you
>    touch it.  With a section you need to carefully parse the module,
>    make sure you don't include the could-be-modified stuff in the
>    signature, and avoid any possible overflows or exploits.

I have to say that here Rusty is correct.  If the signature is embedded in the
ELF, then the ELF needs a bit of careful checking first.  But, excluding the
crypto bits which are the same in all cases, I managed to get the entire ELF
parser/checker/canonicaliser, digest extractor and policy determiner down to a
little over 2K of x86_64 code.

Since the ELF loader/linker has to parse much of this stuff anyway, it might
be possible to combine the two to some extent.

> 5) It wasn't just that they wanted an elf section.  They wanted the
>    signature to work against both a stripped and unstripped module, so
>    only the unstrippable parts of the module were signed.

Yes.  Those are the bits that the module loader needs...

This is quite a good a trade off.  It simplifies building and installation a
lot.  There is only one binary for each module.  That binary can be stripped
quite aggressively - any strip that would ordinarily leave the module
functional won't affect the signature verification.  Any content or metadata
change that affects the module's operational code and data is detected.

> > And I think we really want the ability to have multiple signatures, the
> > whole "chain of trust" thing that is needed will work out much better if
> > multiple signatures are allowed.  Putting it in an elf section allows
> > this to work out easier, right?
> 
> Not at all.  Multiple appended signatures is trivial.  Figuring out the
> semantics (do they chain, or is any one sufficient?), well that's the
> same whether you're talking about an ELF section or not.

Agreed, it makes no difference either way.

But it doesn't necessarily work with a new syscall that has an extra pair of
args for passing a signature.  The kernel really wants to have all the
available sigs available in one go so that it can implement its policy (which
might be to panic in FIPS mode).

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

Powered by blists - more mailing lists