Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Sun, 2006-01-29 at 22:29 +0100, David Härdeman wrote:
> With your system, the signature of a "trusted" binary is embedded in the 
> kernel. Now, if a bug is found in said binary, you also get to compile 
> and install a new kernel along with a new binary.

If you compile a SHA-1 signature directly into the kernel, yes.
Alternatively, you could for instance allow it to be set once and only
once upon boot.

> Since the application is trusted, a security hole in the binary equals a 
> security hole in the kernel. In addition, you are bound to a given 
> kernel <-> userspace ABI, so if it has to be changed, you get to keep 
> several different trusted binaries around for different kernel versions 
> (/sbin/module-validate-v1 for ABI version 1, /sbin/module-validate-v2 
> for ABI version 2, etc).

See modprobe. We already have that sort of dependency.

> Further, how is the module actually verified? If the trusted binary 
> reads it and checks "something" (i.e. a signature), and then says it's 
> ok, what is to say that the module is not changed on-disk between the 
> time when the binary reads it and when the kernel does so (for instance 
> by direct access to the disk). How do you expect the system to provide 
> security if you are running with nfs-root?

You have to verify the module _after_ it has been loaded into the
kernel, but before any code has been run. No difference there between a
userspace and a kernel space solution.

> In addition you must protect the user-space binary against a slew of 
> attacks (you did statically link it to protect against LD_PRELOAD, right?).

I assume so.

> What exactly is the advantage of user-space trusted binary signing?

Umm... No unnecessary junk in the kernel when you are not loading in
modules? Greater possible choice of signing mechanisms? Support for
revoking signatures?

Cheers,
  Trond