public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Subject: Re: auditing activity where uid==0
Date: Fri, 4 Dec 2009 09:35:23 -0500	[thread overview]
Message-ID: <200912040935.23815.sgrubb@redhat.com> (raw)
In-Reply-To: <4B18EDBA.5070603@gmail.com>

On Friday 04 December 2009 06:08:42 am Trevor Vaughan wrote:
> >> I'm getting lots of extraneous chatter from sshd, automount, and cron,
> >> all of which are from tty=(none), but I'm not sure it's possible to
> >> filter on tty...
> 
> It's not as far as I could find, though this would be an awesome
> feature.  Basically, the ability to say, tty!=none.

This can be easily subverted by an attacker. Open af_unix socket, pass 
descriptor, do not read it, close stdin - stdout and do evil work, then read 
socket and use tty input/output again.

> > The way that we suggest auditing the actions of a root user is by using
> > the tty audit capability. This is a little more specific about what is
> > really happening. For example, someone could start a python shell and
> > start issuing commands. If you audit by execve, then all you see is
> > python start up and then you see nothing else. Also, bash can do
> > networking. Its possible to transfer files using bash primitives that you
> > won't pick up by auditing execve syscalls. Awk is also network aware...
> 
> One thing to note about the tty audit capability is that it is a forward
> processing logger, not an echo logger.

I prefer to call it a keystroke logger because it gets all of them.

> This means that it will capture passwords that you type in at the command
> line even if they are not echoed.

True and they are protected by needing root level access to get at them. 
Anyone that has root access can install a rootkit to grab passwords just as 
easily. If the concern is that these could be stored and looked at by anyone 
with access to the backed up logs, then use gpg to encrypt the files.

> You may want to look at something like sudosh or the like which are echo
> loggers and will not collect anything that is hidden from the terminal.

Those are easily subverted, though.

>  This presents it's own problems, but at least won't grab sensitive
> passwords in general.

All protection profiles state that root is trusted. There are at least 20 
covert channels I can think of that would let an evil admin get a user's 
private keys/data or credentials.

-Steve

      reply	other threads:[~2009-12-04 14:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-19 15:02 auditing activity where uid==0 Rich Whitcroft
2009-10-19 15:14 ` Steve Grubb
2009-12-04 11:08   ` Trevor Vaughan
2009-12-04 14:35     ` 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=200912040935.23815.sgrubb@redhat.com \
    --to=sgrubb@redhat.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