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
<[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
