Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
* RE:  Recording user commands (from RE: Linux-audit Digest, Vol 31, Issue 12)
       [not found] <20070426160026.DFC3B73253@hormel.redhat.com>
@ 2007-04-27 20:05 ` Taylor_Tad
  2007-04-27 20:10   ` Steve Grubb
  2007-04-27 20:28   ` Paul Moore
  0 siblings, 2 replies; 4+ messages in thread
From: Taylor_Tad @ 2007-04-27 20:05 UTC (permalink / raw)
  To: linux-audit

  
  
  -----Original Message-----
While a little more verbose than one might like, couldn't you audit
exec() system calls?  That would certainly capture all the commands
issued from a shell.  However, you might want to only audit successful
exec()s.  As I recall from auditing *nix systems years ago, shells tend
to just start trying to execute a command name along your path and if it
fails, it tries again with the next path (for example, the command
doesn't exist in /usr/local/bin, let's try /usr/bin and then /usr/sbin,
etc.)  
  This would pick up other exec()s as well, but you should be able to
generate reports to find the ones that were issued by a shell.  Just a
thought.
  --Tad Taylor
  
  Message: 3
  Date: Thu, 26 Apr 2007 11:10:05 -0400
  From: Steve Grubb <sgrubb@redhat.com>
  Subject: Re: Recording user command ?
  To: linux-audit@redhat.com
  Message-ID: <200704261110.05440.sgrubb@redhat.com>
  Content-Type: text/plain;  charset="iso-8859-1"
  
  On Thursday 26 April 2007 10:32, Gavin White wrote:
  > In addition to recording system calls, file activity etc, I would
like
  > to record issued commands, ie. anything typed into a shell by a
user.
  >
  > Is this a reasonable thing to do with auditd? Is it possible?
  
  Well, there are 2 kinds of users, root and everyone else. What
everyone else 
  does cannot be logged by the session they are running in because it
does not 
  have enough privileges to log to the audit system.
  
  For the root user, it has enough privileges to log. We are working on
a 
  solution for this problem. I think most security targets are only
interested 
  in actions performed by the root user since they can affect the
machine in 
  many ways.
  
  So, as it stands today, it can't be done with the audit system. We
hope to 
  have something that starts to address the problem soon.
  
  -Steve
  
  
  
  ------------------------------
  
  --
  Linux-audit mailing list
  Linux-audit@redhat.com
  https://www.redhat.com/mailman/listinfo/linux-audit
  
  End of Linux-audit Digest, Vol 31, Issue 12
  *******************************************
  

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Recording user commands (from RE: Linux-audit Digest, Vol 31, Issue 12)
  2007-04-27 20:05 ` Recording user commands (from RE: Linux-audit Digest, Vol 31, Issue 12) Taylor_Tad
@ 2007-04-27 20:10   ` Steve Grubb
  2007-04-27 20:28   ` Paul Moore
  1 sibling, 0 replies; 4+ messages in thread
From: Steve Grubb @ 2007-04-27 20:10 UTC (permalink / raw)
  To: linux-audit; +Cc: Taylor_Tad

On Friday 27 April 2007 16:05, Taylor_Tad@emc.com wrote:
> While a little more verbose than one might like, couldn't you audit
> exec() system calls?

Yes, you could certainly do that. But as you said, it would be more data than 
you would want. If you had a policy of no root logins, you could define a 
rule something like this:

-a always,entry -S execve -F 'auid>=500'

And that should cut it down to the commands run by real users and not daemons.

>However, you might want to only audit successful exec()s.

I don't think execve returns in the normal sense when successful.

-Steve

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Recording user commands (from RE: Linux-audit Digest, Vol 31, Issue 12)
  2007-04-27 20:05 ` Recording user commands (from RE: Linux-audit Digest, Vol 31, Issue 12) Taylor_Tad
  2007-04-27 20:10   ` Steve Grubb
@ 2007-04-27 20:28   ` Paul Moore
  2007-04-27 21:38     ` Valdis.Kletnieks
  1 sibling, 1 reply; 4+ messages in thread
From: Paul Moore @ 2007-04-27 20:28 UTC (permalink / raw)
  To: linux-audit; +Cc: Taylor_Tad

On Friday, April 27 2007 4:05:28 pm Taylor_Tad@emc.com wrote:
> While a little more verbose than one might like, couldn't you audit
> exec() system calls?  That would certainly capture all the commands
> issued from a shell.

I believe that would miss all of the shell built-in commands though, wouldn't 
it?  Not sure if we would care, but you can do some interesting things with 
the built-ins ... (although maybe you could capture that through additional 
audit watches/syscalls/etc.)

-- 
paul moore
linux security @ hp

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Recording user commands (from RE: Linux-audit Digest, Vol 31, Issue 12)
  2007-04-27 20:28   ` Paul Moore
@ 2007-04-27 21:38     ` Valdis.Kletnieks
  0 siblings, 0 replies; 4+ messages in thread
From: Valdis.Kletnieks @ 2007-04-27 21:38 UTC (permalink / raw)
  To: Paul Moore; +Cc: Taylor_Tad, linux-audit


[-- Attachment #1.1: Type: text/plain, Size: 448 bytes --]

On Fri, 27 Apr 2007 16:28:17 EDT, Paul Moore said:

> I believe that would miss all of the shell built-in commands though, wouldn't
> it?  Not sure if we would care, but you can do some interesting things with 
> the built-ins ... (although maybe you could capture that through additional 
> audit watches/syscalls/etc.)

# perl -e 'while (<>) {eval $_;}'

Doing proper auditing of what a user is doing is harder than it looks.
Have a nice day. :)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-04-27 21:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20070426160026.DFC3B73253@hormel.redhat.com>
2007-04-27 20:05 ` Recording user commands (from RE: Linux-audit Digest, Vol 31, Issue 12) Taylor_Tad
2007-04-27 20:10   ` Steve Grubb
2007-04-27 20:28   ` Paul Moore
2007-04-27 21:38     ` Valdis.Kletnieks

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox