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



-
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-28 08:21    [W:0.205 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site