[PATCH 1/1] audit: add missing fields to AUDIT_CONFIG_CHANGE event

Richard Guy Briggs rgb at redhat.com
Mon Oct 16 15:27:06 UTC 2017


On 2017-10-13 21:11, Paul Moore wrote:
> On Fri, Oct 13, 2017 at 3:54 PM, Richard Guy Briggs <rgb at redhat.com> wrote:
> > Since these are already standalone records (since the context passed to
> > audit_log_start() is NULL) this info is necessary.
> 
> For the record, I don't have a problem with converting standalone
> records to syscall accompanied records if that makes sense (not all
> audit events can be attributed to a syscall).

I don't either.  I think I've fixed a couple like that in the past when
I thought it made sense.

> Looking purely at the additional information mentioned in this thread,
> e.g. pid/uid/session/tty, it would make me believe that these records
> *could* be accompanied by a syscall (what is the point of recording
> that information if it isn't triggered by a syscall?).  However, I
> can't say I've followed all the different fsnotify paths to know if
> that is the case ... it may be a mix, and perhaps that would be an
> argument for the logging this information in the accompanied SYSCALL
> record (it's only recorded when it is valid).

Ok, fair enough.  There are some records generated by actions that seem
indirect for watches and trees, but I suppose they are all ultimately
triggered by a user action...

The issue I still get stuck with is how do we make sure we put in rules
to catch all the CONFIG_CHANGE instances without getting flooded by all
sorts of other stuff we don't want?

> > I'm fine with the field ordering.  If that is not acceptable, I'd
> > recommend a new record type (AUDIT_TASK) to act as an aux record to this
> > record that lists this information in a standard order that can be used
> > as an aux record for all the standalone records that are missing this
> > information.
> 
> As I just said in the GH issue, I'm not a big fan of the aux record at
> the moment (it seems too much of a dup with the SYSCALL record), but
> I'm not going to rule it out.
> 
> -- 
> paul moore
> www.paul-moore.com

- 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




More information about the Linux-audit mailing list