Re: Where's the key management patchset at?

From: Andy Lutomirski
Date: Fri Sep 10 2004 - 23:57:30 EST


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/