Discussion:
auditctl for admin's accessing other user files
Skaggs, Nicholas C
2018-06-25 20:59:59 UTC
Permalink
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/

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
Steve Grubb
2018-06-25 21:16:46 UTC
Permalink
Post by Skaggs, Nicholas C
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
You might also want to add -F auid>=1000 -F auid!=4294967295
So that you get events caused by people and not system daemons. This might be
all that you need to do.
Post by Skaggs, Nicholas C
I will pull a report on the findings with
aureport -f -i | grep /home/username/
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)
You should use the "dir" option rather than "path". A full example would be:
-a always,exit -F dir=/home -F uid=0 -F auid>=1000 -F auid!=4294967295
-C auid!=obj_uid

-Steve
Post by Skaggs, Nicholas C
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
Skaggs, Nicholas C
2018-06-26 13:22:45 UTC
Permalink
Thank you very much, Steve! Very helpful info!

I also added some of the variations of the reporting you suggested using ausearch. Good stuff.

N.
Post by Skaggs, Nicholas C
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
You might also want to add -F auid>=1000 -F auid!=4294967295
So that you get events caused by people and not system daemons. This might be all that you need to do.
Post by Skaggs, Nicholas C
I will pull a report on the findings with aureport -f -i | grep
/home/username/
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)
You should use the "dir" option rather than "path". A full example would be:
-a always,exit -F dir=/home -F uid=0 -F auid>=1000 -F auid!=4294967295 -C auid!=obj_uid

-Steve
Post by Skaggs, Nicholas C
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
Steve Grubb
2018-06-25 21:28:39 UTC
Permalink
Post by Skaggs, Nicholas C
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
Post by Skaggs, Nicholas C
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
warron.french
2018-06-30 02:44:48 UTC
Permalink
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
Post by Steve Grubb
Post by Skaggs, Nicholas C
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".
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
Post by Skaggs, Nicholas C
The report is heavier than anticipated so I tried to make an adjustment
to
Post by Skaggs, Nicholas C
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
Post by Skaggs, Nicholas C
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
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit
Steve Grubb
2018-06-30 13:33:53 UTC
Permalink
Post by warron.french
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?
ausearch and aureport both check stdin to see if its a pipe. If so, it reads
it instead of the logs. This leads to the common problem of getting no output
when run from a cron job. This is because the cron job creates a pipe for
stdin even when it doesn't pipe anything to it. So, that lead to the creation
of the --input-logs commandline option to force it to read the logs even when
stdin is a pipe.

So, if you wanted to do one of those reports mentioned below from a cron job,
then the ausearch would need to use that option but aureport wouldn't so that
it can process the output of ausearch. Also note that when piping them, they
expect data in the raw format.

-Steve
Post by warron.french
Post by Steve Grubb
Post by Skaggs, Nicholas C
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".
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
Post by Skaggs, Nicholas C
The report is heavier than anticipated so I tried to make an adjustment
to
Post by Skaggs, Nicholas C
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
Post by Skaggs, Nicholas C
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
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit
Loading...