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 17:31:15 +1030
From:	Rusty Russell <rusty@...abs.org>
To:	David Howells <dhowells@...hat.com>
Cc:	Jon Masters <jcm@...masters.org>
Subject: Re: [PATCH 21/21] MODSIGN: Apply signature checking to modules on module load [ver #3]

On Fri, 09 Dec 2011 18:43:26 +0000, David Howells <dhowells@...hat.com> wrote:
> Rusty Russell <rusty@...abs.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.
--
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/