1. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  2. 12 Jan, 2017 1 commit
  3. 24 Dec, 2016 1 commit
  4. 22 Nov, 2016 2 commits
    • Eric W. Biederman's avatar
      exec: Ensure mm->user_ns contains the execed files · f84df2a6
      Eric W. Biederman authored
      When the user namespace support was merged the need to prevent
      ptrace from revealing the contents of an unreadable executable
      was overlooked.
      
      Correct this oversight by ensuring that the executed file
      or files are in mm->user_ns, by adjusting mm->user_ns.
      
      Use the new function privileged_wrt_inode_uidgid to see if
      the executable is a member of the user namespace, and as such
      if having CAP_SYS_PTRACE in the user namespace should allow
      tracing the executable.  If not update mm->user_ns to
      the parent user namespace until an appropriate parent is found.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarJann Horn <jann@thejh.net>
      Fixes: 9e4a36ec ("userns: Fail exec for suid and sgid binaries with ids outside our user namespace.")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      f84df2a6
    • Eric W. Biederman's avatar
      ptrace: Capture the ptracer's creds not PT_PTRACE_CAP · 64b875f7
      Eric W. Biederman authored
      When the flag PT_PTRACE_CAP was added the PTRACE_TRACEME path was
      overlooked.  This can result in incorrect behavior when an application
      like strace traces an exec of a setuid executable.
      
      Further PT_PTRACE_CAP does not have enough information for making good
      security decisions as it does not report which user namespace the
      capability is in.  This has already allowed one mistake through
      insufficient granulariy.
      
      I found this issue when I was testing another corner case of exec and
      discovered that I could not get strace to set PT_PTRACE_CAP even when
      running strace as root with a full set of caps.
      
      This change fixes the above issue with strace allowing stracing as
      root a setuid executable without disabling setuid.  More fundamentaly
      this change allows what is allowable at all times, by using the correct
      information in it's decision.
      
      Cc: stable@vger.kernel.org
      Fixes: 4214e42f96d4 ("v2.4.9.11 -> v2.4.9.12")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      64b875f7
  5. 06 Jun, 2016 1 commit
  6. 15 Apr, 2015 1 commit
    • Iulia Manda's avatar
      kernel: conditionally support non-root users, groups and capabilities · 2813893f
      Iulia Manda authored
      There are a lot of embedded systems that run most or all of their
      functionality in init, running as root:root.  For these systems,
      supporting multiple users is not necessary.
      
      This patch adds a new symbol, CONFIG_MULTIUSER, that makes support for
      non-root users, non-root groups, and capabilities optional.  It is enabled
      under CONFIG_EXPERT menu.
      
      When this symbol is not defined, UID and GID are zero in any possible case
      and processes always have all capabilities.
      
      The following syscalls are compiled out: setuid, setregid, setgid,
      setreuid, setresuid, getresuid, setresgid, getresgid, setgroups,
      getgroups, setfsuid, setfsgid, capget, capset.
      
      Also, groups.c is compiled out completely.
      
      In kernel/capability.c, capable function was moved in order to avoid
      adding two ifdef blocks.
      
      This change saves about 25 KB on a defconfig build.  The most minimal
      kernels have total text sizes in the high hundreds of kB rather than
      low MB.  (The 25k goes down a bit with allnoconfig, but not that much.
      
      The kernel was booted in Qemu.  All the common functionalities work.
      Adding users/groups is not possible, failing with -ENOSYS.
      
      Bloat-o-meter output:
      add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarIulia Manda <iulia.manda21@gmail.com>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2813893f
  7. 24 Jul, 2014 1 commit
    • 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
  8. 10 Jun, 2014 1 commit
    • Andy Lutomirski's avatar
      fs,userns: Change inode_capable to capable_wrt_inode_uidgid · 23adbe12
      Andy Lutomirski authored
      The kernel has no concept of capabilities with respect to inodes; inodes
      exist independently of namespaces.  For example, inode_capable(inode,
      CAP_LINUX_IMMUTABLE) would be nonsense.
      
      This patch changes inode_capable to check for uid and gid mappings and
      renames it to capable_wrt_inode_uidgid, which should make it more
      obvious what it does.
      
      Fixes CVE-2014-4014.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      23adbe12
  9. 04 Jun, 2014 1 commit
  10. 24 Feb, 2014 1 commit
  11. 14 Jan, 2014 1 commit
  12. 31 Aug, 2013 1 commit
  13. 15 Aug, 2013 1 commit
  14. 14 Apr, 2013 1 commit
  15. 15 May, 2012 1 commit
  16. 08 Apr, 2012 1 commit
    • Eric W. Biederman's avatar
      userns: Replace the hard to write inode_userns with inode_capable. · 1a48e2ac
      Eric W. Biederman authored
      This represents a change in strategy of how to handle user namespaces.
      Instead of tagging everything explicitly with a user namespace and bulking
      up all of the comparisons of uids and gids in the kernel,  all uids and gids
      in use will have a mapping to a flat kuid and kgid spaces respectively.  This
      allows much more of the existing logic to be preserved and in general
      allows for faster code.
      
      In this new and improved world we allow someone to utiliize capabilities
      over an inode if the inodes owner mapps into the capabilities holders user
      namespace and the user has capabilities in their user namespace.  Which
      is simple and efficient.
      
      Moving the fs uid comparisons to be comparisons in a flat kuid space
      follows in later patches, something that is only significant if you
      are using user namespaces.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      1a48e2ac
  17. 17 Jan, 2012 1 commit
  18. 05 Jan, 2012 7 commits
  19. 31 Oct, 2011 1 commit
    • Paul Gortmaker's avatar
      kernel: Map most files to use export.h instead of module.h · 9984de1a
      Paul Gortmaker authored
      The changed files were only including linux/module.h for the
      EXPORT_SYMBOL infrastructure, and nothing else.  Revector them
      onto the isolated export header for faster compile times.
      
      Nothing to see here but a whole lot of instances of:
      
        -#include <linux/module.h>
        +#include <linux/export.h>
      
      This commit is only changing the kernel dir; next targets
      will probably be mm, fs, the arch dirs, etc.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      9984de1a
  20. 13 May, 2011 1 commit
    • Serge E. Hallyn's avatar
      Cache user_ns in struct cred · 47a150ed
      Serge E. Hallyn authored
      If !CONFIG_USERNS, have current_user_ns() defined to (&init_user_ns).
      
      Get rid of _current_user_ns.  This requires nsown_capable() to be
      defined in capability.c rather than as static inline in capability.h,
      so do that.
      
      Request_key needs init_user_ns defined at current_user_ns if
      !CONFIG_USERNS, so forward-declare that in cred.h if !CONFIG_USERNS
      at current_user_ns() define.
      
      Compile-tested with and without CONFIG_USERNS.
      Signed-off-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      [ This makes a huge performance difference for acl_permission_check(),
        up to 30%.  And that is one of the hottest kernel functions for loads
        that are pathname-lookup heavy.  ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      47a150ed
  21. 04 Apr, 2011 2 commits
  22. 24 Mar, 2011 2 commits
    • Serge E. Hallyn's avatar
      userns: make has_capability* into real functions · 3263245d
      Serge E. Hallyn authored
      So we can let type safety keep things sane, and as a bonus we can remove
      the declaration of init_user_ns in capability.h.
      Signed-off-by: default avatarSerge E. Hallyn <serge.hallyn@canonical.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Daniel Lezcano <daniel.lezcano@free.fr>
      Cc: David 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>
      3263245d
    • 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
  23. 11 Feb, 2011 1 commit
  24. 02 Apr, 2010 1 commit
  25. 09 Dec, 2009 1 commit
  26. 24 Nov, 2009 1 commit
    • Serge E. Hallyn's avatar
      remove CONFIG_SECURITY_FILE_CAPABILITIES compile option · b3a222e5
      Serge E. Hallyn authored
      As far as I know, all distros currently ship kernels with default
      CONFIG_SECURITY_FILE_CAPABILITIES=y.  Since having the option on
      leaves a 'no_file_caps' option to boot without file capabilities,
      the main reason to keep the option is that turning it off saves
      you (on my s390x partition) 5k.  In particular, vmlinux sizes
      came to:
      
      without patch fscaps=n:		 	53598392
      without patch fscaps=y:		 	53603406
      with this patch applied:		53603342
      
      with the security-next tree.
      
      Against this we must weigh the fact that there is no simple way for
      userspace to figure out whether file capabilities are supported,
      while things like per-process securebits, capability bounding
      sets, and adding bits to pI if CAP_SETPCAP is in pE are not supported
      with SECURITY_FILE_CAPABILITIES=n, leaving a bit of a problem for
      applications wanting to know whether they can use them and/or why
      something failed.
      
      It also adds another subtly different set of semantics which we must
      maintain at the risk of severe security regressions.
      
      So this patch removes the SECURITY_FILE_CAPABILITIES compile
      option.  It drops the kernel size by about 50k over the stock
      SECURITY_FILE_CAPABILITIES=y kernel, by removing the
      cap_limit_ptraced_target() function.
      
      Changelog:
      	Nov 20: remove cap_limit_ptraced_target() as it's logic
      		was ifndef'ed.
      Signed-off-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: default avatarAndrew G. Morgan" <morgan@kernel.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      b3a222e5
  27. 23 Nov, 2009 1 commit
  28. 13 Oct, 2009 1 commit
  29. 14 Jan, 2009 1 commit
  30. 06 Jan, 2009 2 commits
    • David Howells's avatar
      CRED: Fix regression in cap_capable() as shown up by sys_faccessat() [ver #3] · 3699c53c
      David Howells authored
      Fix a regression in cap_capable() due to:
      
      	commit 3b11a1de
      	Author: David Howells <dhowells@redhat.com>
      	Date:   Fri Nov 14 10:39:26 2008 +1100
      
      	    CRED: Differentiate objective and effective subjective credentials on a task
      
      The problem is that the above patch allows a process to have two sets of
      credentials, and for the most part uses the subjective credentials when
      accessing current's creds.
      
      There is, however, one exception: cap_capable(), and thus capable(), uses the
      real/objective credentials of the target task, whether or not it is the current
      task.
      
      Ordinarily this doesn't matter, since usually the two cred pointers in current
      point to the same set of creds.  However, sys_faccessat() makes use of this
      facility to override the credentials of the calling process to make its test,
      without affecting the creds as seen from other processes.
      
      One of the things sys_faccessat() does is to make an adjustment to the
      effective capabilities mask, which cap_capable(), as it stands, then ignores.
      
      The affected capability check is in generic_permission():
      
      	if (!(mask & MAY_EXEC) || execute_ok(inode))
      		if (capable(CAP_DAC_OVERRIDE))
      			return 0;
      
      This change passes the set of credentials to be tested down into the commoncap
      and SELinux code.  The security functions called by capable() and
      has_capability() select the appropriate set of credentials from the process
      being checked.
      
      This can be tested by compiling the following program from the XFS testsuite:
      
      /*
       *  t_access_root.c - trivial test program to show permission bug.
       *
       *  Written by Michael Kerrisk - copyright ownership not pursued.
       *  Sourced from: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/6030.html
       */
      #include <limits.h>
      #include <unistd.h>
      #include <stdio.h>
      #include <stdlib.h>
      #include <fcntl.h>
      #include <sys/stat.h>
      
      #define UID 500
      #define GID 100
      #define PERM 0
      #define TESTPATH "/tmp/t_access"
      
      static void
      errExit(char *msg)
      {
          perror(msg);
          exit(EXIT_FAILURE);
      } /* errExit */
      
      static void
      accessTest(char *file, int mask, char *mstr)
      {
          printf("access(%s, %s) returns %d\n", file, mstr, access(file, mask));
      } /* accessTest */
      
      int
      main(int argc, char *argv[])
      {
          int fd, perm, uid, gid;
          char *testpath;
          char cmd[PATH_MAX + 20];
      
          testpath = (argc > 1) ? argv[1] : TESTPATH;
          perm = (argc > 2) ? strtoul(argv[2], NULL, 8) : PERM;
          uid = (argc > 3) ? atoi(argv[3]) : UID;
          gid = (argc > 4) ? atoi(argv[4]) : GID;
      
          unlink(testpath);
      
          fd = open(testpath, O_RDWR | O_CREAT, 0);
          if (fd == -1) errExit("open");
      
          if (fchown(fd, uid, gid) == -1) errExit("fchown");
          if (fchmod(fd, perm) == -1) errExit("fchmod");
          close(fd);
      
          snprintf(cmd, sizeof(cmd), "ls -l %s", testpath);
          system(cmd);
      
          if (seteuid(uid) == -1) errExit("seteuid");
      
          accessTest(testpath, 0, "0");
          accessTest(testpath, R_OK, "R_OK");
          accessTest(testpath, W_OK, "W_OK");
          accessTest(testpath, X_OK, "X_OK");
          accessTest(testpath, R_OK | W_OK, "R_OK | W_OK");
          accessTest(testpath, R_OK | X_OK, "R_OK | X_OK");
          accessTest(testpath, W_OK | X_OK, "W_OK | X_OK");
          accessTest(testpath, R_OK | W_OK | X_OK, "R_OK | W_OK | X_OK");
      
          exit(EXIT_SUCCESS);
      } /* main */
      
      This can be run against an Ext3 filesystem as well as against an XFS
      filesystem.  If successful, it will show:
      
      	[root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
      	---------- 1 dhowells dhowells 0 2008-12-31 03:00 /tmp/xxx
      	access(/tmp/xxx, 0) returns 0
      	access(/tmp/xxx, R_OK) returns 0
      	access(/tmp/xxx, W_OK) returns 0
      	access(/tmp/xxx, X_OK) returns -1
      	access(/tmp/xxx, R_OK | W_OK) returns 0
      	access(/tmp/xxx, R_OK | X_OK) returns -1
      	access(/tmp/xxx, W_OK | X_OK) returns -1
      	access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1
      
      If unsuccessful, it will show:
      
      	[root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
      	---------- 1 dhowells dhowells 0 2008-12-31 02:56 /tmp/xxx
      	access(/tmp/xxx, 0) returns 0
      	access(/tmp/xxx, R_OK) returns -1
      	access(/tmp/xxx, W_OK) returns -1
      	access(/tmp/xxx, X_OK) returns -1
      	access(/tmp/xxx, R_OK | W_OK) returns -1
      	access(/tmp/xxx, R_OK | X_OK) returns -1
      	access(/tmp/xxx, W_OK | X_OK) returns -1
      	access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1
      
      I've also tested the fix with the SELinux and syscalls LTP testsuites.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      3699c53c
    • James Morris's avatar
      Revert "CRED: Fix regression in cap_capable() as shown up by sys_faccessat() [ver #2]" · 29881c45
      James Morris authored
      This reverts commit 14eaddc9.
      
      David has a better version to come.
      29881c45