From: Steve Grubb <sgrubb@redhat.com>
To: casey@schaufler-ca.com
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
Miloslav Trmac <mitr@redhat.com>,
dwmw2@infradead.org, linux-kernel@vger.kernel.org,
Alan Cox <alan@redhat.com>, Alexander Viro <aviro@redhat.com>
Subject: Re: [PATCH] Audit: Add TTY input auditing
Date: Thu, 7 Jun 2007 12:31:43 -0400 [thread overview]
Message-ID: <200706071231.43843.sgrubb@redhat.com> (raw)
In-Reply-To: <817517.5859.qm@web36605.mail.mud.yahoo.com>
On Thursday 07 June 2007 11:42, Casey Schaufler wrote:
> > tools like rootsh, but that is too easy to detect and defeat. And then it
> > does not put its data into the audit system where its correlated with
> > other system events.
>
> The evaluation teams that I have worked with (OrangeBook and CC)
> as well as their technical advisory groups have always been clear
> that keyboard logging is not an appropriate mechanism for security
> audit logging. There is insufficient correlation between what is
> typed and security relevent actions for keyboard (or mouse event)
> logging to meet the audit requirements.
Ok, this is a sample set of requirements we are trying to meet:
Implement automated audit trails for all system components to reconstruct the
following events:
All actions taken by any individual with root or administrative privileges
If we do not get commands typed at a prompt, we have to audit by execve.
Auditing execve for uid = 0 produces millions of events since that includes
daemons. If we get clever and restrict auditing to events for root uid and
auid >= 500, we still wind up with millions of events because of shell
scripts.
People in control of some of these security targets said to me that auditing
by execve cannot be the solution, because the audit trail becomes too big,
unwieldy, full of irrelavent events, and not easily analysed. So, that
approach does not work for people either.
Casey, so what approach would you take to meet the requirement?
> You have to log what happened.
Which can be done by auditing for execution of specific apps or watching
access to certain files. So, I don't see tty auditing as something that
replaces other auditing, it allows us to form a better picture of what
happened to the system.
> Logging what was requested is insufficient and logging what was
> typed, which may or may not have resulted in an actual request is
> not helpful to meeting security audit requirements.
I would disagree. Its helpful to complete the picture of what's happening on
the system.
-Steve
next prev parent reply other threads:[~2007-06-07 16:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-06 9:49 [PATCH] Audit: Add TTY input auditing Miloslav Trmac
2007-06-06 10:10 ` Miloslav Trmac
2007-06-07 0:41 ` Andrew Morton
2007-06-07 10:10 ` Alan Cox
2007-06-07 14:20 ` Miloslav Trmac
2007-06-07 21:59 ` Alan Cox
2007-06-08 4:18 ` Miloslav Trmac
2007-06-08 4:23 ` [PATCH, v2] " Miloslav Trmac
2007-06-08 6:31 ` Andrew Morton
2007-06-08 16:00 ` Miloslav Trmac
2007-06-07 8:13 ` [PATCH] " Jan Engelhardt
2007-06-07 10:50 ` Steve Grubb
2007-06-07 15:42 ` Casey Schaufler
2007-06-07 15:52 ` Alan Cox
2007-06-07 16:31 ` Steve Grubb [this message]
2007-06-07 17:33 ` Casey Schaufler
2007-06-07 19:28 ` Miloslav Trmac
2007-06-07 21:09 ` Jan Engelhardt
2007-06-07 22:32 ` Casey Schaufler
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=200706071231.43843.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=alan@redhat.com \
--cc=aviro@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=dwmw2@infradead.org \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mitr@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