Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: David Howells <dhowells <at> redhat.com>
Subject: [RFC] Coming key management support improvements
Newsgroups: gmane.linux.kernel.lsm
Date: Tuesday 20th September 2005 10:17:22 UTC (over 11 years ago)
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
 
CD: 2ms