reactive audit proposal

[Richard Guy Briggs]

On 2020-05-14 18:55, Burn Alting wrote:
> I also endorse such a change. 
> There is a significant gap in recoding removable media activity (see 
> https://bugzilla.redhat.com/show_bug.cgi?id=967241) and the on_mount could go a
> reasonable  way to address this, including making use of the
> NETLUNK_KOBJECT_UEVENTnetlink group or  /sys/block polling to assist with device
> discovery.
> Secondly, being able to react to a login/logout event also opens up interesting
> opportunity for targetedevent generation.
> That said, I believe that Juro Hlista did some work on this back around 2010. He did
> this via a plugin. His solutionwas a little more generic. Should we be looking at
> that as a solution as well? One element I do remember from hiswork, was that there
> was a potential gap in the time to react to a trigger firing and the result was that
> one was notguaranteed to implement the new rules immediately. I assume to treat this
> gap, the rules could be preloaded and the 'trigger' action could just move the
> 'dormant' rules, already in core, to the 'active' list.

I was going to say, this one feels like there are a set of rules that
should just be present from the get-go and not dynamic.  If we already
know what we are looking for (monitor a specific user, or monitor a
specific device) then just add those rules to the permenent set.

This makes it easier to lock things down too.

> Burn
> On Wed, 2020-05-13 at 14:03 -0400, Steve Grubb wrote:
> > On Wednesday, May 13, 2020 1:17:02 PM EDT Joe Wulf wrote:
> > > What you propose is a sound enhancement.I have no preference for the choice
> > > between incorporate this in the auditdaemon versus a plugin.What would be the
> > > effort to switch from one to theother if later on you should find the first
> > > choice wasn't as optimal?
> > 
> > Well, the main idea for a plugin is not to stop processing events. Busy systems
> > need to keep focused on unloading the kernel backlog. 
> > > I wonder about the case where a system is booted with new media alreadyattached.
> > 
> > During initialization, it runs through the mount table just as if the mount table
> > was changed. So, it has the opportunity to apply rules during init. I'm borrowing
> > code from fapolicyd which has this nicely solved. (It's one of my other projects.)
> > -Steve

- 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