[RFC] Coming key management support improvements

From: David Howells (dhowells@private)
Date: Tue Sep 20 2005 - 03:17:22 PDT


Following discussions with various interested parties, I'm intending to make
the following changes, probably in this order, to the key management
code:

 (1) Add an extra set of permissions bits applicable only to those in
     possession of a key or keyring.

     This set would act in conjunction to the other sets, thus if a process is
     not granted a permission by virtue of possession of the key, it might be
     granted permission by virtue of being owned by the key's owner.

     Note that having common user ownership _does_ then exclude checking of
     Group or Other permissions, and having common group ownership does
     preclude checking of the Other permissions.

     One reason I didn't implement possession checks very much in the current
     code is that they're slow: we have to recursively check all the keyrings
     to which a process is subscribed; however, since we won't be doing many
     keyring operations, apart from searching for keys in a process's
     keyrings, that really shouldn't be a problem.

 (2) Add LSM support to the key management code.

     (a) Add a security pointer to the struct key for use by the security
     	 modules.

     (b) Add LSM hooks for key management syscalls, including the overriding
      	 or enhancement of the native security controls.

     (c) Add a pair of keyctl() functions to permit passing and retrieval of
     	 security data (equivalent to xattrs). These functions will go solely
     	 to the LSM hooks, and will do nothing otherwise.

	 Whilst some might argue that this should be done through a filesystem
	 interface, doing so potentially adds a large overhead in terms of
	 both extra code and extra state data. KeyFS nearly doubled the size
	 of the key code alone, and then there were all the extra dentry and
	 inode structures. The lifetime of a key was also then in part
	 controlled by the VFS. Even sysfs adds a large runtime overhead.

     Adding LSM support could be used, for example, to allow SE Linux to label
     keys such that only processes with corresponding labels may access
     them. Such a facility could be used to permit only certain userspace
     tools to access particular types of key - for instance AFS keys and the
     AFS userspace tools.

 (3) Make it possible for request_key() to avoid forking and executing
     /sbin/request-key when a new key needs to be instantiated, but instead
     talk to some already running process to do the honours.

     I'm currently thinking that the way to implement this is to add an extra
     operation to the key-type definition so that the key type may override
     the default choice of spawning /sbin/request-key.

     This would let NFS use the rpc_pipefs filesystem, for example.

     Alternate default ways of doing things can be added to the main key code
     if there's sufficient interest in making them commonly available.

 (4) Add a PAM module to initialise a new session keyring for each login
     session.

Please feel free to comment.

David



This archive was generated by hypermail 2.1.3 : Tue Sep 20 2005 - 03:17:51 PDT