Re: [RFC][PATCH] seccomp: add SECCOMP_RET_ACK for non-fatal SIGSYS

2016-01-31 Thread Andy Lutomirski
On Jan 28, 2016 6:33 PM, "Andy Lutomirski" wrote: > > On Thu, Jan 28, 2016 at 5:06 PM, Kees Cook wrote: > > Tracing processes for syscall usage can be done one step at a time with > > SECCOMP_RET_TRAP, but this will block the syscall. Alternatively, using > > a ptrace manager to handle SECCOMP_RE

Re: [RFC][PATCH] seccomp: add SECCOMP_RET_ACK for non-fatal SIGSYS

2016-01-28 Thread Jeffrey Vander Stoep
Thanks! This is just what I need. What are the drawbacks to returning the sigsys before executing the system call? Otherwise this loses the benefit of properly reporting registers for argument inspection. How about SECCOMP_RET_PERMISSIVE? Describes the application rather than the implementation.

Re: [RFC][PATCH] seccomp: add SECCOMP_RET_ACK for non-fatal SIGSYS

2016-01-28 Thread Andy Lutomirski
On Thu, Jan 28, 2016 at 5:06 PM, Kees Cook wrote: > Tracing processes for syscall usage can be done one step at a time with > SECCOMP_RET_TRAP, but this will block the syscall. Alternatively, using > a ptrace manager to handle SECCOMP_RET_TRACE returns can be used but is > heavy weight and depends

[RFC][PATCH] seccomp: add SECCOMP_RET_ACK for non-fatal SIGSYS

2016-01-28 Thread Kees Cook
Tracing processes for syscall usage can be done one step at a time with SECCOMP_RET_TRAP, but this will block the syscall. Alternatively, using a ptrace manager to handle SECCOMP_RET_TRACE returns can be used but is heavy weight and depends on the ptrace infrastructure. A light-weight method to lea