Re: In-kernel Authentication Tokens (PAGs)

[Kyle Moffett]

Ok, I have some free time this week to code up a patch.  To start with 
everything
will rely on being in process context just to make things simple.  
Here's a short
summary of everything we've agreed upon so far:

1)	A key-ring is an object independent of what uses it.  It supports 
operations
to read, modify, and search it.

2)	When a key-ring is searched for a particular key by name and type, 
first
it checks all keys of the specified type within said key-ring.  If it 
does not find it
there, then it proceeds with all sub-key-rings.

3)	Keys and key-rings are allocated and referenced through an 
independent
number space (Somewhat like the PID allocator)

4)	Key and key-ring access should be controlled using permissions and
POSIX ACLs as though they were files.  In this case, however, the 
"execute"
permission bit is used to control in-kernel operations on the keys (EX: 
AES
encrypting a block of data using CryptoAPI without being able to read 
the key.

5)	Key-rings should be automatically associated with the following 
things.
This is also the search order when looking for a key.
Thread
Process
Process Group
Session
User
Group

6)	User process with the appropriate privileges (Perhaps a new 
capability
CAP_LINUX_KEYS or something) can modify/search/link/whatever any/all
keyrings.  (I'm still not quite sure how much should be allowed.)

7)	All algorithms working with keys and keyrings should be iterative, 
not
recursive, and should be run it process context.

8)	Graphs of nested key-rings must be non-circular.

9)	All memory allocated for key-rings and keys should be counted from
various limits associated with users/processes/etc.

10)	All kernel key-types should begin with a "+" character, and 
user-space
cannot use an unregistered key-type that begins with a "+" character. 
(This
means that all keys having a key-type beginning with a "+" character 
have
been validated by kernel code.

11)	A key-ring filesystem should be mounted on /proc/keys:	
	types
	keys/
		<keyID>/
			control
			type
			description
			state
 		<keyringID>/
			control
			type
			description
			state
 			<keyID> => ../<keyID> [symlink]

12)	It should be impossible to look up keys by number unless said key
filesystem is mounted.  The "control" entries in the key filesystem can 
be
open()ed to get the kind of file handle that KETCTL manipulates.

13)	A new syscall "keyctl":

KEYCTL_NEW_RING:	Creates a new key-ring and returns its fd
	Returns:	int filedesc
	Params:
		char *desc
		int *subkeys
		long subkey_count

KEYCTL_NEW_KEY:	Creates a new key and returns its fd
	Returns:	int filedesc
	Params:
		char *type
		char *desc
		void *data

KEYCTL_SHLOCK
KEYCTL_EXLOCK
KEYCTL_UNLOCK:	A mandatory lock on the key/key-ring
	Returns:	int error
	Params:
		int filedesc
		int flags

KEYCTL_TYPE:	Retrieves the "type" field
	Returns:	long bytes_left
	Params:
		char *desc
		long size

KEYCTL_DESC:	Retrieves the "desc" field
	Returns:	long bytes_left
	Params:
		char *desc
		long size

KEYCTL_READ:	Retrieves the "data" field
	Returns:	long bytes_left
	Params:
		char *data
		long size

KEYCTL_WRITE:	Modifies the "data" field
	Returns:	int error
	Params:
		char *data
		long size

KEYCTL_GET:	Retrieves the current key fd
	Returns:	int filedesc
	Params:
		int type
			KEY_THREAD
			KEY_PROCESS
			KEY_PGROUP
			KEY_SESSION
			KEY_USER
			KEY_GROUP

KEYCTL_SET:	Modifies the current key fd
	Returns:	int error
	Params:
		int type
			<See above KEYCTL_GET_KEY>
		int filedesc

KEYCTL_ENUM: Enumerates through all keys. NOTE: This must only be
called with a KEYCTL_SHLOCK, otherwise it might skip keys or repeat
keys.
	Returns:	int error
	Params:
		int keyring_fd
		int *key_fd

KEYCTL_LOOKUP:	Look for a key by type, but don't recurse
	Returns:	int filedesc

KEYCTL_SEARCH:	Searches for a specific key by type
	Returns:	int filedesc
	Params:
		char *type
		char *desc

KEYCTL_ADD:	Adds a key to a key-ring
	Returns:	int error
	Params:
		int keyring_fd
		int key_fd

KEYCTL_REMOVE:	Removes a key from a key-ring
	Returns:	int error
	Params:
		int keyring_fd
		int key_fd

KEYCTL_CLEAR:	Removes all keys from a key-ring
	Returns:	int error
	Params:
		int keyring_fd

KEYCTL_REVOKE:	Revokes a specific key file descriptor and any key
file descriptors it spawned.  This should even apply to keyrings!
	Returns:	int error
	Params:
		int filedesc


I think that's just about everything.  Let me know if I got something 
wrong
or have another problem with the above.

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/