CONFIG_CHANGE record formats

[Richard Guy Briggs]

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?

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.

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.  Furthermore, if CONFFIG_CHANGE records are to be
accompanied by syscall records, they should obey audit_dummy_context()
to avoid unaccompanied records.  Does this reasoning make sense?


- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635