linux-stable.git/security/yama, branch v3.6.4

Yama: handle 32-bit userspace prctl

2012-10-07T15:39:34+00:00

commit 2e4930eb7c8fb20a39dfb5f8a8f80402710dcea8 upstream.

When running a 64-bit kernel and receiving prctls from a 32-bit
userspace, the "-1" used as an unsigned long will end up being
misdetected. The kernel is looking for 0xffffffffffffffff instead of
0xffffffff. Since prctl lacks a distinct compat interface, Yama needs
to handle this translation itself. As such, support either value as
meaning PR_SET_PTRACER_ANY, to avoid breaking the ABI for 64-bit.

Signed-off-by: Kees Cook 
Acked-by: John Johansen 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

Yama: access task_struct->comm directly

2012-08-17T10:40:38+00:00

The core ptrace access checking routine holds a task lock, and when
reporting a failure, Yama takes a separate task lock. To avoid a
potential deadlock with two ptracers taking the opposite locks, do not
use get_task_comm() and just use ->comm directly since accuracy is not
important for the report.

Reported-by: Fengguang Wu 
Suggested-by: Oleg Nesterov 
CC: stable@vger.kernel.org
Signed-off-by: Kees Cook 
Acked-by: John Johansen 
Signed-off-by: James Morris

Yama: higher restrictions should block PTRACE_TRACEME

2012-08-10T09:58:07+00:00

The higher ptrace restriction levels should be blocking even
PTRACE_TRACEME requests. The comments in the LSM documentation are
misleading about when the checks happen (the parent does not go through
security_ptrace_access_check() on a PTRACE_TRACEME call).

Signed-off-by: Kees Cook 
Cc: stable@vger.kernel.org # 3.5.x and later
Signed-off-by: James Morris

Yama: replace capable() with ns_capable()

2012-05-15T00:27:57+00:00

When checking capabilities, the question we want to be asking is "does
current() have the capability in the child's namespace?"

Signed-off-by: Kees Cook 
Signed-off-by: James Morris

Yama: remove an unused variable

2012-04-23T07:20:22+00:00

GCC complains that we don't use "one" any more after 389da25f93 "Yama:
add additional ptrace scopes".

security/yama/yama_lsm.c:322:12: warning: ?one? defined but not used
	[-Wunused-variable]

Signed-off-by: Dan Carpenter 
Acked-by: Kees Cook 
Signed-off-by: James Morris

Yama: add additional ptrace scopes

2012-04-19T03:39:56+00:00

This expands the available Yama ptrace restrictions to include two more
modes. Mode 2 requires CAP_SYS_PTRACE for PTRACE_ATTACH, and mode 3
completely disables PTRACE_ATTACH (and locks the sysctl).

Signed-off-by: Kees Cook 
Signed-off-by: James Morris

Yama: add PR_SET_PTRACER_ANY

2012-02-15T23:25:18+00:00

For a process to entirely disable Yama ptrace restrictions, it can use
the special PR_SET_PTRACER_ANY pid to indicate that any otherwise allowed
process may ptrace it. This is stronger than calling PR_SET_PTRACER with
pid "1" because it includes processes in external pid namespaces. This is
currently needed by the Chrome renderer, since its crash handler (Breakpad)
runs external to the renderer's pid namespace.

Signed-off-by: Kees Cook 
Signed-off-by: James Morris

security: Yama LSM

2012-02-09T22:18:52+00:00

This adds the Yama Linux Security Module to collect DAC security
improvements (specifically just ptrace restrictions for now) that have
existed in various forms over the years and have been carried outside the
mainline kernel by other Linux distributions like Openwall and grsecurity.

Signed-off-by: Kees Cook 
Acked-by: John Johansen 
Signed-off-by: James Morris