Dmitry V. Levin
ldv at altlinux.org
Mon Feb 15 16:31:43 UTC 2016
On Mon, Feb 15, 2016 at 10:11:41AM -0500, Mike Frysinger wrote:
> On 15 Feb 2016 17:50, Dmitry V. Levin wrote:
> > On Mon, Feb 15, 2016 at 09:30:18AM -0500, Mike Frysinger wrote:
> > > On 15 Feb 2016 15:21, Dmitry V. Levin wrote:
> > > > On entering syscall, seccomp kernel hooks are executed before ptrace
> > > > kernel hooks. As result, when some syscall is blocked by seccomp filter
> > > > using SECCOMP_RET_ERRNO statement, on many architectures including x86 and
> > > > x86_64 the syscall number is clobbered and strace sees -1 in its place.
> > > >
> > > > You can play with strace/tests/seccomp.c and see it yourself.
> > >
> > > would PTRACE_O_TRACESECCOMP help here ?
> > Only for SECCOMP_RET_TRACE actions.
> oh i misread ... i was thinking it was for all ret operations.
> can we get the seccomp core to save its original state in a way
> we can get at later, perhaps via a new PTRACE_GETSECCOMPDATA ?
> that'd tell us which SECCOMP_RET_xxx was used and the value that
> was in there before. we would need a new PTRACE_EVENT_xxx so we
> don't have to run it all the time.
Yes, I think something of this kind could be implemented for
SECCOMP_PHASE1_SKIP actions (i.e. SECCOMP_RET_ERRNO and SECCOMP_RET_TRAP).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Strace-devel