From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761383AbdACVNv (ORCPT ); Tue, 3 Jan 2017 16:13:51 -0500 Received: from mail-ua0-f194.google.com ([209.85.217.194]:34432 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751257AbdACVNl (ORCPT ); Tue, 3 Jan 2017 16:13:41 -0500 MIME-Version: 1.0 X-Originating-IP: [96.230.190.88] In-Reply-To: References: <1483375990-14948-1-git-send-email-tyhicks@canonical.com> <8748cee7-efe3-a603-ef2e-dc9077b6ead4@canonical.com> From: Paul Moore Date: Tue, 3 Jan 2017 16:13:10 -0500 Message-ID: Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions To: Kees Cook Cc: Tyler Hicks , Eric Paris , Andy Lutomirski , Will Drewry , linux-audit@redhat.com, LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 3, 2017 at 4:03 PM, Kees Cook wrote: > On Tue, Jan 3, 2017 at 12:54 PM, Paul Moore wrote: >> On Tue, Jan 3, 2017 at 3:44 PM, Kees Cook wrote: >>> I still wonder, though, isn't there a way to use auditctl to get all >>> the seccomp messages you need? >> >> Not all of the seccomp actions are currently logged, that's one of the >> problems (and the biggest at the moment). > > Well... sort of. It all gets passed around, but the logic isn't very > obvious (or at least I always have to go look it up). Last time I checked SECCOMP_RET_ALLOW wasn't logged (as well as at least one other action, but I can't remember which off the top of my head)? > include/linux/audit.h: > > #ifdef CONFIG_AUDITSYSCALL > ... > static inline void audit_seccomp(unsigned long syscall, long signr, int code) > { > if (!audit_enabled) > return; > > /* Force a record to be reported if a signal was delivered. */ > if (signr || unlikely(!audit_dummy_context())) > __audit_seccomp(syscall, signr, code); > } > ... > #else /* CONFIG_AUDITSYSCALL */ > > static inline void audit_seccomp(unsigned long syscall, long signr, int code) > { } > ... > #endif > > kernel/seccomp.c: > > switch (action) { > case SECCOMP_RET_ERRNO: > /* Set low-order bits as an errno, capped at MAX_ERRNO. */ > if (data > MAX_ERRNO) > data = MAX_ERRNO; > syscall_set_return_value(current, task_pt_regs(current), > -data, 0); > goto skip; > ... > case SECCOMP_RET_KILL: > default: > audit_seccomp(this_syscall, SIGSYS, action); > do_exit(SIGSYS); > } > > unreachable(); > > skip: > audit_seccomp(this_syscall, 0, action); > > > Current state: > > - if CONFIG_AUDITSYSCALL=n, then nothing is ever reported. > > - if audit is disabled, nothing is ever reported. > > - if a process isn't being specifically audited > (!audit_dummy_context()), only signals (RET_KILL) are reported. > > - when being specifically audited, everything is reported. > > > So, shouldn't it be possible to specifically audit a process and > examine the resulting logs for the RET_* level one is interested in > ("code=0x%x" in __audit_seccomp())? > > -Kees > > -- > Kees Cook > Nexus Security -- paul moore www.paul-moore.com