linux/security/commoncap.c, branch v2.6.26

security: filesystem capabilities: fix CAP_SETPCAP handling

2008-07-04T17:40:08Z

The filesystem capability support meaning for CAP_SETPCAP is less powerful than the non-filesystem capability support. As such, when filesystem capabilities are configured, we should not permit CAP_SETPCAP to 'enhance' the current process through strace manipulation of a child process. Signed-off-by: Andrew G. Morgan Acked-by: Serge Hallyn Cc: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

xattr: add missing consts to function arguments

2008-04-29T15:06:06Z

Add missing consts to xattr function arguments. Signed-off-by: David Howells Cc: Andreas Gruenbacher Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

capabilities: implement per-process securebits

2008-04-28T15:58:26Z

Filesystem capability support makes it possible to do away with (set)uid-0 based privilege and use capabilities instead. That is, with filesystem support for capabilities but without this present patch, it is (conceptually) possible to manage a system with capabilities alone and never need to obtain privilege via (set)uid-0. Of course, conceptually isn't quite the same as currently possible since few user applications, certainly not enough to run a viable system, are currently prepared to leverage capabilities to exercise privilege. Further, many applications exist that may never get upgraded in this way, and the kernel will continue to want to support their setuid-0 base privilege needs. Where pure-capability applications evolve and replace setuid-0 binaries, it is desirable that there be a mechanisms by which they can contain their privilege. In addition to leveraging the per-process bounding and inheritable sets, this should include suppressing the privilege of the uid-0 superuser from the process' tree of children. The feature added by this patch can be leveraged to suppress the privilege associated with (set)uid-0. This suppression requires CAP_SETPCAP to initiate, and only immediately affects the 'current' process (it is inherited through fork()/exec()). This reimplementation differs significantly from the historical support for securebits which was system-wide, unwieldy and which has ultimately withered to a dead relic in the source of the modern kernel. With this patch applied a process, that is capable(CAP_SETPCAP), can now drop all legacy privilege (through uid=0) for itself and all subsequently fork()'d/exec()'d children with: prctl(PR_SET_SECUREBITS, 0x2f); This patch represents a no-op unless CONFIG_SECURITY_FILE_CAPABILITIES is enabled at configure time. [akpm@linux-foundation.org: fix uninitialised var warning] [serue@us.ibm.com: capabilities: use cap_task_prctl when !CONFIG_SECURITY] Signed-off-by: Andrew G. Morgan Acked-by: Serge Hallyn Reviewed-by: James Morris Cc: Stephen Smalley Cc: Paul Moore Signed-off-by: Serge E. Hallyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

security: replace remaining FUNCTION occurrences

2008-04-18T10:26:07Z

__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison Cc: James Morris Cc: Stephen Smalley Signed-off-by: Andrew Morton Signed-off-by: James Morris

file capabilities: remove cap_task_kill()

2008-03-20T16:46:36Z

The original justification for cap_task_kill() was as follows: check_kill_permission() does appropriate uid equivalence checks. However with file capabilities it becomes possible for an unprivileged user to execute a file with file capabilities resulting in a more privileged task with the same uid. However now that cap_task_kill() always returns 0 (permission granted) when p->uid==current->uid, the whole hook is worthless, and only likely to create more subtle problems in the corner cases where it might still be called but return -EPERM. Those cases are basically when uids are different but euid/suid is equivalent as per the check in check_kill_permission(). One example of a still-broken application is 'at' for non-root users. This patch removes cap_task_kill(). Signed-off-by: Serge Hallyn Acked-by: Andrew G. Morgan Earlier-version-tested-by: Luiz Fernando N. Capitulino Acked-by: Casey Schaufler Signed-off-by: Linus Torvalds

file capabilities: simplify signal check

2008-02-24T01:12:13Z

Simplify the uid equivalence check in cap_task_kill(). Anyone can kill a process owned by the same uid. Without this patch wireshark is reported to fail. Signed-off-by: Serge E. Hallyn Signed-off-by: Andrew G. Morgan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

capabilities: introduce per-process capability bounding set

2008-02-05T17:44:20Z

The capability bounding set is a set beyond which capabilities cannot grow. Currently cap_bset is per-system. It can be manipulated through sysctl, but only init can add capabilities. Root can remove capabilities. By default it includes all caps except CAP_SETPCAP. This patch makes the bounding set per-process when file capabilities are enabled. It is inherited at fork from parent. Noone can add elements, CAP_SETPCAP is required to remove them. One example use of this is to start a safer container. For instance, until device namespaces or per-container device whitelists are introduced, it is best to take CAP_MKNOD away from a container. The bounding set will not affect pP and pE immediately. It will only affect pP' and pE' after subsequent exec()s. It also does not affect pI, and exec() does not constrain pI'. So to really start a shell with no way of regain CAP_MKNOD, you would do prctl(PR_CAPBSET_DROP, CAP_MKNOD); cap_t cap = cap_get_proc(); cap_value_t caparray[1]; caparray[0] = CAP_MKNOD; cap_set_flag(cap, CAP_INHERITABLE, 1, caparray, CAP_DROP); cap_set_proc(cap); cap_free(cap); The following test program will get and set the bounding set (but not pI). For instance ./bset get (lists capabilities in bset) ./bset drop cap_net_raw (starts shell with new bset) (use capset, setuid binary, or binary with file capabilities to try to increase caps) ************************************************************ cap_bound.c ************************************************************ #include #include #include #include #include #include #include #ifndef PR_CAPBSET_READ #define PR_CAPBSET_READ 23 #endif #ifndef PR_CAPBSET_DROP #define PR_CAPBSET_DROP 24 #endif int usage(char *me) { printf("Usage: %s get\n", me); printf(" %s drop \n", me); return 1; } #define numcaps 32 char *captable[numcaps] = { "cap_chown", "cap_dac_override", "cap_dac_read_search", "cap_fowner", "cap_fsetid", "cap_kill", "cap_setgid", "cap_setuid", "cap_setpcap", "cap_linux_immutable", "cap_net_bind_service", "cap_net_broadcast", "cap_net_admin", "cap_net_raw", "cap_ipc_lock", "cap_ipc_owner", "cap_sys_module", "cap_sys_rawio", "cap_sys_chroot", "cap_sys_ptrace", "cap_sys_pacct", "cap_sys_admin", "cap_sys_boot", "cap_sys_nice", "cap_sys_resource", "cap_sys_time", "cap_sys_tty_config", "cap_mknod", "cap_lease", "cap_audit_write", "cap_audit_control", "cap_setfcap" }; int getbcap(void) { int comma=0; unsigned long i; int ret; printf("i know of %d capabilities\n", numcaps); printf("capability bounding set:"); for (i=0; i Signed-off-by: Andrew G. Morgan Cc: Stephen Smalley Cc: James Morris Cc: Chris Wright Cc: Casey Schaufler a Signed-off-by: "Serge E. Hallyn" Tested-by: Jiri Slaby Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Add 64-bit capability support to the kernel

2008-02-05T17:44:20Z

The patch supports legacy (32-bit) capability userspace, and where possible translates 32-bit capabilities to/from userspace and the VFS to 64-bit kernel space capabilities. If a capability set cannot be compressed into 32-bits for consumption by user space, the system call fails, with -ERANGE. FWIW libcap-2.00 supports this change (and earlier capability formats) http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/ [akpm@linux-foundation.org: coding-syle fixes] [akpm@linux-foundation.org: use get_task_comm()] [ezk@cs.sunysb.edu: build fix] [akpm@linux-foundation.org: do not initialise statics to 0 or NULL] [akpm@linux-foundation.org: unused var] [serue@us.ibm.com: export __cap_ symbols] Signed-off-by: Andrew G. Morgan Cc: Stephen Smalley Acked-by: Serge Hallyn Cc: Chris Wright Cc: James Morris Cc: Casey Schaufler Signed-off-by: Erez Zadok Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

revert "capabilities: clean up file capability reading"

2008-02-05T17:44:20Z

Revert b68680e4731abbd78863063aaa0dca2a6d8cc723 to make way for the next patch: "Add 64-bit capability support to the kernel". We want to keep the vfs_cap_data.data[] structure, using two 'data's for 64-bit caps (and later three for 96-bit caps), whereas b68680e4731abbd78863063aaa0dca2a6d8cc723 had gotten rid of the 'data' struct made its members inline. The 64-bit caps patch keeps the stack abuse fix at get_file_caps(), which was the more important part of that patch. [akpm@linux-foundation.org: coding-style fixes] Cc: Stephen Smalley Cc: Serge Hallyn Cc: Chris Wright Cc: James Morris Cc: Casey Schaufler Cc: Andrew Morgan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Fix filesystem capability support

2008-01-22T03:39:41Z

In linux-2.6.24-rc1, security/commoncap.c:cap_inh_is_capped() was introduced. It has the exact reverse of its intended behavior. This led to an unintended privilege esculation involving a process' inheritable capability set. To be exposed to this bug, you need to have Filesystem Capabilities enabled and in use. That is: - CONFIG_SECURITY_FILE_CAPABILITIES must be defined for the buggy code to be compiled in. - You also need to have files on your system marked with fI bits raised. Signed-off-by: Andrew G. Morgan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

linux/security/commoncap.c, branch v2.6.26

security: filesystem capabilities: fix CAP_SETPCAP handling

xattr: add missing consts to function arguments

capabilities: implement per-process securebits

security: replace remaining __FUNCTION__ occurrences

file capabilities: remove cap_task_kill()

file capabilities: simplify signal check

capabilities: introduce per-process capability bounding set

Add 64-bit capability support to the kernel

revert "capabilities: clean up file capability reading"

Fix filesystem capability support

security: replace remaining FUNCTION occurrences