[PATCH] keys & keyring management: key filesystem

[David Howells <dhowells@redhat.com>]

Here's a preliminary look a patch I've concocted to make keys accessible
through yet another filesystem (TM). At the moment, it only gives a read-only
view onto the keys in the system.

The patch can be found at:

	http://people.redhat.com/~dhowells/keys/keyfs-268rc2.diff.bz2

It requires the keys-268rc2-6.diff.bz2 patch to supply the basic key services.


Currently, it makes a filesystem that looks like:

    /keyfs/
	thread		[symlink to process's thread key]
	process		[symlink to process's process key]
	session		[symlink to process's session key]
	user		[symlink to user key for process's UID]
	user-session	[symlink to def session key for process's UID]
	<key>/		[directory representing a key]
	    type	[file holding key type as a string]
	    description	[file holding key description as a string]
	    expiry	[file holding key expiry time as a decimal string]
	    perm	[file holding key access mask as an octal string]
	    payload	[file permitting reading/writing of key's payload data]
	<key>/		[directory representing a keyring]
	    type	[file holding key type as a string]
	    description	[file holding key description as a string]
	    expiry	[file holding key expiry time as a decimal string]
	    perm	[file holding key access mask as an octal string]
	    keyring/	[directory representing a keyring's contents]
		<key>	[symlink to linked keys]


I've encountered some problems:

 (1) readdir() on the root directory has to run in O(N^2) time because the key
     tree lock is a spinlock and the filldir call is permitted to sleep.

     I could solve this by making the spinlock into a semaphore, and just
     read-locking it for the duration of the whole readdir call. But this has
     other problems: it'll exclude any key changes for the duration,
     especially if calling filldir causes it to swap a lot.

     I don't think global enumeration is necessarily a good idea. /proc/keys
     is a debugging interface, to be made root readable only at some point. I
     don't think you should be able to _see_ any keys you don't have any
     rights to. Do people disagree with that?

 (2) It weakens security to some extent: it makes keys more accessible, more
     visible.

     I could, perhaps, deal with this by filtering the keys in readdir() and
     lookup() on the root directory.

 (3) The key permissions mask doesn't map easily to the usual RWX bits on a
     file with their strictly VFS meaning. Whilst on a key I'm using the 'X'
     bits to indicate search permission, that can't directly control execute
     permission on the key directory.

 (4) Accessing keys this way requires more syscall invocations, more locks to
     be dealt with, etc. than the syscall approach. It's a lot less efficient,
     particularly when it comes to producing a list of the same data seen in
     /proc/keys.

 (5) The kernel filesystem side of this is already much bigger than the
     syscall/prctl approach, even when it's read-only.

 (6) d_revalidate and getattr need to be supplied for any file or directory
     that relates to a particular key to pick up UID/GID/permissions changes.

     This is difficult to avoid. Each key has to be represented by several
     inodes, and they all need to be kept in sync.


I still haven't seen any really good arguments why I should get rid of all the
syscalls/prctls and drive it from userspace _entirely_ through a keyfs. We
seem to be going a little overboard with the "everything must be a filesystem
approach".

I could perhaps make all the key syscalls ioctls on a control file placed in
the root directory:-)

David