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