audit.rules

[Steve Grubb]

On Wednesday, February 08, 2012 11:53:44 AM Peter Moody wrote:
> I think there are a few ways you can do this with auditd:
> 
> (These both assume you've setup pam_loginuid)
> 
> If your admins are a finite set of uids, you could do something like
> 
> auditctl -a exit,always -F auid=<admin1> -F success=1
> auditctl -a exit,always -F auid=<admin2> -F success=1
> ...
> auditctl -a exit,always -F auid=<adminN> -F success=1

This audits all syscalls of all programs run by the admin. Normally, this is not 
what people want or desire. Normally when its asked about how you log 
administrative actions, the intended effect is something like the bash history 
file. They want to know just what the admin did. Unfortunately, this can be 
easily tricked. The admin can open wish or a python shell and just start typing 
commands. This does not get recorded in a bash history. So, what you have to do 
is record the keystrokes.

A lot of times these security requirements come from places where they run both 
windows and linux. So, it sounds innocent. But think about windows. There are 
only so many apps and its not like the OS depends on shell scripting. So, what 
sounds like an easy to do requirement in windows becomes impossible in linux. 
You have so many execve's with normal shell scripts that you get way more data 
than you want if you audit on execve.

So, the basic answer is that to weed this down to just the good stuff, you need 
to do the keystroke logging or if everything is defined in sudo commands, then 
sudo will take care of this for you.


> or if by administrators you mean actions run as root (eg, with sudo or
> su), you can do something like
> 
> auditctl -a exit,always -F auid=!0 -F euid=0 -F success=1

Again a mountain of data is not good for people. I think there is a clarification 
to NISPOM that says too much data is just as bad as not enough data. Making 
searching hard to find what you are after is tatamount to not recording it 
becuase you can't find it later.

-Steve