Re: Where's the key management patchset at?

[David Howells]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/