Re: seccomp and audit_enabled
No, it's the default audit.rules (-D, -b320). No actual rules
loaded.
Let me add some instrumentation and figure out what's going on. auditd
is masked (via systemd) but systemd-journal seems to set audit_enabled=1
during startup (at least on our systems).
Tony,
We have bz 1227379
https://bugzilla.redhat.com/show_bug.cgi?id=1227379
There is a patch attached to disable systemd's propensity to turn on the audit
system. Are people complaining and opening bugs in your distribution? If so,
that might add more ammunition to get that fixed.
On Tuesday, October 13, 2015 03:19:20 PM Paul Moore wrote:
> I'm of the opinion that nothing should get output (through
the audit
> system) if audit_enabled == 0. What you advocate calls for more than 2
> possible states for audit_enabled or logging the information through
> another mechanism than audit.
I don't really care if it is audit or not (although we will need to
output something via audit if it is enabled to keep the CC crowd
happy);
The rules for CC are that any access decision must be auditable and selective.
That means that we need to be able to choose if we want to audit success,
and/or failure, and/or nothing.
The inability to turn off SE Linux AVCs in the audit logs is why the exclude
filter was created. Seccomp could be the same way.
-Steve
if you feel strongly that it isn't audit, we can just make it
a printk, that would work well with Kees' goals. To me the important
point here is that we send a message when seccomp alters the behavior
of the syscall (action != ALLOW).