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 [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]
