1. 11 Oct, 2009 2 commits
  2. 10 Sep, 2009 1 commit
    • David P. Quigley's avatar
      LSM/SELinux: inode_{get,set,notify}secctx hooks to access LSM security context information. · 1ee65e37
      David P. Quigley authored
      This patch introduces three new hooks. The inode_getsecctx hook is used to get
      all relevant information from an LSM about an inode. The inode_setsecctx is
      used to set both the in-core and on-disk state for the inode based on a context
      derived from inode_getsecctx.The final hook inode_notifysecctx will notify the
      LSM of a change for the in-core state of the inode in question. These hooks are
      for use in the labeled NFS code and addresses concerns of how to set security
      on an inode in a multi-xattr LSM. For historical reasons Stephen Smalley's
      explanation of the reason for these hooks is pasted below.
      Quote Stephen Smalley
      inode_setsecctx:  Change the security context of an inode.  Updates the
      in core security context managed by the security module and invokes the
      fs code as needed (via __vfs_setxattr_noperm) to update any backing
      xattrs that represent the context.  Example usage:  NFS server invokes
      this hook to change the security context in its incore inode and on the
      backing file system to a value provided by the client on a SETATTR
      inode_notifysecctx:  Notify the security module of what the security
      context of an inode should be.  Initializes the incore security context
      managed by the security module for this inode.  Example usage:  NFS
      client invokes this hook to initialize the security context in its
      incore inode to the value provided by the server for the file when the
      server returned the file's attributes to the client.
      Signed-off-by: default avatarDavid P. Quigley <dpquigl@tycho.nsa.gov>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  3. 02 Sep, 2009 1 commit
    • David Howells's avatar
      KEYS: Add a keyctl to install a process's session keyring on its parent [try #6] · ee18d64c
      David Howells authored
      Add a keyctl to install a process's session keyring onto its parent.  This
      replaces the parent's session keyring.  Because the COW credential code does
      not permit one process to change another process's credentials directly, the
      change is deferred until userspace next starts executing again.  Normally this
      will be after a wait*() syscall.
      To support this, three new security hooks have been provided:
      cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
      the blank security creds and key_session_to_parent() - which asks the LSM if
      the process may replace its parent's session keyring.
      The replacement may only happen if the process has the same ownership details
      as its parent, and the process has LINK permission on the session keyring, and
      the session keyring is owned by the process, and the LSM permits it.
      Note that this requires alteration to each architecture's notify_resume path.
      This has been done for all arches barring blackfin, m68k* and xtensa, all of
      which need assembly alteration to support TIF_NOTIFY_RESUME.  This allows the
      replacement to be performed at the point the parent process resumes userspace
      This allows the userspace AFS pioctl emulation to fully emulate newpag() and
      the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
      alter the parent process's PAG membership.  However, since kAFS doesn't use
      PAGs per se, but rather dumps the keys into the session keyring, the session
      keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
      the newpag flag.
      This can be tested with the following program:
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <keyutils.h>
      	#define KEYCTL_SESSION_TO_PARENT	18
      	#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
      	int main(int argc, char **argv)
      		key_serial_t keyring, key;
      		long ret;
      		keyring = keyctl_join_session_keyring(argv[1]);
      		OSERROR(keyring, "keyctl_join_session_keyring");
      		key = add_key("user", "a", "b", 1, keyring);
      		OSERROR(key, "add_key");
      		ret = keyctl(KEYCTL_SESSION_TO_PARENT);
      		return 0;
      Compiled and linked with -lkeyutils, you should see something like:
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: _ses
      	355907932 --alswrv   4043    -1   \_ keyring: _uid.4043
      	[dhowells@andromeda ~]$ /tmp/newpag
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: _ses
      	1055658746 --alswrv   4043  4043   \_ user: a
      	[dhowells@andromeda ~]$ /tmp/newpag hello
      	[dhowells@andromeda ~]$ keyctl show
      	Session Keyring
      	       -3 --alswrv   4043  4043  keyring: hello
      	340417692 --alswrv   4043  4043   \_ user: a
      Where the test program creates a new session keyring, sticks a user key named
      'a' into it and then installs it on its parent.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  4. 31 Aug, 2009 1 commit
    • Paul Moore's avatar
      lsm: Add hooks to the TUN driver · 2b980dbd
      Paul Moore authored
      The TUN driver lacks any LSM hooks which makes it difficult for LSM modules,
      such as SELinux, to enforce access controls on network traffic generated by
      TUN users; this is particularly problematic for virtualization apps such as
      QEMU and KVM.  This patch adds three new LSM hooks designed to control the
      creation and attachment of TUN devices, the hooks are:
       * security_tun_dev_create()
         Provides access control for the creation of new TUN devices
       * security_tun_dev_post_create()
         Provides the ability to create the necessary socket LSM state for newly
         created TUN devices
       * security_tun_dev_attach()
         Provides access control for attaching to existing, persistent TUN devices
         and the ability to update the TUN device's socket LSM state as necessary
      Signed-off-by: default avatarPaul Moore <paul.moore@hp.com>
      Acked-by: default avatarEric Paris <eparis@parisplace.org>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  5. 17 Aug, 2009 1 commit
  6. 14 Aug, 2009 1 commit
  7. 05 Aug, 2009 1 commit
  8. 24 Jun, 2009 1 commit
  9. 28 Mar, 2009 1 commit
  10. 06 Jan, 2009 1 commit
  11. 05 Jan, 2009 1 commit
    • David Howells's avatar
      CRED: Fix regression in cap_capable() as shown up by sys_faccessat() [ver #2] · 14eaddc9
      David Howells authored
      Fix a regression in cap_capable() due to:
      	commit 5ff7711e635b32f0a1e558227d030c7e45b4a465
      	Author: David Howells <dhowells@redhat.com>
      	Date:   Wed Dec 31 02:52:28 2008 +0000
      	    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
      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 splits capable() from has_capability() down into the commoncap and
      SELinux code.  The capable() security op now only deals with the current
      process, and uses the current process's subjective creds.  A new security op -
      task_capable() - is introduced that can check any task's objective creds.
      strictly the capable() security op is superfluous with the presence of the
      task_capable() op, however it should be faster to call the capable() op since
      two fewer arguments need be passed down through the various layers.
      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)
      } /* errExit */
      static void
      accessTest(char *file, int mask, char *mstr)
          printf("access(%s, %s) returns %d\n", file, mstr, access(file, mask));
      } /* accessTest */
      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;
          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");
          snprintf(cmd, sizeof(cmd), "ls -l %s", testpath);
          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");
      } /* 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>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  12. 31 Dec, 2008 1 commit
  13. 19 Dec, 2008 1 commit
  14. 13 Nov, 2008 5 commits
    • David Howells's avatar
      CRED: Allow kernel services to override LSM settings for task actions · 3a3b7ce9
      David Howells authored
      Allow kernel services to override LSM settings appropriate to the actions
      performed by a task by duplicating a set of credentials, modifying it and then
      using task_struct::cred to point to it when performing operations on behalf of
      a task.
      This is used, for example, by CacheFiles which has to transparently access the
      cache on behalf of a process that thinks it is doing, say, NFS accesses with a
      potentially inappropriate (with respect to accessing the cache) set of
      This patch provides two LSM hooks for modifying a task security record:
       (*) security_kernel_act_as() which allows modification of the security datum
           with which a task acts on other objects (most notably files).
       (*) security_kernel_create_files_as() which allows modification of the
           security datum that is used to initialise the security data on a file that
           a task creates.
      The patch also provides four new credentials handling functions, which wrap the
      LSM functions:
       (1) prepare_kernel_cred()
           Prepare a set of credentials for a kernel service to use, based either on
           a daemon's credentials or on init_cred.  All the keyrings are cleared.
       (2) set_security_override()
           Set the LSM security ID in a set of credentials to a specific security
           context, assuming permission from the LSM policy.
       (3) set_security_override_from_ctx()
           As (2), but takes the security context as a string.
       (4) set_create_files_as()
           Set the file creation LSM security ID in a set of credentials to be the
           same as that on a particular inode.
      Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> [Smack changes]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • David Howells's avatar
      CRED: Make execve() take advantage of copy-on-write credentials · a6f76f23
      David Howells authored
      Make execve() take advantage of copy-on-write credentials, allowing it to set
      up the credentials in advance, and then commit the whole lot after the point
      of no return.
      This patch and the preceding patches have been tested with the LTP SELinux
      This patch makes several logical sets of alteration:
       (1) execve().
           The credential bits from struct linux_binprm are, for the most part,
           replaced with a single credentials pointer (bprm->cred).  This means that
           all the creds can be calculated in advance and then applied at the point
           of no return with no possibility of failure.
           I would like to replace bprm->cap_effective with:
           but this seems impossible due to special behaviour for processes of pid 1
           (they always retain their parent's capability masks where normally they'd
           be changed - see cap_bprm_set_creds()).
           The following sequence of events now happens:
           (a) At the start of do_execve, the current task's cred_exec_mutex is
           	 locked to prevent PTRACE_ATTACH from obsoleting the calculation of
           	 creds that we make.
           (a) prepare_exec_creds() is then called to make a copy of the current
           	 task's credentials and prepare it.  This copy is then assigned to
        	 This renders security_bprm_alloc() and security_bprm_free()
           	 unnecessary, and so they've been removed.
           (b) The determination of unsafe execution is now performed immediately
           	 after (a) rather than later on in the code.  The result is stored in
           	 bprm->unsafe for future reference.
           (c) prepare_binprm() is called, possibly multiple times.
           	 (i) This applies the result of set[ug]id binaries to the new creds
           	     attached to bprm->cred.  Personality bit clearance is recorded,
           	     but now deferred on the basis that the exec procedure may yet
               (ii) This then calls the new security_bprm_set_creds().  This should
      	     calculate the new LSM and capability credentials into *bprm->cred.
      	     This folds together security_bprm_set() and parts of
      	     security_bprm_apply_creds() (these two have been removed).
      	     Anything that might fail must be done at this point.
               (iii) bprm->cred_prepared is set to 1.
      	     bprm->cred_prepared is 0 on the first pass of the security
      	     calculations, and 1 on all subsequent passes.  This allows SELinux
      	     in (ii) to base its calculations only on the initial script and
      	     not on the interpreter.
           (d) flush_old_exec() is called to commit the task to execution.  This
           	 performs the following steps with regard to credentials:
      	 (i) Clear pdeath_signal and set dumpable on certain circumstances that
      	     may not be covered by commit_creds().
               (ii) Clear any bits in current->personality that were deferred from
           (e) install_exec_creds() [compute_creds() as was] is called to install the
           	 new credentials.  This performs the following steps with regard to
               (i) Calls security_bprm_committing_creds() to apply any security
                   requirements, such as flushing unauthorised files in SELinux, that
                   must be done before the credentials are changed.
      	     This is made up of bits of security_bprm_apply_creds() and
      	     security_bprm_post_apply_creds(), both of which have been removed.
      	     This function is not allowed to fail; anything that might fail
      	     must have been done in (c.ii).
               (ii) Calls commit_creds() to apply the new credentials in a single
                   assignment (more or less).  Possibly pdeath_signal and dumpable
                   should be part of struct creds.
      	 (iii) Unlocks the task's cred_replace_mutex, thus allowing
      	     PTRACE_ATTACH to take place.
               (iv) Clears The bprm->cred pointer as the credentials it was holding
                   are now immutable.
               (v) Calls security_bprm_committed_creds() to apply any security
                   alterations that must be done after the creds have been changed.
                   SELinux uses this to flush signals and signal handlers.
           (f) If an error occurs before (d.i), bprm_free() will call abort_creds()
           	 to destroy the proposed new credentials and will then unlock
           	 cred_replace_mutex.  No changes to the credentials will have been
       (2) LSM interface.
           A number of functions have been changed, added or removed:
           (*) security_bprm_alloc(), ->bprm_alloc_security()
           (*) security_bprm_free(), ->bprm_free_security()
           	 Removed in favour of preparing new credentials and modifying those.
           (*) security_bprm_apply_creds(), ->bprm_apply_creds()
           (*) security_bprm_post_apply_creds(), ->bprm_post_apply_creds()
           	 Removed; split between security_bprm_set_creds(),
           	 security_bprm_committing_creds() and security_bprm_committed_creds().
           (*) security_bprm_set(), ->bprm_set_security()
           	 Removed; folded into security_bprm_set_creds().
           (*) security_bprm_set_creds(), ->bprm_set_creds()
           	 New.  The new credentials in bprm->creds should be checked and set up
           	 as appropriate.  bprm->cred_prepared is 0 on the first call, 1 on the
           	 second and subsequent calls.
           (*) security_bprm_committing_creds(), ->bprm_committing_creds()
           (*) security_bprm_committed_creds(), ->bprm_committed_creds()
           	 New.  Apply the security effects of the new credentials.  This
           	 includes closing unauthorised files in SELinux.  This function may not
           	 fail.  When the former is called, the creds haven't yet been applied
           	 to the process; when the latter is called, they have.
       	 The former may access bprm->cred, the latter may not.
       (3) SELinux.
           SELinux has a number of changes, in addition to those to support the LSM
           interface changes mentioned above:
           (a) The bprm_security_struct struct has been removed in favour of using
           	 the credentials-under-construction approach.
           (c) flush_unauthorized_files() now takes a cred pointer and passes it on
           	 to inode_has_perm(), file_has_perm() and dentry_open().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • David Howells's avatar
      CRED: Inaugurate COW credentials · d84f4f99
      David Howells authored
      Inaugurate copy-on-write credentials management.  This uses RCU to manage the
      credentials pointer in the task_struct with respect to accesses by other tasks.
      A process may only modify its own credentials, and so does not need locking to
      access or modify its own credentials.
      A mutex (cred_replace_mutex) is added to the task_struct to control the effect
      of PTRACE_ATTACHED on credential calculations, particularly with respect to
      With this patch, the contents of an active credentials struct may not be
      changed directly; rather a new set of credentials must be prepared, modified
      and committed using something like the following sequence of events:
      	struct cred *new = prepare_creds();
      	int ret = blah(new);
      	if (ret < 0) {
      		return ret;
      	return commit_creds(new);
      There are some exceptions to this rule: the keyrings pointed to by the active
      credentials may be instantiated - keyrings violate the COW rule as managing
      COW keyrings is tricky, given that it is possible for a task to directly alter
      the keys in a keyring in use by another task.
      To help enforce this, various pointers to sets of credentials, such as those in
      the task_struct, are declared const.  The purpose of this is compile-time
      discouragement of altering credentials through those pointers.  Once a set of
      credentials has been made public through one of these pointers, it may not be
      modified, except under special circumstances:
        (1) Its reference count may incremented and decremented.
        (2) The keyrings to which it points may be modified, but not replaced.
      The only safe way to modify anything else is to create a replacement and commit
      using the functions described in Documentation/credentials.txt (which will be
      added by a later patch).
      This patch and the preceding patches have been tested with the LTP SELinux
      This patch makes several logical sets of alteration:
       (1) execve().
           This now prepares and commits credentials in various places in the
           security code rather than altering the current creds directly.
       (2) Temporary credential overrides.
           do_coredump() and sys_faccessat() now prepare their own credentials and
           temporarily override the ones currently on the acting thread, whilst
           preventing interference from other threads by holding cred_replace_mutex
           on the thread being dumped.
           This will be replaced in a future patch by something that hands down the
           credentials directly to the functions being called, rather than altering
           the task's objective credentials.
       (3) LSM interface.
           A number of functions have been changed, added or removed:
           (*) security_capset_check(), ->capset_check()
           (*) security_capset_set(), ->capset_set()
           	 Removed in favour of security_capset().
           (*) security_capset(), ->capset()
           	 New.  This is passed a pointer to the new creds, a pointer to the old
           	 creds and the proposed capability sets.  It should fill in the new
           	 creds or return an error.  All pointers, barring the pointer to the
           	 new creds, are now const.
           (*) security_bprm_apply_creds(), ->bprm_apply_creds()
           	 Changed; now returns a value, which will cause the process to be
           	 killed if it's an error.
           (*) security_task_alloc(), ->task_alloc_security()
           	 Removed in favour of security_prepare_creds().
           (*) security_cred_free(), ->cred_free()
           	 New.  Free security data attached to cred->security.
           (*) security_prepare_creds(), ->cred_prepare()
           	 New. Duplicate any security data attached to cred->security.
           (*) security_commit_creds(), ->cred_commit()
           	 New. Apply any security effects for the upcoming installation of new
           	 security by commit_creds().
           (*) security_task_post_setuid(), ->task_post_setuid()
           	 Removed in favour of security_task_fix_setuid().
           (*) security_task_fix_setuid(), ->task_fix_setuid()
           	 Fix up the proposed new credentials for setuid().  This is used by
           	 cap_set_fix_setuid() to implicitly adjust capabilities in line with
           	 setuid() changes.  Changes are made to the new credentials, rather
           	 than the task itself as in security_task_post_setuid().
           (*) security_task_reparent_to_init(), ->task_reparent_to_init()
           	 Removed.  Instead the task being reparented to init is referred
           	 directly to init's credentials.
      	 NOTE!  This results in the loss of some state: SELinux's osid no
      	 longer records the sid of the thread that forked it.
           (*) security_key_alloc(), ->key_alloc()
           (*) security_key_permission(), ->key_permission()
           	 Changed.  These now take cred pointers rather than task pointers to
           	 refer to the security context.
       (4) sys_capset().
           This has been simplified and uses less locking.  The LSM functions it
           calls have been merged.
       (5) reparent_to_kthreadd().
           This gives the current thread the same credentials as init by simply using
           commit_thread() to point that way.
       (6) __sigqueue_alloc() and switch_uid()
           __sigqueue_alloc() can't stop the target task from changing its creds
           beneath it, so this function gets a reference to the currently applicable
           user_struct which it then passes into the sigqueue struct it returns if
           switch_uid() is now called from commit_creds(), and possibly should be
           folded into that.  commit_creds() should take care of protecting
       (7) [sg]et[ug]id() and co and [sg]et_current_groups.
           The set functions now all use prepare_creds(), commit_creds() and
           abort_creds() to build and check a new set of credentials before applying
           security_task_set[ug]id() is called inside the prepared section.  This
           guarantees that nothing else will affect the creds until we've finished.
           The calling of set_dumpable() has been moved into commit_creds().
           Much of the functionality of set_user() has been moved into
           The get functions all simply access the data directly.
       (8) security_task_prctl() and cap_task_prctl().
           security_task_prctl() has been modified to return -ENOSYS if it doesn't
           want to handle a function, or otherwise return the return value directly
           rather than through an argument.
           Additionally, cap_task_prctl() now prepares a new set of credentials, even
           if it doesn't end up using it.
       (9) Keyrings.
           A number of changes have been made to the keyrings code:
           (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
           	 all been dropped and built in to the credentials functions directly.
           	 They may want separating out again later.
           (b) key_alloc() and search_process_keyrings() now take a cred pointer
           	 rather than a task pointer to specify the security context.
           (c) copy_creds() gives a new thread within the same thread group a new
           	 thread keyring if its parent had one, otherwise it discards the thread
           (d) The authorisation key now points directly to the credentials to extend
           	 the search into rather pointing to the task that carries them.
           (e) Installing thread, process or session keyrings causes a new set of
           	 credentials to be created, even though it's not strictly necessary for
           	 process or session keyrings (they're shared).
      (10) Usermode helper.
           The usermode helper code now carries a cred struct pointer in its
           subprocess_info struct instead of a new session keyring pointer.  This set
           of credentials is derived from init_cred and installed on the new process
           after it has been cloned.
           call_usermodehelper_setup() allocates the new credentials and
           call_usermodehelper_freeinfo() discards them if they haven't been used.  A
           special cred function (prepare_usermodeinfo_creds()) is provided
           specifically for call_usermodehelper_setup() to call.
           call_usermodehelper_setkeys() adjusts the credentials to sport the
           supplied keyring as the new session keyring.
      (11) SELinux.
           SELinux has a number of changes, in addition to those to support the LSM
           interface changes mentioned above:
           (a) selinux_setprocattr() no longer does its check for whether the
           	 current ptracer can access processes with the new SID inside the lock
           	 that covers getting the ptracer's SID.  Whilst this lock ensures that
           	 the check is done with the ptracer pinned, the result is only valid
           	 until the lock is released, so there's no point doing it inside the
      (12) is_single_threaded().
           This function has been extracted from selinux_setprocattr() and put into
           a file of its own in the lib/ directory as join_session_keyring() now
           wants to use it too.
           The code in SELinux just checked to see whether a task shared mm_structs
           with other tasks (CLONE_VM), but that isn't good enough.  We really want
           to know if they're part of the same thread group (CLONE_THREAD).
      (13) nfsd.
           The NFS server daemon now has to use the COW credentials to set the
           credentials it is going to use.  It really needs to pass the credentials
           down to the functions it calls, but it can't do that until other patches
           in this series have been applied.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • David Howells's avatar
      CRED: Pass credentials through dentry_open() · 745ca247
      David Howells authored
      Pass credentials through dentry_open() so that the COW creds patch can have
      SELinux's flush_unauthorized_files() pass the appropriate creds back to itself
      when it opens its null chardev.
      The security_dentry_open() call also now takes a creds pointer, as does the
      dentry_open hook in struct security_operations.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • David Howells's avatar
      CRED: Detach the credentials from task_struct · f1752eec
      David Howells authored
      Detach the credentials from task_struct, duplicating them in copy_process()
      and releasing them in __put_task_struct().
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  15. 14 Aug, 2008 1 commit
    • David Howells's avatar
      security: Fix setting of PF_SUPERPRIV by __capable() · 5cd9c58f
      David Howells authored
      Fix the setting of PF_SUPERPRIV by __capable() as it could corrupt the flags
      the target process if that is not the current process and it is trying to
      change its own flags in a different way at the same time.
      __capable() is using neither atomic ops nor locking to protect t->flags.  This
      patch removes __capable() and introduces has_capability() that doesn't set
      PF_SUPERPRIV on the process being queried.
      This patch further splits security_ptrace() in two:
       (1) security_ptrace_may_access().  This passes judgement on whether one
           process may access another only (PTRACE_MODE_ATTACH for ptrace() and
           PTRACE_MODE_READ for /proc), and takes a pointer to the child process.
           current is the parent.
       (2) security_ptrace_traceme().  This passes judgement on PTRACE_TRACEME only,
           and takes only a pointer to the parent process.  current is the child.
           In Smack and commoncap, this uses has_capability() to determine whether
           the parent will be permitted to use PTRACE_ATTACH if normal checks fail.
           This does not set PF_SUPERPRIV.
      Two of the instances of __capable() actually only act on current, and so have
      been changed to calls to capable().
      Of the places that were using __capable():
       (1) The OOM killer calls __capable() thrice when weighing the killability of a
           process.  All of these now use has_capability().
       (2) cap_ptrace() and smack_ptrace() were using __capable() to check to see
           whether the parent was allowed to trace any process.  As mentioned above,
           these have been split.  For PTRACE_ATTACH and /proc, capable() is now
           used, and for PTRACE_TRACEME, has_capability() is used.
       (3) cap_safe_nice() only ever saw current, so now uses capable().
       (4) smack_setprocattr() rejected accesses to tasks other than current just
           after calling __capable(), so the order of these two tests have been
           switched and capable() is used instead.
       (5) In smack_file_send_sigiotask(), we need to allow privileged processes to
           receive SIGIO on files they're manipulating.
       (6) In smack_task_wait(), we let a process wait for a privileged process,
           whether or not the process doing the waiting is privileged.
      I've tested this with the LTP SELinux and syscalls testscripts.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Acked-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Acked-by: default avatarAndrew G. Morgan <morgan@kernel.org>
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  16. 27 Jul, 2008 1 commit
  17. 14 Jul, 2008 2 commits
  18. 28 Apr, 2008 1 commit
    • Andrew G. Morgan's avatar
      capabilities: implement per-process securebits · 3898b1b4
      Andrew G. Morgan authored
      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: default avatarAndrew G. Morgan <morgan@kernel.org>
      Acked-by: default avatarSerge Hallyn <serue@us.ibm.com>
      Reviewed-by: default avatarJames Morris <jmorris@namei.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Paul Moore <paul.moore@hp.com>
      Signed-off-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  19. 20 Mar, 2008 1 commit
  20. 17 Oct, 2007 2 commits
    • Serge E. Hallyn's avatar
      Implement file posix capabilities · b5376771
      Serge E. Hallyn authored
      Implement file posix capabilities.  This allows programs to be given a
      subset of root's powers regardless of who runs them, without having to use
      setuid and giving the binary all of root's powers.
      This version works with Kaigai Kohei's userspace tools, found at
      http://www.kaigai.gr.jp/index.php.  For more information on how to use this
      patch, Chris Friedhoff has posted a nice page at
      	Nov 27:
      	Incorporate fixes from Andrew Morton
      	(security-introduce-file-caps-tweaks and
      	Fix Kconfig dependency.
      	Fix change signaling behavior when file caps are not compiled in.
      	Nov 13:
      	Integrate comments from Alexey: Remove CONFIG_ ifdef from
      	capability.h, and use %zd for printing a size_t.
      	Nov 13:
      	Fix endianness warnings by sparse as suggested by Alexey
      	Nov 09:
      	Address warnings of unused variables at cap_bprm_set_security
      	when file capabilities are disabled, and simultaneously clean
      	up the code a little, by pulling the new code into a helper
      	Nov 08:
      	For pointers to required userspace tools and how to use
      	them, see http://www.friedhoff.org/fscaps.html
      	Nov 07:
      	Fix the calculation of the highest bit checked in
      	Nov 07:
      	Allow file caps to be enabled without CONFIG_SECURITY, since
      	capabilities are the default.
      	Hook cap_task_setscheduler when !CONFIG_SECURITY.
      	Move capable(TASK_KILL) to end of cap_task_kill to reduce
      	audit messages.
      	Nov 05:
      	Add secondary calls in selinux/hooks.c to task_setioprio and
      	task_setscheduler so that selinux and capabilities with file
      	cap support can be stacked.
      	Sep 05:
      	As Seth Arnold points out, uid checks are out of place
      	for capability code.
      	Sep 01:
      	Define task_setscheduler, task_setioprio, cap_task_kill, and
      	task_setnice to make sure a user cannot affect a process in which
      	they called a program with some fscaps.
      	One remaining question is the note under task_setscheduler: are we
      	ok with CAP_SYS_NICE being sufficient to confine a process to a
      	It is a semantic change, as without fsccaps, attach_task doesn't
      	allow CAP_SYS_NICE to override the uid equivalence check.  But since
      	it uses security_task_setscheduler, which elsewhere is used where
      	CAP_SYS_NICE can be used to override the uid equivalence check,
      	fixing it might be tough.
      		 note: this also controls cpuset:attach_task.  Are we ok with
      		     CAP_SYS_NICE being used to confine to a cpuset?
      		 sys_setpriority uses this (through set_one_prio) for another
      		 process.  Need same checks as setrlimit
      	Aug 21:
      	Updated secureexec implementation to reflect the fact that
      	euid and uid might be the same and nonzero, but the process
      	might still have elevated caps.
      	Aug 15:
      	Handle endianness of xattrs.
      	Enforce capability version match between kernel and disk.
      	Enforce that no bits beyond the known max capability are
      	set, else return -EPERM.
      	With this extra processing, it may be worth reconsidering
      	doing all the work at bprm_set_security rather than
      	Aug 10:
      	Always call getxattr at bprm_set_security, rather than
      	caching it at d_instantiate.
      [morgan@kernel.org: file-caps clean up for linux/capability.h]
      [bunk@kernel.org: unexport cap_inode_killpriv]
      Signed-off-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Andrew Morgan <morgan@kernel.org>
      Signed-off-by: default avatarAndrew Morgan <morgan@kernel.org>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • James Morris's avatar
      security: Convert LSM into a static interface · 20510f2f
      James Morris authored
      Convert LSM into a static interface, as the ability to unload a security
      module is not required by in-tree users and potentially complicates the
      overall security architecture.
      Needlessly exported LSM symbols have been unexported, to help reduce API
      Parameters for the capability and root_plug modules are now specified
      at boot.
      The SECURITY_FRAMEWORK_VERSION macro has also been removed.
      In a nutshell, there is no safe way to unload an LSM.  The modular interface
      is thus unecessary and broken infrastructure.  It is used only by out-of-tree
      modules, which are often binary-only, illegal, abusive of the API and
      dangerous, e.g.  silently re-vectoring SELinux.
      [akpm@linux-foundation.org: cleanups]
      [akpm@linux-foundation.org: USB Kconfig fix]
      [randy.dunlap@oracle.com: fix LSM kernel-doc]
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Acked-by: default avatarChris Wright <chrisw@sous-sol.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: "Serge E. Hallyn" <serue@us.ibm.com>
      Acked-by: default avatarArjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  21. 08 May, 2007 1 commit
  22. 30 Jun, 2006 1 commit
  23. 06 Jan, 2006 1 commit
    • Sam Ravnborg's avatar
      kbuild: un-stringnify KBUILD_MODNAME · 367cb704
      Sam Ravnborg authored
      Now when kbuild passes KBUILD_MODNAME with "" do not __stringify it when
      used. Remove __stringnify for all users.
      This also fixes the output of:
      $ ls -l /sys/module/
      drwxr-xr-x 4 root root 0 2006-01-05 14:24 pcmcia
      drwxr-xr-x 4 root root 0 2006-01-05 14:24 pcmcia_core
      drwxr-xr-x 3 root root 0 2006-01-05 14:24 "processor"
      drwxr-xr-x 3 root root 0 2006-01-05 14:24 "psmouse"
      The quoting of the module names will be gone again.
      Thanks to GregKH + Kay Sievers for reproting this.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
  24. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!