From: "David Härdeman" <david@2gen.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Dax Kelson <dax@gurulabs.com>,
Christoph Hellwig <hch@infradead.org>,
keyrings@linux-nfs.org, linux-kernel@vger.kernel.org,
Adrian Bunk <bunk@stusta.de>
Subject: Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library
Date: Sun, 29 Jan 2006 22:29:15 +0100 [thread overview]
Message-ID: <20060129212915.GB20118@hardeman.nu> (raw)
In-Reply-To: <1138561846.8711.33.camel@lade.trondhjem.org>
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
next prev parent reply other threads:[~2006-01-29 21:29 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-26 21:58 [PATCH 00/04] Add DSA key type David Härdeman
2006-01-26 21:58 ` [PATCH 03/04] Add encryption ops to the keyctl syscall David Härdeman
2006-01-26 21:58 ` [PATCH 02/04] Add dsa crypto ops David Härdeman
2006-01-26 21:58 ` [PATCH 01/04] Add multi-precision-integer maths library David Härdeman
2006-01-27 9:28 ` Christoph Hellwig
2006-01-27 20:07 ` David Howells
2006-01-27 20:41 ` David Härdeman
2006-01-27 22:19 ` [Keyrings] " Trond Myklebust
2006-01-27 23:35 ` Kyle Moffett
2006-01-28 0:27 ` Adrian Bunk
2006-01-28 3:45 ` Trond Myklebust
2006-01-28 7:17 ` Kyle Moffett
2006-01-28 10:39 ` Adrian Bunk
2006-01-28 0:22 ` Adrian Bunk
2006-01-28 10:46 ` David Härdeman
2006-01-28 13:03 ` Adrian Bunk
2006-01-28 17:09 ` David Härdeman
2006-01-28 16:37 ` [Keyrings] " Trond Myklebust
2006-01-28 16:57 ` David Härdeman
2006-01-29 3:20 ` Trond Myklebust
2006-01-29 11:33 ` David Härdeman
2006-01-29 12:29 ` Adrian Bunk
2006-01-29 13:09 ` Arjan van de Ven
2006-01-29 20:05 ` Steve French
2006-01-29 20:52 ` Arjan van de Ven
2006-01-29 21:41 ` Steve French
2006-02-06 12:31 ` David Howells
2006-01-29 23:18 ` Adrian Bunk
2006-01-29 13:18 ` David Härdeman
2006-01-29 23:36 ` Adrian Bunk
2006-01-30 18:09 ` Nix
2006-01-29 16:38 ` Trond Myklebust
2006-01-29 18:49 ` Dax Kelson
2006-01-29 19:10 ` Trond Myklebust
2006-01-29 21:29 ` David Härdeman [this message]
2006-01-29 21:46 ` Trond Myklebust
2006-01-29 21:13 ` David Härdeman
2006-01-29 21:28 ` Trond Myklebust
2006-01-29 22:02 ` David Härdeman
2006-01-29 22:05 ` Trond Myklebust
2006-01-29 22:54 ` Kyle Moffett
2006-01-29 23:07 ` Trond Myklebust
2006-01-29 23:15 ` Adrian Bunk
2006-01-29 21:09 ` Pavel Machek
2006-01-26 21:58 ` [PATCH 04/04] Add dsa key type David Härdeman
2006-01-27 1:10 ` [PATCH 00/04] Add DSA " Herbert Xu
2006-01-27 7:18 ` David Härdeman
2006-01-27 20:11 ` David Howells
2006-01-27 23:22 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060129212915.GB20118@hardeman.nu \
--to=david@2gen.com \
--cc=bunk@stusta.de \
--cc=dax@gurulabs.com \
--cc=hch@infradead.org \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).