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(a)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