Re: reactive audit proposal

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.

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