This is very cool!  I didn't know you could pass data from ausearch into aureport.  Does the -f option simply expect stdin if a file is not specified then?


--------------------------
Warron French


On Mon, Jun 25, 2018 at 5:28 PM, Steve Grubb <sgrubb@redhat.com> wrote:
On Monday, June 25, 2018 4:59:59 PM EDT Skaggs, Nicholas C wrote:
> Hello
> I noticed in the man page for auditctl, an example of how to monitor if
> admins are accessing other user's files. I created a rule like the one in
> the example. This is great that it is pulling the action and user calling
> the action!
>
> The rule
> -a always,exit -S all -F dir=/home/username/ -F uid=0 -C auid!=obj_uid
>
> I will pull a report on the findings with
> aureport -f -i | grep /home/username/

One other thing to comment on. You might do the report part a little
different. I'd let ausearch do the filtering before it goes to aureport. Its
much more flexible. For example, if you added a key to the rule "admin-access".
Then you can do this:

summary of all accesses
ausearch --start today -k admin-access --raw | aureport --summary -f

summary for a specific dir
ausearch --start today -k admin-access -f /home/username --raw | aureport --summary -f

summary of who did it
ausearch --start today -k admin-access --raw | aureport --summary -u -i

summary for a sepcific admin
ausearch --start today -k admin-access --loginuid admin-name --raw | aureport --summary -f

If you don't use the key in the searches, then you may be getting
unrelated events in the report.

-Steve

> The report is heavier than anticipated so I tried to make an adjustment to
> only capture what happens in the directory -a always,exit -S all -F
> path=/home/username/ -F uid=0 -C auid!=obj_uid ... but that is returning
> with  Error sending add rule data request (Invalid argument)
>
> I then tried the below rule; it does not return an error upon add, but when
> I do an auditctl -l there are no rules listed -a always,exit -S all -F
> path=/home/username/ -p=rwxa -F uid=0 -C auid!=obj_uid
>
> Is there a preferred  way to set the rule, maybe on the inode of the
> directory, but does not lose the ability to see if an admin is doing it
> and what action?  I have been adding these on the fly, instead of adding
> to the /etc/audit/audit.rules file, for now.
>
>
> Thanks!
> Nick Skaggs