Re: seccomp and audit_enabled

[Steve Grubb <sgrubb@redhat.com>]

> 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).