summaryrefslogtreecommitdiff
path: root/security/smack/smack_access.c
diff options
context:
space:
mode:
authorJann Horn <jannh@google.com>2019-07-04 20:44:44 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-10-07 21:01:06 +0200
commitcfaf71c99319a0ebec6f736ac5b400099257ae1b (patch)
tree7bdc3030f89d6b864e6947781cca5f149d93c9cf /security/smack/smack_access.c
parent3aa452bf9baa11cf99a8913eaf0ed98a06cf6493 (diff)
Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set
commit 3675f052b43ba51b99b85b073c7070e083f3e6fb upstream. There is a logic bug in the current smack_bprm_set_creds(): If LSM_UNSAFE_PTRACE is set, but the ptrace state is deemed to be acceptable (e.g. because the ptracer detached in the meantime), the other ->unsafe flags aren't checked. As far as I can tell, this means that something like the following could work (but I haven't tested it): - task A: create task B with fork() - task B: set NO_NEW_PRIVS - task B: install a seccomp filter that makes open() return 0 under some conditions - task B: replace fd 0 with a malicious library - task A: attach to task B with PTRACE_ATTACH - task B: execve() a file with an SMACK64EXEC extended attribute - task A: while task B is still in the middle of execve(), exit (which destroys the ptrace relationship) Make sure that if any flags other than LSM_UNSAFE_PTRACE are set in bprm->unsafe, we reject the execve(). Cc: stable@vger.kernel.org Fixes: 5663884caab1 ("Smack: unify all ptrace accesses in the smack") Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'security/smack/smack_access.c')
0 files changed, 0 insertions, 0 deletions