Message-ID: <87obvfogc6.fsf@rustcorp.com.au>
Date:	Sun, 11 Dec 2011 15:27:45 +1030
From:	Rusty Russell <rusty@...abs.org>
To:	David Howells <dhowells@...hat.com>
Cc:	dhowells@...hat.com, keyrings@...ux-nfs.org,
	linux-crypto@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, dmitry.kasatkin@...el.com,
	zohar@...ux.vnet.ibm.com, arjan.van.de.ven@...el.com,
	alan.cox@...el.com, Jon Masters <jcm@...masters.org>
Subject: Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Sat, 10 Dec 2011 14:08:34 +0000, David Howells <dhowells@...hat.com> wrote:
> Rusty Russell <rusty@...abs.org> wrote:
> 
> > > > 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.
> 
> The distributions packaging tools and initramfs tools are things I have to
> contend with, and others will have to contend with.

If they're doing weird things to modules, yep, they'll break.  They're
not supposed to, but I know these things happen.  But I'll need more
than speculation, we'll need examples.

> > (We'll want to enhance modinfo, at least, to show the signatures).
> 
> Ummm...  To show what exactly?  And why?  The modinfo has to go into the
> signature hash.  Further to find the modinfo, you have to parse the ELF - which
> brings us right back to how do you know you can trust it?

I think you misunderstand, I'm talking about the modinfo command, not
the .modinfo section.

> > > 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
> 
> That's not very practical.  That spreads the what-do-we-need-to-calculate
> question over a whole bunch of packages: the kernel, rpmbuild (if RPM-based),
> mkinitramfs and maybe others.  I presume you're thinking of trying all the
> possible strip combinations and generating a signature for each?  However, if
> someone upgrades their binutils, but not their kernel, say, and then their
> initramfs gets rebuilt for some reason, this may invalidate all their module
> signatures.

I'm assuming you either guarantee that strip produces identical results,
or you generate all altered versions during the build (perhaps
make-module-variants has a place it can stash them in the kernel tree
where it gets rolled into your rpm).

But I need to know exactly what these version-dependent mangling of
modules is.  Is it real?  Is it more than strip?  Is it so hard to fix
that it makes sense to add 450 lines of dense kernel code to allow
alteration of a module after signing?

The answer may be "yes".  But I need to know that before accepting your
code.

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