CONFIG_CHANGE record formats

[Steve Grubb]

On Thursday, March 22, 2018 4:42:46 AM EDT Richard Guy Briggs wrote:
> Hi Steve, Paul,
> 
> Looking at some AUDIT_CONFIG_CHANGE record formats, a couple of things
> stand out as potential problems:
> 
> For ADD_RULE and DEL_RULE case when audit_enabled is in the AUDIT_LOCKED
> state, it just outputs "audit_enabled=2 res=0" to indicate locked and
> failure, but doesn't appear to actually give the normal "op=<mumble>" to
> indicate a rule change was attempted and refused due to immutability of
> the rule set.  Will this be a problem for the parser, and should an
> attempted rule change be logged as such?

If its the only rule change event that does not have an op= field, then make 
it have one.


> The other is AUDIT_TTY_SET that has non-standard old-* and new-* fields,
> but since there are two, I think it is unavoidable and can't be fixed.

We actually have to have old and new values for any configuration change that 
is not a rule add/delete. For example, if we enable audit, we need the old 
and new values. This can be expressed either as old- new-  or old- and the 
item without a new prefix.
 
> Another is that other than a change to the enabled status and maybe
> auditd PID changes, every other config change should not be logged if
> audit is disabled.

True.

> Furthermore, if CONFIG_CHANGE records are to be accompanied by syscall
> records, they should obey audit_dummy_context() to avoid unaccompanied
> records.  Does this reasoning make sense?

CONFIG_CHANGE records are simple events and not compound events. They should 
contain all the pertinent information in their one record.

-Steve