summaryrefslogtreecommitdiffstats
path: root/security/yama
Commit message (Collapse)AuthorAgeFilesLines
* Yama: access task_struct->comm directlyKees Cook2012-08-171-8/+2
| | | | | | | | | | | | | | | 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 <fengguang.wu@intel.com> Suggested-by: Oleg Nesterov <oleg@redhat.com> CC: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
* Yama: higher restrictions should block PTRACE_TRACEMEKees Cook2012-08-101-0/+41
| | | | | | | | | | | 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 <keescook@chromium.org> Cc: stable@vger.kernel.org # 3.5.x and later Signed-off-by: James Morris <james.l.morris@oracle.com>
* Yama: replace capable() with ns_capable()Kees Cook2012-05-151-2/+2
| | | | | | | | 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 <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
* Yama: remove an unused variableDan Carpenter2012-04-231-1/+0
| | | | | | | | | | | | 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 <dan.carpenter@oracle.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
* Yama: add additional ptrace scopesKees Cook2012-04-191-11/+51
| | | | | | | | | 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 <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
* Yama: add PR_SET_PTRACER_ANYKees Cook2012-02-161-2/+6
| | | | | | | | | | | | 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 <keescook@chromium.org> Signed-off-by: James Morris <jmorris@namei.org>
* security: Yama LSMKees Cook2012-02-103-0/+335
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 <keescook@chromium.org> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <jmorris@namei.org>
OpenPOWER on IntegriCloud