Re: In-kernel Authentication Tokens (PAGs)

[Kyle Moffett]

On Jun 16, 2004, at 10:49, David Howells wrote:
> Well, userspace can decide that a process should begin a new session. 
> I'd
> envision this as a user gets a session keyring for each login, and so 
> are able
> to use these to hold different sets of credentials that don't 
> interfere with
> each other.
>
> A UID keyring would be too pervasive - a key in there would affect 
> _every_
> process owned by that user - which might be undesirable.
>
> A process keyring wouldn't be pervasive enough. You couldn't, for 
> example, run
> aklog in your shell to get you an AFS token attached to the session, 
> use that
> token several times by running programs and then quit the shell to 
> dispose of
> the token. Each process wanting the token would have to get itself a 
> new token
> by contacting the Kerberos server.

What if we leave the concept of a key-ring as completely general in 
nature,
such that it can be associated with any object without needing to know 
what
that object is.  Then additional key-ring contexts could be created as 
needed
for LSM modules or such.

I gave reasons earlier in this thread of why it is very useful to have 
nested
key-rings, so perhaps we can give each key-ring a "parent" which 
happens to
be an additional key-ring association.  As long as we avoid cyclic 
graphs, that
should give a great increase in flexibility without security problems.

Another complexity is the access control issue.  I would rather not add 
more
LSM hooks if we can avoid it, just to keep the complexity down, so I'm 
thinking
that we could just represent all the information through the filesystem 
and file
descriptors, with a couple of convenient IOCTLs.  That way we could use 
the
existing LSM hooks for filesystem access, and avoid giving sysadmins 
another
system that they must start all over learning to secure.

I've looked at your patch, and it doesn't seem to be general enough to 
allow
user-space to store arbitrary keys in the kernel, one of the features 
that others
have expressed a desire for (see Andy Lutomirski's emails).  With such a
system the most critical aspect to get first is the most flexible way 
to manipulate
such keys without creating too much complexity.

It's essential to be able to tell the difference between different 
types of keys,
especially if we want to let user-space use this to store other kinds 
of keys. We
also need to be able to identify keys by "service" of some sort.  I 
think that
would probably be a key-type specific parameter, but for a Kerberos TGT 
it
could be something like "krbtgt/MY.REALM@xxxxxxxx".  With a type based
system we could even allow modules that implement additional 
functionality
for certain types (IE something that uses CryptoAPI to do AES in-kernel 
for
extra security).

Hmm, so going along with these ideas, how about this?
/proc/keyring/
	MODE = 555
	DESC = keyringfs, contains keyring metadata
	
	<id>/
		MODE = Access control for entire keyring
		DESC = A keyring entry, referenced by number
		opendir = Increments the ref count to make sure it won't go away.
		
		parent => ../<id>
			DESC = A symlink or hardlink to the parent keyring
		
		<typeid>/
			MODE = 555
			DESC = A numerical "key-type" (KEYTYPE_KRB5)
			
			<service>
				MODE = Access control for a single key
				DESC = The key, accessed as a file.
			
		<typename> => <typeid>/
				DESC = A symlink or hardlink to a type number from
					a type name.  These types could be registered
					by modules that implement them.

There would be IOCTLs on the key-ring dir handles for getting the 
key-ring
number, adding new keys, etc.  On key handles there would be IOCTLs for
deleting the key, revoking access, etc.  We'd also need a few syscalls 
for
creating new key-rings.

Cheers,
Kyle Moffett

-
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/