lkml.org 
[lkml]   [2006]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library
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 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/

\
 
 \ /
  Last update: 2006-01-29 22:33    [from the cache]
©2003-2011 Jasper Spaans