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
prev parent 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