Re: [PATCH] implement in-kernel keys & keyring management [try #2]

[David Howells <dhowells@redhat.com>]

James Morris <jmorris@redhat.com> wrote:
> You write and then read, like the transaction based IO methods in 
> selinuxfs (TA_write, TA_read).

Hmmm... You need to consider the fact that you need three or four pieces of
information to create a key: type, description, payload (if there's a payload
- there may not be) and destination keyring ID; and the payload is a binary
blob of data.

I could say that you must do this as a single write of a buffer containing
three NUL terminated strings, one after the other, followed, if present, by a
binary blob...

Maybe I should say you have to use an ioctl()... :-)

> > Maintaining access controls would be fun though... How does the kernel then
> > distinguish between a read and a search?
> 
> I guess you'd use normal filsystem access controls instead of storing them
> with the keys themselves.  i.e. keyrings are directories, and keys are
> files (or directories with files including metadata and key data).  Then
> xattrs could be used to integrate with things like SELinux.  A user could
> then use chmod to specify whether a kerying can be searched, for example.

Keyring permissions don't map exactly to file or directory attributes. If
you, for instance, place the key permissions mask on the directory
representing the key/keyring, then search permission controls whether you can
access any file in that directory, which isn't practical.

I think I'd have to keep the key search mask in a separate file under that key
directory, and have you read or write to it rather than using chmod.

chmod() isn't an option, really: key permissions don't really map well to file
permissions. I suppose also key permissions really ought to have more than RWX
permission can handle:

	{ read, write, search, subscribe } x { UID, GID, Other }

Currently, I permit subscription (link) to any key for which you have either
read or execute permission.

I also don't really want you to be able to _see_ any key for which you don't
have any permission, so readdir() on /keyfs/ should not report any directory
corresponding to a file you can't see. I should implement this on my
/proc/keys too.

> The main point is that a filesystem API provides several useful framework
> components by default:access control, creat/open/read/write etc. syscalls,
> hierarchical structure and xattrs.  Using a filesystem API means not
> inventing yet another class of API.

I think you're wrong:

 (1) Making a service like this accessible through a filesystem is as much
     creating a new class of API, as is creating new prctl() functions or new
     syscalls. It's just an API built on read(), write(), etc. rather than
     being on the syscall interface directly.

 (2) A filesystem API is _way_ less efficient, though that probably isn't too
     much of a problem in this case. You have to do several VFS syscalls to
     achieve many things you could just do with a single real syscall.

 (3) Hierarchy? So what? You can't really represent a set of nested keyrings
     as a set of nested directories since keys can have multiple
     parents. Besides, keys don't make a single tree.

     You'd have to represent links in a keyring as symlinks, but when creating
     them, how do you interpret the argument given to symlink()?

 (4) I suspect a filesystem API will be a lot heavier on code and memory.

 (5) Text parsers are required in a number of cases.

 (6) Using a filesystem API throws more locks into the works.

The downsides of adding a number of new syscalls are:

 (1) glibc, uclibc, etc

 (2) 32->64 bit syscall translation

 (3) Adding the new syscalls to all archs

However, using prctl(), I just about get all three for free:-)

But are they really greater than the downsides of trying to do it through the
filesystem API to which doesn't really map, and which must be abused?

David