Messages in this thread | | | From | Steve Grubb <> | Subject | Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions | Date | Tue, 03 Jan 2017 15:53:39 -0500 |
| |
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
| |