reactive audit proposal

[Steve Grubb]

Hello,

Answering both emails at once.

On Thursday, May 14, 2020 9:32:21 AM EDT Richard Guy Briggs wrote:
> 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.

libudev has a function that looks up device from a path. I was planning to use that.

> > 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?

I really don't know that code. It was done as a summer research project for
a thesis. I do not know if it is production ready, supportable, or
sustainable. While it may be more general, I remember the code base being
large. Large means complicated. I'd rather narrow the scope and have a small
amount of code that serves a single purpose.

> > 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 make them memory resident so that searching them is fast.
Watching for mount changes will probably be faster that the general system
because it does not depend on a mount syscall rule to trickle down and then
react. 

In the user case, we would watch for the login event. It should be
able to react before the whole pam cycle finishes. Although we would want to
monitor the progress of pam so that we don't place a rule when the session
never starts due to pam_time voting no. And we'll have to handle a login and
cron jobs differently.
 
> 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.

OK, lets give that a try

# auditctl -a always,exit -F dir=/run/media/sgrubb/sandisk/ -F perm=rx -F key=usb-drive
Error sending add rule data request (No such file or directory)

We can't. Also, every single rule we add slows down the system.

-Steve

> 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