On Wed, Feb 22, 2012 at 4:05 PM, Will Drewry <wad@xxxxxxxxxxxx> wrote: > On Wed, Feb 22, 2012 at 5:53 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Wed, Feb 22, 2012 at 3:38 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: >>> On Wed, Feb 22, 2012 at 11:48 AM, Will Drewry <wad@xxxxxxxxxxxx> wrote: >>>> On Wed, Feb 22, 2012 at 2:34 AM, Indan Zupancic <indan@xxxxxx> wrote: >>>>> On Tue, February 21, 2012 18:30, Will Drewry wrote: >>>>>> 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. > > Hrm, it might be possible to do_exit(SIGSYS) which would be both. It > looks like tsk->exit_code would be SIGSYS then, but I'll look a little > more closely to see what that'll actually do. As long as there's no way it can get blocked, I'd be fine with that. It would, actually, be better than SIGKILL because, as Andy said, it's more distinguishable from other situations. I've long wanted a signal to be used for "violated policy" that wasn't just a straight SIGKILL. -Kees -- Kees Cook ChromeOS Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
