linux-kernel - Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Dec 2011 14:08:34 +0000
From:	David Howells <dhowells@...hat.com>
To:	Rusty Russell <rusty@...abs.org>
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]

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.

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

So the number of signatures is:

	strip_combos × binutils_variations × other_factors

and you have to generate all these at kernel build time because the secret key
cannot be disseminated to the installed machines that might be affected by
this.

(Note that binutils may rearrange the symbol, relocation and section tables in
different ways for different versions.)

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/