Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux