Messages in this thread | | | From | David Howells <> | Subject | Re: Where's the key management patchset at? | Date | Tue, 07 Sep 2004 19:30:10 +0100 |
| |
> First, I can't find the patch. > http://people.redhat.com/~dhowells/keys/keys-268rc4mm1.diff seems to be > a diff between two diff between two different versions of the key stuff.
My patches are currently residing in Andrew Morton's kernel, so if you grab his 2.6.9-rc1-mm4 patch you'll find them there. Look in:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc1/2.6.9-rc1-mm4/
The patch includes documentation in Documentation/keys.txt.
> 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.
"Using" a key from userspace is tricky. We want to stop random processes from reading your keys if they don't have Read permission, but it might be necessary to _read_ the key to make use of it:-/
Although userspace could find a key given that that's governed by Search permission it can't necessarily read it. I've added in a "bypass" so that if a key is Searchable from one of a userspace process's process keyrings then it's allowed to read it, even if it doesn't have Read permission. This allows keys to be added through to SUID programs - you create your keyrings and your key with Search permission and the SUID programs can then access them in userspace.
I haven't yet created a method for one process to hand a key to another, short of linking the key directly into one of the target process's keyrings.
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 may also need to follow up on Kyle Moffett's suggestion and make a distinction between a key and its handle:
HANDLE KEY
+---------+ | Serial# | | UID/GID |--------+ | Perm | | +---------+ | | +----------+ +---------+ | | Owner | | Serial# | +-------->| Type | | UID/GID |----------------->| Desc | | Perm | +-------->| Payload | +---------+ | | | | +----------+ +---------+ | | Serial# | | | UID/GID |--------+ | Perm | +---------+
Handles would then be clonable and individually revokable, giving the opportunity to create handles for specific purposes, possibly even "personalised" for specific processes rather than UID/GID. I'd then add a "Clone" permission to the permissions mask.
The "number of keys" quota value would then count handles instead.
I've tried to implement this once before... it adds quite a bit of complexity to the code, and makes locking interesting in places.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |