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