From: Kyle Moffett <mrmacman_g4@mac.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: "David Härdeman" <david@2gen.com>,
"David Howells" <dhowells@redhat.com>,
"Christoph Hellwig" <hch@infradead.org>,
keyrings@linux-nfs.org,
"LKML Kernel" <linux-kernel@vger.kernel.org>,
"Adrian Bunk" <bunk@stusta.de>
Subject: Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library
Date: Sat, 28 Jan 2006 02:17:49 -0500 [thread overview]
Message-ID: <DEA6D91F-9925-47E3-8A93-3D0C7D7F8CDA@mac.com> (raw)
In-Reply-To: <1138419925.8770.70.camel@lade.trondhjem.org>
On Jan 27, 2006, at 19:22, Adrian Bunk wrote:
> On Fri, Jan 27, 2006 at 09:41:58PM +0100, David Härdeman wrote:
>> The in-kernel key management also protects the key against many of
>> the different ways in which a user-space daemon could be attacked
>> (ptrace, swap-out, coredump, etc).
>
> If an attacker has enough privileges for attacking the daemon, he
> should usually also have enough privileges for attacking the kernel.
Not necessarily. If the daemon runs as the "backup" user or similar,
access to it does not imply root. We want to make an efficient way
to allow the _use_ of keys without implying access to the key data.
For example, one item under consideration is a "key handle" that
could be cloned, however if you revoke a given handle, all of its
cloned handles (and their clones), will be automatically revoked as
well. This would make it possible to pass a key to a program without
risking the key to compromise of that program. Say I pass my SSL key
to Mozilla. With this and some of the other new security features
(One of the code-isolation ones I think?), you could allow Mozilla to
use SSL websites without risking compromise of the SSL keys because
of a browser security hole.
On Jan 27, 2006, at 22:45, Trond Myklebust wrote:
> On Fri, 2006-01-27 at 18:35 -0500, Kyle Moffett wrote:
>
>> No, the point is not to put the backup daemon into the kernel, but
>> to provide a way for the backup daemon and my user process to
>> communicate DSA key details without completely giving the backup
>> daemon my key. I may not entirely trust the backup daemon not to
>> get compromised, but with support for the kernel keyring system,
>> compromising the backup daemon would only compromise the backed up
>> files, not the private keys and other secure data.
>
> This sort of thing is implemented routinely in user space by means
> of proxy tickets/certificates/credentials. What makes them
> insufficient for this use?
The problem is that there is no standard way to store/use the keys.
I can put my key in an ssh-agent to handle SSH, but that doesn't let
me securely auth mozilla. To do that, I need to explore how mozilla
configs work. And there are similar problems with context for
Kerberos, OpenAFS, encrypted filesystems, etc. You need to have a
common standardized way to pass the secure information around. This
provides that interface.
Cheers,
Kyle Moffett
--
Simple things should be simple and complex things should be possible
-- Alan Kay
next prev parent reply other threads:[~2006-01-28 7:18 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 [this message]
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
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=DEA6D91F-9925-47E3-8A93-3D0C7D7F8CDA@mac.com \
--to=mrmacman_g4@mac.com \
--cc=bunk@stusta.de \
--cc=david@2gen.com \
--cc=dhowells@redhat.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).