]> git.neil.brown.name Git - history.git/commit
[PATCH] credentials locking fix
authorAndrew Morton <akpm@osdl.org>
Mon, 26 Apr 2004 15:55:51 +0000 (08:55 -0700)
committerLinus Torvalds <torvalds@ppc970.osdl.org>
Mon, 26 Apr 2004 15:55:51 +0000 (08:55 -0700)
commit10c189cdc6b127955068fcfb812d021b5ed32be6
treefa62ae052c2ccd3861534987bd23b18944431db2
parentf6cfe4f8ce4b5bc13a0ade4daf267fdf5b0e61c9
[PATCH] credentials locking fix

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
fs/exec.c
include/linux/security.h
security/commoncap.c
security/dummy.c
security/selinux/hooks.c