Re: Where's the key management patchset at?

Andy Lutomirski
2004-09-11T04:55:55Z

David Howells wrote:

>>Second, is there a way for a process/user to have "use but not read"
>>access so it could pass the key to a different _userspace_ process
>>(probably a daemon running as root) that wants to read it? This would
>>be nice for all kinds of things (like ssh agents and such).
>
>
> That depends on what you mean by "use but not read" access.
>
> Keys now have five permissions (View, Link, Write, Read, Search) and these can
> be applied to user, group or other.
>
> An in-kernel service just requires Search (Use) permission to be able to use a
> key. It calls request_key() to come up with a key from the process's keyrings
> or from userspace.
>
> I'll probably have to do it by passing a new type of SCM message over
AF_UNIX
> sockets - one that attaches a key and can drop it into the process's
thread
> keyring.
>

I mean that a process would have be permitted to "use" a key (whatever
that means) but have no right to read the contents, delegating the
reading to a second process. This way a process could delegate the act
of seeing the key contents (computing a signature, for example) to a
trusted process, limiting the damage if the key-holding program is
compromised. This also might allow smart-cards to fit into the model
(where "use" makes sense but "read" is meant to be physically impossible).

Maybe one way to do this is to have a second UID attached to the key
(with its corresponding permission mask), the restriction that Read
without Search is forbidden and the exception that Search is implied by
a key's presence in a keyring. You'd also need to prevent the key owner
from changing the key's permissions if the owner doesn't have Read.

So my hypothetical ssh agent-like program has a key with UID 500: VLS /
GID whatever: - / 2nd UID 100: R and a setuid-100 program that does
public-key ops on it. Then if the user's account is compromised, no one
gets the private key.

I'm out of town now, so I haven't actually tried any of this. I'll take
a look at the code next week.

--Andy