I also endorse such a change.
and the on_mount could go a reasonable way to address this, including making use of the NETLUNK_KOBJECT_UEVENT
netlink 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 targeted
event generation.
That said, I believe that Juro Hlista did some work on this back around 2010. He did this via a plugin. His solution
was a little more generic. Should we be looking at that as a solution as well? One element I do remember from his
work, was that there was a potential gap in the time to react to a trigger firing and the result was that one was not
guaranteed 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 audit
daemon versus a plugin.What would be the effort to switch from one to the
other 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 already
attached.
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 list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit