reactive audit proposal

[Lenny Bruzenak]

On 5/12/20 6:22 PM, Steve Grubb wrote:

> It may also be possible to poll /sys/block to watch for changes. This might
> be easier as the names are more friendly. This would take some research to
> see if its even possible.
>
> The rule syntax could look something like:
> on=mount mount=/run/user/1000 : -a exit,always ...
> on=device device=/dev/sdd : -a exit,always ...
>
> The on-login event would simply watch the audit trail for any AUDIT_LOGIN
> events. That event can be parsed to get the new auid. If the auid matches
> any rules, then it will load them into the kernel. To remove the rules, we
> could watch for the AUDIT_USER_END event. The only issue is that we would
> need to track how many sessions the user has open and remove the rules only
> when the last session closes out.
>
> The rules for this might look something like this:
> on=login auid=1000 : -a exit,always ...
>
> The question is whether or not this should be done as part of the audit
> daemon or as a plugin for the audit daemon. One advantage of doing this as
> a plugin is that it will keep the audit daemon focused on getting events
> and distributing them. Any programming mistake in the plugin will crash it
> and not the daemon. The tradeoff is that it will get the event slightly
> after auditd sees it. This only matters for the on-login functionality. The
> device and mount events come from an entirely different source. And I'm sure
> that in every case, the program will react faster than a user possibily can
> winning the race evry time.


Although I like this generally, I also have to say that I'm generally 
apprehensive (OK scared) of dynamic rules.

I think also that while your proposal makes sense for some (likely many) 
use cases, usually not ones I deal with. Controlled spaces don't allow 
USB drives and even so, we detect this adequately now. Have plans of 
using USBGuard to augment that stance.

So in that regard, a plugin would be far better for me so I can disable 
it until it fits the model under which I operate. Just my own small, 
non-standard myopic focus. :-)

I also believe that this has more generic application, and you are 
probably using the USB device as an exemplar. There may be other 
reactive rule use cases I would be inclined to reassess.

The login/user_end event watching does pique my interest...besides 
device insertion I imagine there would be some interesting things you 
could do on the fly with that.

But again for me the strength of locking the rules into place is pretty 
big. I can only imagine what an informed pen test crew would do with 
dynamic rule manipulation.

Thanks Steve!

LCB

-- 
Lenny Bruzenak
MagitekLTD