Re: Where's the key management patchset at?

Re: Where's the key management patchset at?

[David Howells]

> So
> 
> a) Why should we merge keyfs?

A bunch of people out there (viro, hch, jamesm for example) think they want
it, and in fact think that there shouldn't be any other interface. I've also
had emails of random people saying there absolutely has to be a filesystem
interface so they can as administrators go and rummage around in the key
database, though I suspect they're going to be disappointed in keyfs as it'll
only let them see those keys they've a right to do something with.

I'd like to dispense with keyfs. The semantics of the key database don't map
to the VFS, hence the fact we have to present the key database as a flat
directory and why I have to make use of a bunch of undocumented esoteric fs
ops.

I'd also like keyfs to remain optional at best. It's a large chunk of code
that is completely unnecessary, and on an embedded system it's something you'd
probably want to do without. It could be made a module, I suppose, to be
loaded on demand.

> b) Are people likely to use the APIs frequently enough for its
>    performance to matter?

Now that's harder to judge...

Performance is going to matter very much from the point of view of a
filesystem that wants a key. It's probably going to be checking for a key on
every open call. However, that's mostly taken care of by the internal kernel
API, and the userspace interface has little impact upon that, except where the
request-key callout is concerned.

Performance may also matter from the point of view of userspace service
programs (AFS requires a few of these), though in this case you should only
need to do one lookup per invocation of the program.

So, for most userspace operations wrt to keys, performance isn't a problem;
however, for certain systems, size _is_ a problem and in those cases keyfs is
a liability.

And, before anyone asks, yes, the problem of kernel size is something I've had
to contend with.

David

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

Re: Where's the key management patchset at?

[Andy Lutomirski]

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

Re: Where's the key management patchset at?

[Andrew Morton]

David Howells <dhowells@redhat.com> wrote:
>
> I'd like to dispense with keyfs.

Let's do that then.  I'll keep the patch alive in -mm.  If someone can come
along and demonstrate a solid reason for needing keyfs then we can
reevaluate.