reactive audit proposal

[Burn Alting]

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
> 
> 
> --Linux-audit mailing listLinux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20200514/10ab2e2b/attachment.htm>