From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935979AbdACVEP (ORCPT ); Tue, 3 Jan 2017 16:04:15 -0500 Received: from mail-it0-f41.google.com ([209.85.214.41]:34898 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935962AbdACVEB (ORCPT ); Tue, 3 Jan 2017 16:04:01 -0500 MIME-Version: 1.0 In-Reply-To: References: <1483375990-14948-1-git-send-email-tyhicks@canonical.com> <8748cee7-efe3-a603-ef2e-dc9077b6ead4@canonical.com> From: Kees Cook Date: Tue, 3 Jan 2017 13:03:59 -0800 X-Google-Sender-Auth: zQlEIH2-8Wvy9LUidKQ3rvTReFU Message-ID: Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions To: Paul Moore 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 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). 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Tue, 3 Jan 2017 13:03:59 -0800 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-mx04.extmail.prod.ext.phx2.redhat.com [10.5.110.28]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v03L43PK012683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Jan 2017 16:04:03 -0500 Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (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 D86747F7B1 for ; Tue, 3 Jan 2017 21:04:01 +0000 (UTC) Received: by mail-it0-f47.google.com with SMTP id x2so307219806itf.1 for ; Tue, 03 Jan 2017 13:04:00 -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: Paul Moore Cc: Will Drewry , LKML , Andy Lutomirski , linux-audit@redhat.com List-Id: linux-audit@redhat.com 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). 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