Thread (21 messages) 21 messages, 3 authors, 2016-06-14

Re: [PATCH 05/14] seccomp: recheck the syscall after RET_TRACE

From: Andy Lutomirski <luto@amacapital.net>
Date: 2016-06-09 22:46:36
Also in: linux-arch, linux-arm-kernel, linux-mips, linux-s390, linux-um, lkml

On Thu, Jun 9, 2016 at 2:01 PM, Kees Cook [off-list ref] wrote:
quoted hunk ↗ jump to hunk
When RET_TRACE triggers, a tracer may change a syscall into something that
should be filtered by seccomp. This re-runs seccomp after a trace event
to make sure things continue to pass.

Signed-off-by: Kees Cook <redacted>
Cc: Andy Lutomirski <luto@kernel.org>
---
 kernel/seccomp.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 14a37d71b612..54d15eb2b701 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -556,7 +556,8 @@ void secure_computing_strict(int this_syscall)
 #else

 #ifdef CONFIG_SECCOMP_FILTER
-static int __seccomp_filter(int this_syscall, const struct seccomp_data *sd)
+static int __seccomp_filter(int this_syscall, const struct seccomp_data *sd,
+                           const bool recheck_after_trace)
This patch looks good with one minor nit: I read this as "pass true if
you want to recheck after trace", which is exactly the opposite of how
it works.

--Andy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help