Re: Where's the key management patchset at?

[Andy Lutomirski <luto@myrealbox.com>]

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