Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753865Ab2BWAIi (ORCPT ); Wed, 22 Feb 2012 19:08:38 -0500 Received: from mail-tul01m020-f174.google.com ([209.85.214.174]:60371 "EHLO mail-tul01m020-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753804Ab2BWAIg convert rfc822-to-8bit (ORCPT ); Wed, 22 Feb 2012 19:08:36 -0500 Authentication-Results: mr.google.com; spf=pass (google.com: domain of keescook@google.com designates 10.60.12.103 as permitted sender) smtp.mail=keescook@google.com; dkim=pass header.i=keescook@google.com MIME-Version: 1.0 In-Reply-To: References: <1329845435-2313-1-git-send-email-wad@chromium.org> <1329845435-2313-7-git-send-email-wad@chromium.org> <9edbabb2262e3d91a7b8c75dbec03d7f.squirrel@webmail.greenhost.nl> Date: Wed, 22 Feb 2012 16:08:33 -0800 X-Google-Sender-Auth: 5_whf5MxLwGUfVms8AcI5lUMrWQ Message-ID: Subject: Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous. From: Kees Cook To: Will Drewry Cc: Andrew Lutomirski , Indan Zupancic , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com, netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de, davem@davemloft.net, hpa@zytor.com, mingo@redhat.com, oleg@redhat.com, peterz@infradead.org, rdunlap@xenotime.net, mcgrathr@chromium.org, tglx@linutronix.de, eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org, scarybeasts@gmail.com, pmoore@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3472 Lines: 70 On Wed, Feb 22, 2012 at 4:05 PM, Will Drewry wrote: > On Wed, Feb 22, 2012 at 5:53 PM, Kees Cook wrote: >> On Wed, Feb 22, 2012 at 3:38 PM, Andrew Lutomirski wrote: >>> On Wed, Feb 22, 2012 at 11:48 AM, Will Drewry wrote: >>>> On Wed, Feb 22, 2012 at 2:34 AM, Indan Zupancic 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/