Re: CONFIG_CHANGE record formats
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