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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 29, 2006 at 02:10:46PM -0500, Trond Myklebust wrote:
On Sun, 2006-01-29 at 11:49 -0700, Dax Kelson wrote:
Has anyone tried to look for simpler signing mechanisms that make use of
the crypto algorithms that are already in the kernel?

Maybe you meant something else, but history has shown that 'rolling your own' mechanism is a bad idea.

Are there even any suitable algorithms in the kernel??

I'm suggesting that if the only real problem that dsa in the kernel
solves is module signing, then perhaps one can simplify the problem.

For instance, if instead of going for a general signing mechanism in the
kernel that will take any old module and verify it, you define a
particular binary as being trusted, and then devise a signature that the
kernel can check (even the SHA-1 of the binary image might be
sufficient).
The object would be to give the kernel a trusted program that can check
module signatures on its behalf.

Today, if a security bug is found in the kernel, you have to compile and install a new kernel.

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.

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).

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?

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?).

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

Regards,
David

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux