Re: [Keyrings] [PATCH] Keys: Add LSM hooks for key management

[James Morris <jmorris@namei.org>]

I think this looks ok from an SELinux point of view if keys are treated as 
opaque objects, i.e. like files.

We could do something like create a new object class (kernkey or 
something) and implement SELinux permissions for the class such as read, 
write, search, link, setattr and getattr.  Your KEY_VIEW perm could be 
translated to SELinux getattr.

More thought needs to go into whether we need to implement an SELinux 
create permission (and add hooks into the code), for control over whether 
a process can create an anonymous keyring.

I'm not sure if we need user-level labeling of keys via the set & get 
security ops, although LSPP may require some form of get_security. If we 
don't need to manually set security attributes but still view them, they 
could be displayed via /proc/keys rather than implementing a separate 
multiplexed syscall.

It seems that there are no LSM checks for the following:

  keyctl_chown_key()
  keyctl_setperm_key()
  keyctl_set_reqkey_keyring()

  keyctl_join_session_keyring()  [only if we add a 'create' perm]


All users of key_permission() need to propagate the error code from the 
LSM back to the user.


- James
-- 
James Morris
<jmorris@namei.org>