Messages in this thread | | | Subject | Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library | From | Trond Myklebust <> | Date | Sun, 29 Jan 2006 16:46:05 -0500 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |