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
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.
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
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