public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: "Jender, Raymond [USA]" <jender_raymond@bah.com>
Subject: Re: audit.rules
Date: Wed, 8 Feb 2012 13:40:33 -0500	[thread overview]
Message-ID: <201202081340.33499.sgrubb@redhat.com> (raw)
In-Reply-To: <CALnj_=6eBkm1Z_1bVTQhUsJBiaux4Uq3hG-8saVx0oJ9dYQNDg@mail.gmail.com>

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

      reply	other threads:[~2012-02-08 18:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08 14:30 audit.rules Jender, Raymond [USA]
2012-02-08 14:59 ` audit.rules Steve Grubb
2012-02-08 16:53 ` audit.rules Peter Moody
2012-02-08 18:40   ` Steve Grubb [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201202081340.33499.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=jender_raymond@bah.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox