aboutsummaryrefslogtreecommitdiffstats
path: root/security/commoncap.c
diff options
context:
space:
mode:
authorEric Paris <eparis@redhat.com>2011-04-01 17:07:50 -0400
committerJames Morris <jmorris@namei.org>2011-04-04 10:31:04 +1000
commit17f60a7da150fdd0cfb9756f86a262daa72c835f (patch)
tree1c5ece75d66bed0766de861cde6eb18ee7ea4cf2 /security/commoncap.c
parenttomoyo: fix memory leak in tomoyo_commit_ok() (diff)
downloadlinux-dev-17f60a7da150fdd0cfb9756f86a262daa72c835f.tar.xz
linux-dev-17f60a7da150fdd0cfb9756f86a262daa72c835f.zip
capabilites: allow the application of capability limits to usermode helpers
There is no way to limit the capabilities of usermodehelpers. This problem reared its head recently when someone complained that any user with cap_net_admin was able to load arbitrary kernel modules, even though the user didn't have cap_sys_module. The reason is because the actual load is done by a usermode helper and those always have the full cap set. This patch addes new sysctls which allow us to bound the permissions of usermode helpers. /proc/sys/kernel/usermodehelper/bset /proc/sys/kernel/usermodehelper/inheritable You must have CAP_SYS_MODULE and CAP_SETPCAP to change these (changes are &= ONLY). When the kernel launches a usermodehelper it will do so with these as the bset and pI. -v2: make globals static create spinlock to protect globals -v3: require both CAP_SETPCAP and CAP_SYS_MODULE -v4: fix the typo s/CAP_SET_PCAP/CAP_SETPCAP/ because I didn't commit Signed-off-by: Eric Paris <eparis@redhat.com> No-objection-from: Serge E. Hallyn <serge.hallyn@canonical.com> Acked-by: David Howells <dhowells@redhat.com> Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com> Acked-by: Andrew G. Morgan <morgan@kernel.org> Signed-off-by: James Morris <jmorris@namei.org>
Diffstat (limited to 'security/commoncap.c')
0 files changed, 0 insertions, 0 deletions