1. 24 Jun, 2016 2 commits
    • Andy Lutomirski's avatar
      fs: Treat foreign mounts as nosuid · 380cf5ba
      Andy Lutomirski authored
      If a process gets access to a mount from a different user
      namespace, that process should not be able to take advantage of
      setuid files or selinux entrypoints from that filesystem.  Prevent
      this by treating mounts from other mount namespaces and those not
      owned by current_user_ns() or an ancestor as nosuid.
      
      This will make it safer to allow more complex filesystems to be
      mounted in non-root user namespaces.
      
      This does not remove the need for MNT_LOCK_NOSUID.  The setuid,
      setgid, and file capability bits can no longer be abused if code in
      a user namespace were to clear nosuid on an untrusted filesystem,
      but this patch, by itself, is insufficient to protect the system
      from abuse of files that, when execed, would increase MAC privilege.
      
      As a more concrete explanation, any task that can manipulate a
      vfsmount associated with a given user namespace already has
      capabilities in that namespace and all of its descendents.  If they
      can cause a malicious setuid, setgid, or file-caps executable to
      appear in that mount, then that executable will only allow them to
      elevate privileges in exactly the set of namespaces in which they
      are already privileges.
      
      On the other hand, if they can cause a malicious executable to
      appear with a dangerous MAC label, running it could change the
      caller's security context in a way that should not have been
      possible, even inside the namespace in which the task is confined.
      
      As a hardening measure, this would have made CVE-2014-5207 much
      more difficult to exploit.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Acked-by: default avatarJames Morris <james.l.morris@oracle.com>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      380cf5ba
    • Seth Forshee's avatar
      fs: Limit file caps to the user namespace of the super block · d07b846f
      Seth Forshee authored
      Capability sets attached to files must be ignored except in the
      user namespaces where the mounter is privileged, i.e. s_user_ns
      and its descendants. Otherwise a vector exists for gaining
      privileges in namespaces where a user is not already privileged.
      
      Add a new helper function, current_in_user_ns(), to test whether a user
      namespace is the same as or a descendant of another namespace.
      Use this helper to determine whether a file's capability set
      should be applied to the caps constructed during exec.
      
      --EWB Replaced in_userns with the simpler current_in_userns.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      d07b846f
  2. 22 Apr, 2016 1 commit
    • Baolin Wang's avatar
      security: Introduce security_settime64() · 457db29b
      Baolin Wang authored
      security_settime() uses a timespec, which is not year 2038 safe
      on 32bit systems. Thus this patch introduces the security_settime64()
      function with timespec64 type. We also convert the cap_settime() helper
      function to use the 64bit types.
      
      This patch then moves security_settime() to the header file as an
      inline helper function so that existing users can be iteratively
      converted.
      
      None of the existing hooks is using the timespec argument and therefor
      the patch is not making any functional changes.
      
      Cc: Serge Hallyn <serge.hallyn@canonical.com>,
      Cc: James Morris <james.l.morris@oracle.com>,
      Cc: "Serge E. Hallyn" <serge@hallyn.com>,
      Cc: Paul Moore <pmoore@redhat.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Reviewed-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarBaolin Wang <baolin.wang@linaro.org>
      [jstultz: Reworded commit message]
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      457db29b
  3. 10 Apr, 2016 1 commit
  4. 20 Jan, 2016 1 commit
    • Jann Horn's avatar
      ptrace: use fsuid, fsgid, effective creds for fs access checks · caaee623
      Jann Horn authored
      By checking the effective credentials instead of the real UID / permitted
      capabilities, ensure that the calling process actually intended to use its
      credentials.
      
      To ensure that all ptrace checks use the correct caller credentials (e.g.
      in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS
      flag), use two new flags and require one of them to be set.
      
      The problem was that when a privileged task had temporarily dropped its
      privileges, e.g.  by calling setreuid(0, user_uid), with the intent to
      perform following syscalls with the credentials of a user, it still passed
      ptrace access checks that the user would not be able to pass.
      
      While an attacker should not be able to convince the privileged task to
      perform a ptrace() syscall, this is a problem because the ptrace access
      check is reused for things in procfs.
      
      In particular, the following somewhat interesting procfs entries only rely
      on ptrace access checks:
      
       /proc/$pid/stat - uses the check for determining whether pointers
           should be visible, useful for bypassing ASLR
       /proc/$pid/maps - also useful for bypassing ASLR
       /proc/$pid/cwd - useful for gaining access to restricted
           directories that contain files with lax permissions, e.g. in
           this scenario:
           lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar
           drwx------ root root /root
           drwxr-xr-x root root /root/foobar
           -rw-r--r-- root root /root/foobar/secret
      
      Therefore, on a system where a root-owned mode 6755 binary changes its
      effective credentials as described and then dumps a user-specified file,
      this could be used by an attacker to reveal the memory layout of root's
      processes or reveal the contents of files he is not allowed to access
      (through /proc/$pid/cwd).
      
      [akpm@linux-foundation.org: fix warning]
      Signed-off-by: default avatarJann Horn <jann@thejh.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      caaee623
  5. 04 Sep, 2015 2 commits
    • Andy Lutomirski's avatar
      capabilities: add a securebit to disable PR_CAP_AMBIENT_RAISE · 746bf6d6
      Andy Lutomirski authored
      Per Andrew Morgan's request, add a securebit to allow admins to disable
      PR_CAP_AMBIENT_RAISE.  This securebit will prevent processes from adding
      capabilities to their ambient set.
      
      For simplicity, this disables PR_CAP_AMBIENT_RAISE entirely rather than
      just disabling setting previously cleared bits.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Acked-by: default avatarAndrew G. Morgan <morgan@kernel.org>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      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>
      746bf6d6
    • 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
      discarded.
      
      Preliminary userspace code is here, but it needs updating:
      https://git.kernel.org/cgit/linux/kernel/git/luto/util-linux-playground.git/commit/?h=cap_ambient&id=7f5afbd175d2
      
      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
      #define PR_CAP_AMBIENT_CLEAR_ALL 4
      
      static void set_ambient_cap(int cap)
      {
      	int rc;
      
      	capng_get_caps_process();
      	rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap);
      	if (rc) {
      		printf("Cannot add inheritable cap\n");
      		exit(2);
      	}
      	capng_apply(CAPNG_SELECT_CAPS);
      
      	/* 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");
      		exit(1);
      	}
      }
      
      int main(int argc, char **argv)
      {
      	int rc;
      
      	set_ambient_cap(CAP_NET_RAW);
      	set_ambient_cap(CAP_NET_ADMIN);
      	set_ambient_cap(CAP_SYS_NICE);
      
      	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>
      58319057
  6. 11 May, 2015 1 commit
    • Casey Schaufler's avatar
      LSM: Switch to lists of hooks · b1d9e6b0
      Casey Schaufler authored
      Instead of using a vector of security operations
      with explicit, special case stacking of the capability
      and yama hooks use lists of hooks with capability and
      yama hooks included as appropriate.
      
      The security_operations structure is no longer required.
      Instead, there is a union of the function pointers that
      allows all the hooks lists to use a common mechanism for
      list management while retaining typing. Each module
      supplies an array describing the hooks it provides instead
      of a sparsely populated security_operations structure.
      The description includes the element that gets put on
      the hook list, avoiding the issues surrounding individual
      element allocation.
      
      The method for registering security modules is changed to
      reflect the information available. The method for removing
      a module, currently only used by SELinux, has also changed.
      It should be generic now, however if there are potential
      race conditions based on ordering of hook removal that needs
      to be addressed by the calling module.
      
      The security hooks are called from the lists and the first
      failure is returned.
      Signed-off-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Acked-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Acked-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Acked-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      b1d9e6b0
  7. 15 Apr, 2015 1 commit
  8. 25 Jan, 2015 1 commit
  9. 19 Nov, 2014 1 commit
  10. 24 Jul, 2014 2 commits
    • Eric Paris's avatar
      CAPABILITIES: remove undefined caps from all processes · 7d8b6c63
      Eric Paris authored
      This is effectively a revert of 7b9a7ec5
      plus fixing it a different way...
      
      We found, when trying to run an application from an application which
      had dropped privs that the kernel does security checks on undefined
      capability bits.  This was ESPECIALLY difficult to debug as those
      undefined bits are hidden from /proc/$PID/status.
      
      Consider a root application which drops all capabilities from ALL 4
      capability sets.  We assume, since the application is going to set
      eff/perm/inh from an array that it will clear not only the defined caps
      less than CAP_LAST_CAP, but also the higher 28ish bits which are
      undefined future capabilities.
      
      The BSET gets cleared differently.  Instead it is cleared one bit at a
      time.  The problem here is that in security/commoncap.c::cap_task_prctl()
      we actually check the validity of a capability being read.  So any task
      which attempts to 'read all things set in bset' followed by 'unset all
      things set in bset' will not even attempt to unset the undefined bits
      higher than CAP_LAST_CAP.
      
      So the 'parent' will look something like:
      CapInh:	0000000000000000
      CapPrm:	0000000000000000
      CapEff:	0000000000000000
      CapBnd:	ffffffc000000000
      
      All of this 'should' be fine.  Given that these are undefined bits that
      aren't supposed to have anything to do with permissions.  But they do...
      
      So lets now consider a task which cleared the eff/perm/inh completely
      and cleared all of the valid caps in the bset (but not the invalid caps
      it couldn't read out of the kernel).  We know that this is exactly what
      the libcap-ng library does and what the go capabilities library does.
      They both leave you in that above situation if you try to clear all of
      you capapabilities from all 4 sets.  If that root task calls execve()
      the child task will pick up all caps not blocked by the bset.  The bset
      however does not block bits higher than CAP_LAST_CAP.  So now the child
      task has bits in eff which are not in the parent.  These are
      'meaningless' undefined bits, but still bits which the parent doesn't
      have.
      
      The problem is now in cred_cap_issubset() (or any operation which does a
      subset test) as the child, while a subset for valid cap bits, is not a
      subset for invalid cap bits!  So now we set durring commit creds that
      the child is not dumpable.  Given it is 'more priv' than its parent.  It
      also means the parent cannot ptrace the child and other stupidity.
      
      The solution here:
      1) stop hiding capability bits in status
      	This makes debugging easier!
      
      2) stop giving any task undefined capability bits.  it's simple, it you
      don't put those invalid bits in CAP_FULL_SET you won't get them in init
      and you won't get them in any other task either.
      	This fixes the cap_issubset() tests and resulting fallout (which
      	made the init task in a docker container untraceable among other
      	things)
      
      3) mask out undefined bits when sys_capset() is called as it might use
      ~0, ~0 to denote 'all capabilities' for backward/forward compatibility.
      	This lets 'capsh --caps="all=eip" -- -c /bin/bash' run.
      
      4) mask out undefined bit when we read a file capability off of disk as
      again likely all bits are set in the xattr for forward/backward
      compatibility.
      	This lets 'setcap all+pe /bin/bash; /bin/bash' run
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Andrew G. Morgan <morgan@kernel.org>
      Cc: Serge E. Hallyn <serge.hallyn@canonical.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Steve Grubb <sgrubb@redhat.com>
      Cc: Dan Walsh <dwalsh@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      7d8b6c63
    • Tetsuo Handa's avatar
      commoncap: don't alloc the credential unless needed in cap_task_prctl · 6d6f3328
      Tetsuo Handa authored
      In function cap_task_prctl(), we would allocate a credential
      unconditionally and then check if we support the requested function.
      If not we would release this credential with abort_creds() by using
      RCU method. But on some archs such as powerpc, the sys_prctl is heavily
      used to get/set the floating point exception mode. So the unnecessary
      allocating/releasing of credential not only introduce runtime overhead
      but also do cause OOM due to the RCU implementation.
      
      This patch removes abort_creds() from cap_task_prctl() by calling
      prepare_creds() only when we need to modify it.
      Reported-by: default avatarKevin Hao <haokexin@gmail.com>
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reviewed-by: default avatarPaul Moore <paul@paul-moore.com>
      Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      6d6f3328
  11. 31 Aug, 2013 1 commit
  12. 30 Aug, 2013 1 commit
  13. 26 Feb, 2013 1 commit
  14. 14 Dec, 2012 1 commit
    • Eric W. Biederman's avatar
      Fix cap_capable to only allow owners in the parent user namespace to have caps. · 520d9eab
      Eric W. Biederman authored
      Andy Lutomirski pointed out that the current behavior of allowing the
      owner of a user namespace to have all caps when that owner is not in a
      parent user namespace is wrong.  Add a test to ensure the owner of a user
      namespace is in the parent of the user namespace to fix this bug.
      
      Thankfully this bug did not apply to the initial user namespace, keeping
      the mischief that can be caused by this bug quite small.
      
      This is bug was introduced in v3.5 by commit 783291e6
      "Simplify the user_namespace by making userns->creator a kuid."
      But did not matter until the permisions required to create
      a user namespace were relaxed allowing a user namespace to be created
      inside of a user namespace.
      
      The bug made it possible for the owner of a user namespace to be
      present in a child user namespace.  Since the owner of a user nameapce
      is granted all capabilities it became possible for users in a
      grandchild user namespace to have all privilges over their parent user
      namspace.
      
      Reorder the checks in cap_capable.  This should make the common case
      faster and make it clear that nothing magic happens in the initial
      user namespace.  The reordering is safe because cred->user_ns
      can only be in targ_ns or targ_ns->parent but not both.
      
      Add a comment a the top of the loop to make the logic of
      the code clear.
      
      Add a distinct variable ns that changes as we walk up
      the user namespace hierarchy to make it clear which variable
      is changing.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      520d9eab
  15. 31 May, 2012 2 commits
  16. 03 May, 2012 2 commits
  17. 26 Apr, 2012 1 commit
    • Eric W. Biederman's avatar
      userns: Simplify the user_namespace by making userns->creator a kuid. · 783291e6
      Eric W. Biederman authored
      - Transform userns->creator from a user_struct reference to a simple
        kuid_t, kgid_t pair.
      
        In cap_capable this allows the check to see if we are the creator of
        a namespace to become the classic suser style euid permission check.
      
        This allows us to remove the need for a struct cred in the mapping
        functions and still be able to dispaly the user namespace creators
        uid and gid as 0.
      
      - Remove the now unnecessary delayed_work in free_user_ns.
      
        All that is left for free_user_ns to do is to call kmem_cache_free
        and put_user_ns.  Those functions can be called in any context
        so call them directly from free_user_ns removing the need for delayed work.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      783291e6
  18. 18 Apr, 2012 1 commit
  19. 17 Apr, 2012 1 commit
  20. 13 Apr, 2012 1 commit
    • Andy Lutomirski's avatar
      Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs · 259e5e6c
      Andy Lutomirski authored
      With this change, calling
        prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
      disables privilege granting operations at execve-time.  For example, a
      process will not be able to execute a setuid binary to change their uid
      or gid if this bit is set.  The same is true for file capabilities.
      
      Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
      LSMs respect the requested behavior.
      
      To determine if the NO_NEW_PRIVS bit is set, a task may call
        prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
      It returns 1 if set and 0 if it is not set. If any of the arguments are
      non-zero, it will return -1 and set errno to -EINVAL.
      (PR_SET_NO_NEW_PRIVS behaves similarly.)
      
      This functionality is desired for the proposed seccomp filter patch
      series.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
      system call behavior for itself and its child tasks without being
      able to impact the behavior of a more privileged task.
      
      Another potential use is making certain privileged operations
      unprivileged.  For example, chroot may be considered "safe" if it cannot
      affect privileged tasks.
      
      Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
      set and AppArmor is in use.  It is fixed in a subsequent patch.
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarWill Drewry <wad@chromium.org>
      Acked-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      
      v18: updated change desc
      v17: using new define values as per 3.4
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      259e5e6c
  21. 07 Apr, 2012 2 commits
  22. 13 Feb, 2012 1 commit
  23. 05 Jan, 2012 2 commits
    • Eric Paris's avatar
      security: remove the security_netlink_recv hook as it is equivalent to capable() · fd778461
      Eric Paris authored
      Once upon a time netlink was not sync and we had to get the effective
      capabilities from the skb that was being received.  Today we instead get
      the capabilities from the current task.  This has rendered the entire
      purpose of the hook moot as it is now functionally equivalent to the
      capable() call.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      fd778461
    • Eric Paris's avatar
      capabilities: remove the task from capable LSM hook entirely · 6a9de491
      Eric Paris authored
      The capabilities framework is based around credentials, not necessarily the
      current task.  Yet we still passed the current task down into LSMs from the
      security_capable() LSM hook as if it was a meaningful portion of the security
      decision.  This patch removes the 'generic' passing of current and instead
      forces individual LSMs to use current explicitly if they think it is
      appropriate.  In our case those LSMs are SELinux and AppArmor.
      
      I believe the AppArmor use of current is incorrect, but that is wholely
      unrelated to this patch.  This patch does not change what AppArmor does, it
      just makes it clear in the AppArmor code that it is doing it.
      
      The SELinux code still uses current in it's audit message, which may also be
      wrong and needs further investigation.  Again this is NOT a change, it may
      have always been wrong, this patch just makes it clear what is happening.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      6a9de491
  24. 15 Aug, 2011 1 commit
  25. 11 Aug, 2011 1 commit
    • Zhi Li's avatar
      capabilities: do not grant full privs for setuid w/ file caps + no effective caps · 4d49f671
      Zhi Li authored
      A task (when !SECURE_NOROOT) which executes a setuid-root binary will
      obtain root privileges while executing that binary.  If the binary also
      has effective capabilities set, then only those capabilities will be
      granted.  The rationale is that the same binary can carry both setuid-root
      and the minimal file capability set, so that on a filesystem not
      supporting file caps the binary can still be executed with privilege,
      while on a filesystem supporting file caps it will run with minimal
      privilege.
      
      This special case currently does NOT happen if there are file capabilities
      but no effective capabilities.  Since capability-aware programs can very
      well start with empty pE but populated pP and move those caps to pE when
      needed.  In other words, if the file has file capabilities but NOT
      effective capabilities, then we should do the same thing as if there
      were file capabilities, and not grant full root privileges.
      
      This patchset does that.
      
      (Changelog by Serge Hallyn).
      Signed-off-by: default avatarZhi Li <lizhi1215@gmail.com>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      4d49f671
  26. 03 Apr, 2011 1 commit
  27. 23 Mar, 2011 2 commits
    • Serge E. Hallyn's avatar
      userns: allow ptrace from non-init user namespaces · 8409cca7
      Serge E. Hallyn authored
      ptrace is allowed to tasks in the same user namespace according to the
      usual rules (i.e.  the same rules as for two tasks in the init user
      namespace).  ptrace is also allowed to a user namespace to which the
      current task the has CAP_SYS_PTRACE capability.
      
      Changelog:
      	Dec 31: Address feedback by Eric:
      		. Correct ptrace uid check
      		. Rename may_ptrace_ns to ptrace_capable
      		. Also fix the cap_ptrace checks.
      	Jan  1: Use const cred struct
      	Jan 11: use task_ns_capable() in place of ptrace_capable().
      	Feb 23: same_or_ancestore_user_ns() was not an appropriate
      		check to constrain cap_issubset.  Rather, cap_issubset()
      		only is meaningful when both capsets are in the same
      		user_ns.
      Signed-off-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@free.fr>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8409cca7
    • Serge E. Hallyn's avatar
      userns: security: make capabilities relative to the user namespace · 3486740a
      Serge E. Hallyn authored
      - Introduce ns_capable to test for a capability in a non-default
        user namespace.
      - Teach cap_capable to handle capabilities in a non-default
        user namespace.
      
      The motivation is to get to the unprivileged creation of new
      namespaces.  It looks like this gets us 90% of the way there, with
      only potential uid confusion issues left.
      
      I still need to handle getting all caps after creation but otherwise I
      think I have a good starter patch that achieves all of your goals.
      
      Changelog:
      	11/05/2010: [serge] add apparmor
      	12/14/2010: [serge] fix capabilities to created user namespaces
      	Without this, if user serge creates a user_ns, he won't have
      	capabilities to the user_ns he created.  THis is because we
      	were first checking whether his effective caps had the caps
      	he needed and returning -EPERM if not, and THEN checking whether
      	he was the creator.  Reverse those checks.
      	12/16/2010: [serge] security_real_capable needs ns argument in !security case
      	01/11/2011: [serge] add task_ns_capable helper
      	01/11/2011: [serge] add nsown_capable() helper per Bastian Blank suggestion
      	02/16/2011: [serge] fix a logic bug: the root user is always creator of
      		    init_user_ns, but should not always have capabilities to
      		    it!  Fix the check in cap_capable().
      	02/21/2011: Add the required user_ns parameter to security_capable,
      		    fixing a compile failure.
      	02/23/2011: Convert some macros to functions as per akpm comments.  Some
      		    couldn't be converted because we can't easily forward-declare
      		    them (they are inline if !SECURITY, extern if SECURITY).  Add
      		    a current_user_ns function so we can use it in capability.h
      		    without #including cred.h.  Move all forward declarations
      		    together to the top of the #ifdef __KERNEL__ section, and use
      		    kernel-doc format.
      	02/23/2011: Per dhowells, clean up comment in cap_capable().
      	02/23/2011: Per akpm, remove unreachable 'return -EPERM' in cap_capable.
      
      (Original written and signed off by Eric;  latest, modified version
      acked by him)
      
      [akpm@linux-foundation.org: fix build]
      [akpm@linux-foundation.org: export current_user_ns() for ecryptfs]
      [serge.hallyn@canonical.com: remove unneeded extra argument in selinux's task_has_capability]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarDaniel Lezcano <daniel.lezcano@free.fr>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3486740a
  28. 03 Mar, 2011 1 commit
  29. 02 Feb, 2011 1 commit
  30. 15 Nov, 2010 1 commit
  31. 12 Nov, 2010 1 commit
  32. 20 Oct, 2010 1 commit