CONFIG_CHANGE record formats

[Richard Guy Briggs]

On 2018-03-22 04:42, 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?
> 
> 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 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?

I'll backtrack on audit_dummy_context since config changes should not
depend on syscall existing rules, and I can't really think of rules that
make sense to catch them.  Stick with the audit_enabled check.

> - RGB

- 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