• Andy Lutomirski's avatar
    capabilities: ambient capabilities · 58319057
    Andy Lutomirski authored
    Credit where credit is due: this idea comes from Christoph Lameter with
    a lot of valuable input from Serge Hallyn.  This patch is heavily based
    on Christoph's patch.
    ===== The status quo =====
    On Linux, there are a number of capabilities defined by the kernel.  To
    perform various privileged tasks, processes can wield capabilities that
    they hold.
    Each task has four capability masks: effective (pE), permitted (pP),
    inheritable (pI), and a bounding set (X).  When the kernel checks for a
    capability, it checks pE.  The other capability masks serve to modify
    what capabilities can be in pE.
    Any task can remove capabilities from pE, pP, or pI at any time.  If a
    task has a capability in pP, it can add that capability to pE and/or pI.
    If a task has CAP_SETPCAP, then it can add any capability to pI, and it
    can remove capabilities from X.
    Tasks are not the only things that can have capabilities; files can also
    have capabilities.  A file can have no capabilty information at all [1].
    If a file has capability information, then it has a permitted mask (fP)
    and an inheritable mask (fI) as well as a single effective bit (fE) [2].
    File capabilities modify the capabilities of tasks that execve(2) them.
    A task that successfully calls execve has its capabilities modified for
    the file ultimately being excecuted (i.e.  the binary itself if that
    binary is ELF or for the interpreter if the binary is a script.) [3] In
    the capability evolution rules, for each mask Z, pZ represents the old
    value and pZ' represents the new value.  The rules are:
      pP' = (X & fP) | (pI & fI)
      pI' = pI
      pE' = (fE ? pP' : 0)
      X is unchanged
    For setuid binaries, fP, fI, and fE are modified by a moderately
    complicated set of rules that emulate POSIX behavior.  Similarly, if
    euid == 0 or ruid == 0, then fP, fI, and fE are modified differently
    (primary, fP and fI usually end up being the full set).  For nonroot
    users executing binaries with neither setuid nor file caps, fI and fP
    are empty and fE is false.
    As an extra complication, if you execute a process as nonroot and fE is
    set, then the "secure exec" rules are in effect: AT_SECURE gets set,
    LD_PRELOAD doesn't work, etc.
    This is rather messy.  We've learned that making any changes is
    dangerous, though: if a new kernel version allows an unprivileged
    program to change its security state in a way that persists cross
    execution of a setuid program or a program with file caps, this
    persistent state is surprisingly likely to allow setuid or file-capped
    programs to be exploited for privilege escalation.
    ===== The problem =====
    Capability inheritance is basically useless.
    If you aren't root and you execute an ordinary binary, fI is zero, so
    your capabilities have no effect whatsoever on pP'.  This means that you
    can't usefully execute a helper process or a shell command with elevated
    capabilities if you aren't root.
    On current kernels, you can sort of work around this by setting fI to
    the full set for most or all non-setuid executable files.  This causes
    pP' = pI for nonroot, and inheritance works.  No one does this because
    it's a PITA and it isn't even supported on most filesystems.
    If you try this, you'll discover that every nonroot program ends up with
    secure exec rules, breaking many things.
    This is a problem that has bitten many people who have tried to use
    capabilities for anything useful.
    ===== The proposed change =====
    This patch adds a fifth capability mask called the ambient mask (pA).
    pA does what most people expect pI to do.
    pA obeys the invariant that no bit can ever be set in pA if it is not
    set in both pP and pI.  Dropping a bit from pP or pI drops that bit from
    pA.  This ensures that existing programs that try to drop capabilities
    still do so, with a complication.  Because capability inheritance is so
    broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and
    then calling execve effectively drops capabilities.  Therefore,
    setresuid from root to nonroot conditionally clears pA unless
    SECBIT_NO_SETUID_FIXUP is set.  Processes that don't like this can
    re-add bits to pA afterwards.
    The capability evolution rules are changed:
      pA' = (file caps or setuid or setgid ? 0 : pA)
      pP' = (X & fP) | (pI & fI) | pA'
      pI' = pI
      pE' = (fE ? pP' : pA')
      X is unchanged
    If you are nonroot but you have a capability, you can add it to pA.  If
    you do so, your children get that capability in pA, pP, and pE.  For
    example, you can set pA = CAP_NET_BIND_SERVICE, and your children can
    automatically bind low-numbered ports.  Hallelujah!
    Unprivileged users can create user namespaces, map themselves to a
    nonzero uid, and create both privileged (relative to their namespace)
    and unprivileged process trees.  This is currently more or less
    impossible.  Hallelujah!
    You cannot use pA to try to subvert a setuid, setgid, or file-capped
    program: if you execute any such program, pA gets cleared and the
    resulting evolution rules are unchanged by this patch.
    Users with nonzero pA are unlikely to unintentionally leak that
    capability.  If they run programs that try to drop privileges, dropping
    privileges will still work.
    It's worth noting that the degree of paranoia in this patch could
    possibly be reduced without causing serious problems.  Specifically, if
    we allowed pA to persist across executing non-pA-aware setuid binaries
    and across setresuid, then, naively, the only capabilities that could
    leak as a result would be the capabilities in pA, and any attacker
    *already* has those capabilities.  This would make me nervous, though --
    setuid binaries that tried to privilege-separate might fail to do so,
    and putting CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE into pA could have
    unexpected side effects.  (Whether these unexpected side effects would
    be exploitable is an open question.) I've therefore taken the more
    paranoid route.  We can revisit this later.
    An alternative would be to require PR_SET_NO_NEW_PRIVS before setting
    ambient capabilities.  I think that this would be annoying and would
    make granting otherwise unprivileged users minor ambient capabilities
    (CAP_NET_BIND_SERVICE or CAP_NET_RAW for example) much less useful than
    it is with this patch.
    ===== Footnotes =====
    [1] Files that are missing the "security.capability" xattr or that have
    unrecognized values for that xattr end up with has_cap set to false.
    The code that does that appears to be complicated for no good reason.
    [2] The libcap capability mask parsers and formatters are dangerously
    misleading and the documentation is flat-out wrong.  fE is *not* a mask;
    it's a single bit.  This has probably confused every single person who
    has tried to use file capabilities.
    [3] Linux very confusingly processes both the script and the interpreter
    if applicable, for reasons that elude me.  The results from thinking
    about a script's file capabilities and/or setuid bits are mostly
    Preliminary userspace code is here, but it needs updating:
    Here is a test program that can be used to verify the functionality
    (from Christoph):
     * Test program for the ambient capabilities. This program spawns a shell
     * that allows running processes with a defined set of capabilities.
     * (C) 2015 Christoph Lameter <cl@linux.com>
     * Released under: GPL v3 or later.
     * Compile using:
     *	gcc -o ambient_test ambient_test.o -lcap-ng
     * This program must have the following capabilities to run properly:
     * Permissions for CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE
     * A command to equip the binary with the right caps is:
     *	setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test
     * To get a shell with additional caps that can be inherited by other processes:
     *	./ambient_test /bin/bash
     * Verifying that it works:
     * From the bash spawed by ambient_test run
     *	cat /proc/$$/status
     * and have a look at the capabilities.
    #include <stdlib.h>
    #include <stdio.h>
    #include <errno.h>
    #include <cap-ng.h>
    #include <sys/prctl.h>
    #include <linux/capability.h>
     * Definitions from the kernel header files. These are going to be removed
     * when the /usr/include files have these defined.
    #define PR_CAP_AMBIENT 47
    #define PR_CAP_AMBIENT_IS_SET 1
    #define PR_CAP_AMBIENT_RAISE 2
    #define PR_CAP_AMBIENT_LOWER 3
    static void set_ambient_cap(int cap)
    	int rc;
    	rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap);
    	if (rc) {
    		printf("Cannot add inheritable cap\n");
    	/* Note the two 0s at the end. Kernel checks for these */
    	if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0)) {
    		perror("Cannot set cap");
    int main(int argc, char **argv)
    	int rc;
    	printf("Ambient_test forking shell\n");
    	if (execv(argv[1], argv + 1))
    		perror("Cannot exec");
    	return 0;
    Signed-off-by: Christoph Lameter <cl@linux.com> # Original author
    Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
    Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
    Acked-by: default avatarKees Cook <keescook@chromium.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Aaron Jones <aaronmdjones@gmail.com>
    Cc: Ted Ts'o <tytso@mit.edu>
    Cc: Andrew G. Morgan <morgan@kernel.org>
    Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
    Cc: Markku Savela <msa@moth.iki.fi>
    Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Cc: Michael Kerrisk <mtk.manpages@gmail.com>
    Cc: James Morris <james.l.morris@oracle.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Last commit
Last update
encrypted-keys Loading commit data...
Kconfig Loading commit data...
Makefile Loading commit data...
big_key.c Loading commit data...
compat.c Loading commit data...
gc.c Loading commit data...
internal.h Loading commit data...
key.c Loading commit data...
keyctl.c Loading commit data...
keyring.c Loading commit data...
permission.c Loading commit data...
persistent.c Loading commit data...
proc.c Loading commit data...
process_keys.c Loading commit data...
request_key.c Loading commit data...
request_key_auth.c Loading commit data...
sysctl.c Loading commit data...
trusted.c Loading commit data...
trusted.h Loading commit data...
user_defined.c Loading commit data...