An error occurred fetching the project authors.
  1. 03 Jan, 2005 1 commit
    • Andries E. Brouwer's avatar
      [PATCH] mm: overcommit updates · ea86630e
      Andries E. Brouwer authored
      Alan made overcommit mode 2 and it doesnt work at all.  A process passing
      the limit often does so at a moment of stack extension, and is killed by a
      segfault, not better than being OOM-killed.
      
      Another problem is that close to the edge no other processes can be
      started, so that a sysadmin has problems logging in and investigating.
      
      Below a patch that does 3 things:
      
      (1) It reserves a reasonable amount of virtual stack space (amount
          randomly chosen, no guarantees given) when the process is started, so
          that the common utilities will not be killed by segfault on stack
          extension.
      
      (2) It reserves a reasonable amount of virtual memory for root, so that
          root can do things when the system is out-of-memory
      
      (3) It limits a single process to 97% of what is left, so that also an
          ordinary user is able to use getty, login, bash, ps, kill and similar
          things when one of her processes got out of control.
      
      Since the current overcommit mode 2 is not really useful, I did not give
      this a new number.
      
      The patch is just for playing, not to be applied by Linus.  But, Andrew, I
      hope that you would be willing to put this in -mm so that people can
      experiment.  Of course it only does something if one sets overcommit mode
      to 2.
      
      The past month I have pressured people asking for feedback, and now have
      about a dozen reports, mostly positive, one very positive.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ea86630e
  2. 25 Oct, 2004 1 commit
  3. 20 Oct, 2004 1 commit
  4. 30 Sep, 2004 1 commit
    • Andries E. Brouwer's avatar
      [PATCH] overcommit symbolic constants · 23782705
      Andries E. Brouwer authored
      Played a bit with overcommit the past hour.
      
      Am not entirely satisfied with the no overcommit mode 2 -
      programs segfault when the system is close to that boundary.
      So, instead of the somewhat larger patch that I planned to send,
      just symbolic names for the modes.
      23782705
  5. 03 Sep, 2004 1 commit
    • Alan Cox's avatar
      [PATCH] Root reservations for strict overcommit · 157ac241
      Alan Cox authored
      This was on my TODO list for a while and it turns out someone already fixed
      the armwaving overcommit mode for the same problem.  It is easy to get into
      a situation where you have no overcommit and nothing can be done because
      there is no memory to clean up the stable but non-useful state of the
      machine.
      
      The fix is trivial and duplicated from the armwaving overcommit code path. 
      The last 3% of the memory can be claimed by root processes only.  It isn't
      a cure but it does seem to solve the real world problems - at least
      providing you have enough memory for 3% to be useful 8).
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      157ac241
  6. 10 May, 2004 1 commit
  7. 26 Apr, 2004 1 commit
    • Andrew Morton's avatar
      [PATCH] credentials locking fix · 10c189cd
      Andrew Morton authored
      From: Chris Wright <chrisw@osdl.org>
      
      Contributions from:
      Stephen Smalley <sds@epoch.ncsc.mil>
      Andy Lutomirski <luto@stanford.edu>
      
      During exec the LSM bprm_apply_creds() hooks may tranisition the program to a
      new security context (like setuid binaries).  The security context of the new
      task is dependent on state such as if the task is being ptraced.  
      
      ptrace_detach() doesn't take the task_lock() when clearing task->ptrace.  So
      there is a race possible where a process starts off being ptraced, the
      malicious ptracer detaches and if any checks agains task->ptrace are done more
      than once, the results are indeterminate.
      
      This patch ensures task_lock() is held while bprm_apply_creds() hooks are
      called, keeping it safe against ptrace_attach() races.  Additionally, tests
      against task->ptrace (and ->fs->count, ->files->count and ->sighand->count all
      of which signify potential unsafe resource sharing during a security context
      transition) are done only once the results are passed down to hooks, making it
      safe against ptrace_detach() races.
      
      Additionally:
      
      - s/must_must_not_trace_exec/unsafe_exec/
      - move unsafe_exec() call above security_bprm_apply_creds() call rather than
        in call for readability.
      - fix dummy hook to honor the case where root is ptracing
      - couple minor formatting/spelling fixes
      10c189cd
  8. 21 Apr, 2004 1 commit
    • Andrew Morton's avatar
      [PATCH] compute_creds race · b7fbe52c
      Andrew Morton authored
      From: Andy Lutomirski <luto@myrealbox.com>
      
      Fixes from me, Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de>
      
      In fs/exec.c, compute_creds does:
      
      	task_lock(current);
      	if (bprm->e_uid != current->uid || bprm->e_gid != current->gid) {
                       current->mm->dumpable = 0;
      
      		if (must_not_trace_exec(current)
      		    || atomic_read(&current->fs->count) > 1
      		    || atomic_read(&current->files->count) > 1
      		    || atomic_read(&current->sighand->count) > 1) {
      			if(!capable(CAP_SETUID)) {
      				bprm->e_uid = current->uid;
      				bprm->e_gid = current->gid;
      			}
      		}
      	}
      
               current->suid = current->euid = current->fsuid = bprm->e_uid;
               current->sgid = current->egid = current->fsgid = bprm->e_gid;
      
      	task_unlock(current);
      
      	security_bprm_compute_creds(bprm);
      
      I assume the task_lock is to prevent another process (on SMP or preempt)
      from ptracing the execing process between the check and the assignment.  If
      that's the concern then the fact that the lock is dropped before the call
      to security_brpm_compute_creds means that, if security_bprm_compute_creds
      does anything interesting, there's a race.
      
      For my (nearly complete) caps patch, I obviously need to fix this.  But I
      think it may be exploitable now.  Suppose there are two processes, A (the
      malicious code) and B (which uses exec).  B starts out unprivileged (A and
      B have, e.g., uid and euid = 500).
      
      1. A ptraces B.
      
      2. B calls exec on some setuid-root program.
      
      3. in cap_bprm_set_security, B sets bprm->cap_permitted to the full
         set.
      
      4. B gets to compute_creds in exec.c, calls task_lock, and does not
         change its uid.
      
      5. B calls task_unlock.
      
      6. A detaches from B (on preempt or SMP).
      
      7. B gets to task_lock in cap_bprm_compute_creds, changes its
         capabilities, and returns from compute_creds into load_elf_binary.
      
      8. load_elf_binary calls create_elf_tables (line 852 in 2.6.5-mm1),
         which calls cap_bprm_secureexec (through LSM), which returns false (!).
      
      9. exec finishes.
      
      The setuid program is now running with uid=euid=500 but full permitted
      capabilities.  There are two (or three) ways to effectively get local root
      now:
      
      1.  IIRC, linux 2.4 doesn't check capabilities in ptrace, so A could
         just ptrace B again.
      
      2. LD_PRELOAD.
      
      3.  There are probably programs that will misbehave on their own under
         these circumstances.
      
      Is there some reason why this is not doable?
      
      The patch renames bprm_compute_creds to bprm_apply_creds and moves all uid
      logic into the hook, where the test and the resulting modification can both
      happen under task_lock().
      
      This way, out-of-tree LSMs will fail to compile instead of malfunctioning. 
      It should also make life easier for LSMs and will certainly make it easier
      for me to finish the cap patch.
      b7fbe52c
  9. 01 Apr, 2004 1 commit
    • Andrew Morton's avatar
      [PATCH] Fix hugetlb-vs-memory overcommit · c1c0d518
      Andrew Morton authored
      From: Andy Whitcroft <apw@shadowen.org>
      
      Two problems:
      
      a) The memory overcommit code fails oto take into account all the pages
         which are pinned by being reserved for the hugetlbpage pool
      
      b) We're performing overcommit accounting and checking on behalf of
         hugetlbpage vmas.
      
      The main thrust is to ensure that VM_ACCOUNT actually only gets set on
      vma's which are indeed accountable.  With that ensured much of the rest
      comes out in the wash.  It also removes the hugetlb memory for the
      overcommit_memory=2 case.
      c1c0d518
  10. 18 Mar, 2004 1 commit
    • Andrew Morton's avatar
      [PATCH] VM overcommit documentation fixes · 2860cb86
      Andrew Morton authored
      From: Andy Whitcroft <andyw@uk.ibm.com>
      
      Whilst looking at the memory overcommit logic I noticed that the pointer to
      the documentation from the *_vm_enough_memory calls is incorrect.  Also
      that in one instance the routine does not have the expected pointers.
      2860cb86
  11. 04 Feb, 2004 1 commit
    • Andrew Morton's avatar
      [PATCH] rate limit nr_free_pages · c7f6fcf5
      Andrew Morton authored
      From: Jes Sorensen <jes@trained-monkey.org>
      
      nr_free_pages() is expensive, especially on large SMP machines.  The patch
      changes the memory overcommit code so that it only calls nr_free_pages() is
      we're about to fail the allocation attempt.
      c7f6fcf5
  12. 20 Jan, 2004 1 commit
    • Andrew Morton's avatar
      [PATCH] Default hooks protecting the XATTR_SECURITY_PREFIX namespace · 3ba6fffc
      Andrew Morton authored
      From: Chris Wright <chrisw@osdl.org>
      
      Add default hooks for both the dummy and capability code to protect the
      XATTR_SECURITY_PREFIX namespace.  These EAs were fully accessible to
      unauthorized users, so a user that rebooted from an SELinux kernel to a
      default kernel would leave those critical EAs unprotected.
      
      (Acked by Stephen Smalley)
      3ba6fffc
  13. 17 Sep, 2003 1 commit
    • Chris Wright's avatar
      [PATCH] root_plug fixup · e984a6dc
      Chris Wright authored
       From: bert hubert <ahu@ds9a.nl>
      
       LSM: To recap, this patch allows root_plug to work again. It needs functions
       that used to reside in capability.c but linking in capability.c, disabled
       root_plug from loading, as a security module is already present then. This
       patch splits out the functions root_plug needs from capability.c.
      e984a6dc
  14. 31 Aug, 2003 1 commit
  15. 02 Jul, 2003 1 commit
    • Andrew Morton's avatar
      [PATCH] Security hook for vm_enough_memory · bc75ac4f
      Andrew Morton authored
      From: Stephen Smalley <sds@epoch.ncsc.mil>
      
      This patch against 2.5.73 replaces vm_enough_memory with a security hook
      per Alan Cox's suggestion so that security modules can completely replace
      the logic if desired.
      
      Note that the patch changes the interface to follow the convention of the
      other security hooks, i.e.  return 0 if ok or -errno on failure (-ENOMEM in
      this case) rather than returning a boolean.  It also exports various
      variables and functions required for the vm_enough_memory logic.
      bc75ac4f
  16. 25 Jun, 2003 1 commit
    • Andrew Morton's avatar
      [PATCH] AT_SECURE auxv entry · 177be0a4
      Andrew Morton authored
      From: Stephen Smalley <sds@epoch.ncsc.mil>
      
      This patch adds an AT_SECURE auxv entry to pass a boolean flag indicating
      whether "secure mode" should be enabled (i.e.  sanitize the environment,
      initial descriptors, etc) and allows each security module to specify the
      flag value via a new hook.
      
      New userland can then simply obey this flag when present rather than
      applying other methods of deciding (sample patch for glibc-2.3.2 can be
      found at http://www.cs.utah.edu/~sds/glibc-secureexec.patch).
      
      This change enables security modules like SELinux to request secure mode
      upon changes to other security attributes (e.g.  capabilities,
      roles/domains, etc) in addition to uid/gid changes or even to completely
      override the legacy logic.
      
      The legacy decision algorithm is preserved in the default hook functions
      for the dummy and capability security modules.
      
      Credit for the idea of adding an AT_SECURE auxv entry goes to Roland
      McGrath.
      177be0a4
  17. 13 Jun, 2003 2 commits
    • Chris Wright's avatar
      [PATCH] lsm: Remove task_kmod_set_label hook (2/4) · 35190709
      Chris Wright authored
      The task_kmod_set_label hook is no longer necessary.
      
      kmod is now handled by keventd which already does reparent_to_init, so
      there is no need to worry about getting the security labels right for
      code running off the keventd workqueue.
      35190709
    • Chris Wright's avatar
      [PATCH] lsm: Early init for security modules (1/4) · 553bd5a2
      Chris Wright authored
      As discussed before, this allows for early initialization of security
      modules when compiled statically into the kernel.  The standard
      do_initcalls is too late for complete coverage of all filesystems and
      threads, for example.
      553bd5a2
  18. 15 Feb, 2003 1 commit
  19. 07 Feb, 2003 1 commit
    • Linus Torvalds's avatar
      Split up "struct signal_struct" into "signal" and "sighand" parts. · 8eae2998
      Linus Torvalds authored
      This is required to get make the old LinuxThread semantics work
      together with the fixed-for-POSIX full signal sharing. A traditional
      CLONE_SIGHAND thread (LinuxThread) will not see any other shared
      signal state, while a new-style CLONE_THREAD thread will share all
      of it.
      
      This way the two methods don't confuse each other.
      8eae2998
  20. 06 Feb, 2003 2 commits
    • James Morris's avatar
      d5a92560
    • Stephen D. Smalley's avatar
      [PATCH] LSM: Add LSM syslog hook to 2.5.59 · 7c9bf63f
      Stephen D. Smalley authored
      This patch adds the LSM security_syslog hook for controlling the
      syslog(2) interface relative to 2.5.59 plus the previously posted
      security_sysctl patch.  In response to earlier comments by Christoph,
      the existing capability check for syslog(2) is moved into the
      capability security module hook function, and a corresponding dummy
      security module hook function is defined that provides traditional
      superuser behavior.  The LSM hook is placed in do_syslog rather than
      sys_syslog so that it is called when either the system call interface
      or the /proc/kmsg interface is used.  SELinux uses this hook to
      control access to the kernel message ring and to the console log
      level.
      7c9bf63f
  21. 02 Feb, 2003 1 commit
    • Andrew Morton's avatar
      [PATCH] remove lock_kernel() from exec of setuid apps · 3b149cc7
      Andrew Morton authored
      Patch from Manfred Spraul <manfred@colorfullife.com>
      
      exec of setuid apps and ptrace must be synchronized, to ensure that a normal
      user cannot ptrace a setuid app across exec.  ptrace_attach acquires the
      task_lock around the uid checks, compute_creds acquires the BLK.  The patch
      converts compute_creds to the task_lock.  Additionally, it removes the
      do_unlock variable: the task_lock is not heaviliy used, there is no need to
      avoid the spinlock by adding branches.
      
      The patch is a cleanup patch, not a fix for a security problem: AFAICS the
      sys_ptrace in every arch acquires the BKL before calling ptrace_attach.
      3b149cc7
  22. 04 Dec, 2002 1 commit
  23. 18 Nov, 2002 1 commit
    • Andries E. Brouwer's avatar
      [PATCH] inode_mknod parameters · 65b5db50
      Andries E. Brouwer authored
      These security_ops are declared like
      
              int (*inode_mknod) (struct inode *dir, struct dentry *dentry,
                                  int mode, dev_t dev);
      
      with a mode and a dev_t argument.
      
      But the users mistakenly had major, minor instead of mode, dev.
      65b5db50
  24. 29 Oct, 2002 1 commit
  25. 17 Oct, 2002 2 commits
  26. 08 Oct, 2002 1 commit
    • Stephen D. Smalley's avatar
      [PATCH] Base set of LSM hooks for SysV IPC · f9274840
      Stephen D. Smalley authored
      The patch below adds the base set of LSM hooks for System V IPC to the
      2.5.41 kernel.  These hooks permit a security module to label
      semaphore sets, message queues, and shared memory segments and to
      perform security checks on these objects that parallel the existing
      IPC access checks.  Additional LSM hooks for labeling and controlling
      individual messages sent on a single message queue and for providing
      fine-grained distinctions among IPC operations will be submitted
      separately after this base set of LSM IPC hooks has been accepted.
      f9274840
  27. 29 Jul, 2002 1 commit
  28. 22 Jul, 2002 3 commits
  29. 19 Jul, 2002 1 commit