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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Tue, 3 Jan 2017 16:13:10 -0500 Message-ID: References: <1483375990-14948-1-git-send-email-tyhicks@canonical.com> <8748cee7-efe3-a603-ef2e-dc9077b6ead4@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx08.extmail.prod.ext.phx2.redhat.com [10.5.110.32]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v03LDEpn017172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Jan 2017 16:13:14 -0500 Received: from mail-ua0-f196.google.com (mail-ua0-f196.google.com [209.85.217.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4BDC9C05678F for ; Tue, 3 Jan 2017 21:13:13 +0000 (UTC) Received: by mail-ua0-f196.google.com with SMTP id i68so34890353uad.1 for ; Tue, 03 Jan 2017 13:13:12 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Kees Cook Cc: Will Drewry , LKML , Andy Lutomirski , linux-audit@redhat.com List-Id: linux-audit@redhat.com 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