On Wed, Feb 22, 2012 at 3:38 PM, Andrew Lutomirski [off-list ref] wrote:

On Wed, Feb 22, 2012 at 11:48 AM, Will Drewry [off-list ref] wrote:

quoted

On Wed, Feb 22, 2012 at 2:34 AM, Indan Zupancic [off-list ref] wrote:

quoted

On Tue, February 21, 2012 18:30, Will Drewry wrote:

quoted

This change enables SIGSYS, defines _sigfields._sigsys, and adds
x86 (compat) arch support.  _sigsys defines fields which allow
a signal handler to receive the triggering system call number,
the relevant AUDIT_ARCH_* value for that number, and the address
of the callsite.

To ensure that SIGSYS delivery occurs on return from the triggering
system call, SIGSYS is added to the SYNCHRONOUS_MASK macro.  I'm
this is enough to ensure it will be synchronous or if it is explicitly
required to ensure an immediate delivery of the signal upon return from
the blocked system call.

The first consumer of SIGSYS would be seccomp filter.  In particular,
a filter program could specify a new return value, SECCOMP_RET_TRAP,
which would result in the system call being denied and the calling
thread signaled.  This also means that implementing arch-specific
support can be dependent upon HAVE_ARCH_SECCOMP_FILTER.

I think others said this is useful, but I don't see how. Easier
debugging compared to checking return values?

I suppose SIGSYS can be blocked, so there is no guarantee the process
will be killed.

Yeah, this allows for in-process system call emulation, if desired, or
for the process to dump core/etc.  With RET_ERRNO or RET_KILL, there
isn't any feedback to the system about the state of the process.  Kill
populates audit_seccomp and dmesg, but if the application
user/developer isn't the system admin, installing audit bits or
checking system logs seems onerous.

[Warning: this suggestion may be bad for any number of reasons]

I wonder if it would be helpful to change the semantics of RET_KILL
slightly.  Rather than killing via do_exit, what if it killed via a
forcibly-fatal SIGSYS?  That way, the parent's waitid() / SIGCHLD
would indicate CLD_KILLED with si_status == SIGSYS.  The parent could
check that and report that the child was probably compromised.

--Andy

I'd prefer sticking with do_exit. This provides much less chance of
things going wrong. A parent seeing a child killed with SIGKILL is
already pretty distinct, IMO.

-Kees

-- 
Kees Cook
ChromeOS Security