Re: [RFC][PATCH v1 0/2] integrity: module integrity verification

[David Howells]

Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:

> As a distro knows what it is shipping, why would you need support for
> both stripped/unstripped versions.  Unless "stripping" occurs post
> install.  Perhaps something similar to 'prelink'?

Let me summarise the state of things.


In RHEL and Fedora the stripping occurs twice that I know of:

 (1) During package generation the debugging info in each module file is
     extracted into a separate file in a 'debuginfo' RPM and is then stripped
     from the module binary.

 (2) During initramfs generation, the module files are further stripped to get
     rid of all unnecessary bulk.

I'm told that step (1) can be waived - but that means that the installed module
still has all its debug info in it, and thus uses up more filesystem space.


Red Hat already have a working module signature checker that we've been using
for a few years.  However, it incorporates the signature *in* the module file,
using ELF's ability as a container format to carry it in an ELF note.

This has the downside that the kernel then has to determine that the ELF is
sufficiently valid that it's safe to parse it to find the signature note.

The checker is also robust enough that the module survives being stripped a
number of times by tools from a different packages (strip and eu-strip), but
the cost of this is that the kernel has to limit and canonicalise the data it
adds to the signature.

Basically, this checker hasn't required to need any alterations to userspace
tools outside of the kernel sources (eg. busybox, modprobe, insmod, mkinitrd,
strip, kernel rpm specfile, ...) to generate signed modules that can be
checked, and doesn't require any special filesystem features (such as xattrs),
hardware (such as a TPM) or auxiliary files to hold signatures.


However, Rusty doesn't like the RH checker because it is a largish chunk of
code that needs careful checking:

	warthog>size module-verify.o module-verify-elf.o module-verify-sig.o
	   text    data     bss     dec     hex filename
	    170       0       0     170      aa kernel/module-verify.o
	   2351       0       0    2351     92f kernel/module-verify-elf.o
	   2390      32      20    2442     98a kernel/module-verify-sig.o

plus a bit in kernel/module.o on x86_64.

He would prefer to see something that just appends the signature with a magic
number and then the kernel just has to search for the magic number and digest
the entirety of the blob up to that point.  You don't then need to check the
ELF as the validity of the ELF structure is then guaranteed by the signature.

The main downside of this approach is that the signature is only good as long
as the ELF module is not modified anywhere - and this mean no stripping.  If
the unstripped, semi-unstripped and fully stripped modules are all necessary,
then they must all be included in the package, and any variant that is going to
be loaded (which may perhaps only be the fully-stripped variant) must be
signed.  Another problem is recognising the signature marker correctly as it's
conceivably possible for the assembler to generate the same string (there are
ways round that, however).


As I understand it, Dmitry's approach is similar to Rusty's except the
signature is determined by userspace (eg. insmod) and passed to the kernel
separately as a special argument to insmod.  This allows Dmitry to store the
signature separately, say in an xattr on the module file or in some special
hardware.

The downsides of this approach are similar to Rusty's, and have the additional
problem that insmod & co. may need to implement multiple methods for finding
the signature (are there xattrs in the initramfs, for example?).

However, if there is a real requirement to store the signature detached from
the module (say in a cryptographic hardware cache), then Dmitry's approach may
be the only viable one, and userspace can look through the module file for an
inline signature, and, if found, detach it and give the signature and the
remnant blob to the kernel separately.


At some point I intend to look at integrating Dmitry's stuff with my signature
handling patches to see if we can make a unified system that can handle the
signature being done in software or in hardware, and with any combination of
digest and asymmetric key algorithm.  On that basis, if we can't go with RH's
module signature checker, I'd prefer Dmitry's approach over Rusty's and do the
signature retrieval in userspace.

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