Message-ID: <87wr2yswts.fsf@rustcorp.com.au>
Date:	Sat, 23 Jun 2012 09:50:31 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	David Howells <dhowells@...hat.com>
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

On Fri, 22 Jun 2012 12:03:13 +0100, David Howells <dhowells@...hat.com> wrote:
> 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?

True, if mkinitrd strips the module, it will break the signature.

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

Sure, but that's kind of independent of what Greg was asking.

> 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).

Userspace a bit more complex.  Kernel simpler.  Win.

> > 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

OK, s/far//.  We already rely on objcopy for kernel builds, so no
additional requirements.

> > 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.

No, that was more complex and tasteless.

> > 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.

I've been tempted to search for a hole in your parsing code.  But while
finding one would be satisfying, not finding one isn't conclusive.  So
it's a waste of time.

> 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.

Wouldn't it be nice if strip removed nop padding at the end of text
sections?

Cheers,
Rusty.
--
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