From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966043AbdACUxw (ORCPT ); Tue, 3 Jan 2017 15:53:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54740 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966007AbdACUxl (ORCPT ); Tue, 3 Jan 2017 15:53:41 -0500 From: Steve Grubb To: linux-audit@redhat.com Cc: Kees Cook , Paul Moore , Will Drewry , LKML , Andy Lutomirski Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Date: Tue, 03 Jan 2017 15:53:39 -0500 Message-ID: <7769390.PcQeGc7e00@x2> Organization: Red Hat User-Agent: KMail/5.3.3 (Linux/4.8.15-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: References: <1483375990-14948-1-git-send-email-tyhicks@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 03 Jan 2017 20:53:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, January 3, 2017 12:44:41 PM EST Kees Cook wrote: > >> That doesn't fully solve #3 for me. In Ubuntu (and I think Debian), we > >> build with CONFIG_AUDIT enabled but don't ship auditd by default so > >> audit_enabled is false. In that default configuration, we still want > >> seccomp audit messages to be printk'ed. I'll need to figure out how to > >> cleanly allow opting into seccomp audit messages when CONFIG_AUDIT is > >> enabled and audit_enabled is false. > > > > Heh, so you've got audit built into the kernel but you're not using > > it; that sounds "fun". > > > > Anyway, I think the logging consolidation could still help you, if for > > no other reason than everything is going through the same function at > > that point. We could do some other stuff there to handle the case > > where audit is compiled, but auditd is not running ... we already have > > some code in place to handle that for other reasons, check > > kernel/audit.c for more information. I'd still work on the other > > stuff first and then we can add this in at the end of the patchset. > > Yeah, I think the "should I report it?" threshold sysctl could just > check if audit is enabled... > > I still wonder, though, isn't there a way to use auditctl to get all > the seccomp messages you need? If you do "auditctl -e 1" then auditing will be enabled and it will send events to syslog if the audit daemon is not running. -Steve