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