Current capabilities

Current capabilities

[Michael W Folsom]

I've been lurking on this list for a while now and am a bit confused at
the current state of audit's capabilities.  I've looked at: 
	http://people.redhat.com/sgrubb/audit/
and still aren't sure if it is capable of doing what I need.  To get to
the point the events I need to record in an audit log are -

1) If someone tries to access an object (file, directory, program) that
they don't have rights to the event needs to be recorded

2) if someone logs into a system and su's to another user or series of
users their actions need to be traceable to the original login user's
id 

Can this be done with the current audit system in RHEL4 or will this not
be supported until RHEL5 is released?  Are there any other Linux
distro's that can do this?  If either of these are true where would I
look for information how to get this to work.


Thanks!

Re: Current capabilities

[Linda Knippers]

Michael W Folsom wrote:
> I've been lurking on this list for a while now and am a bit confused at
> the current state of audit's capabilities.  I've looked at: 
> 	http://people.redhat.com/sgrubb/audit/
> and still aren't sure if it is capable of doing what I need.  To get to
> the point the events I need to record in an audit log are -

If you're interested in RHEL4 then I suggest you look at the updates.
HP and IBM have both completed CAPP evaluations of RHEL4 and
when properly configured the system and audit framework supports what you want.

For details, check out HP's documentation at:
http://h71028.www7.hp.com/enterprise/downloads/RHEL-CAPP-EAL3-HP-Configuration-Guide.pdf
or IBM's at:
ftp://www6.software.ibm.com/software/developer/library/os-ltc-security/RHEL-CAPP-EAL4-IBM-Configuration-Guide-v1.14.pdf

> 1) If someone tries to access an object (file, directory, program) that
> they don't have rights to the event needs to be recorded

You can configure the audit system to audit specific system calls that fail.
> 
> 2) if someone logs into a system and su's to another user or series of
> users their actions need to be traceable to the original login user's
> id 

The audit system keeps track of the login uid as well as the current uid,
so I believe it does what you want.
> 
> Can this be done with the current audit system in RHEL4 or will this not
> be supported until RHEL5 is released?  Are there any other Linux
> distro's that can do this?  

SLES8 as of SP3 can do the same thing, only with a different audit
framework.

> If either of these are true where would I
> look for information how to get this to work.

-- ljk
> 
> 
> Thanks!
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Current capabilities

[Steve Grubb]

On Wednesday 13 December 2006 18:16, Michael W Folsom wrote:
> 1) If someone tries to access an object (file, directory, program) that
> they don't have rights to the event needs to be recorded

-a always,exit -S open,opendir,execve -F exit=-13

This does it for 3 common syscalls. You can do it for any syscall you want. 
You can use strace to figure out the syscalls you want.

> 2) if someone logs into a system and su's to another user or series of
> users their actions need to be traceable to the original login user's
> id

It does this. There is a process attribute, loginuid, that keeps track of 
this. The audit events have it as the auid field. We've already preconfigured 
RHEL4/5 and FC4->rawhide to handle this.

-Steve

RE: Current capabilities

[Boyce, Kevin P. (Melbourne, FL)]

If you need a record of failed login attempts, try using the syslog
daemon.  Look at /etc/syslog.conf and configure events and a place to
log the logs, then touch the <log_filename.log> and restart syslog. 


Kevin Boyce
kevin.boyce@ngc.com

-----Original Message-----
From: linux-audit-bounces@redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Linda Knippers
Sent: Wednesday, December 13, 2006 6:40 PM
To: Michael W Folsom
Cc: Linux Audit List
Subject: Re: Current capabilities

Michael W Folsom wrote:
> I've been lurking on this list for a while now and am a bit confused 
> at the current state of audit's capabilities.  I've looked at:
> 	http://people.redhat.com/sgrubb/audit/
> and still aren't sure if it is capable of doing what I need.  To get 
> to the point the events I need to record in an audit log are -

If you're interested in RHEL4 then I suggest you look at the updates.
HP and IBM have both completed CAPP evaluations of RHEL4 and when
properly configured the system and audit framework supports what you
want.

For details, check out HP's documentation at:
http://h71028.www7.hp.com/enterprise/downloads/RHEL-CAPP-EAL3-HP-Configu
ration-Guide.pdf
or IBM's at:
ftp://www6.software.ibm.com/software/developer/library/os-ltc-security/R
HEL-CAPP-EAL4-IBM-Configuration-Guide-v1.14.pdf

> 1) If someone tries to access an object (file, directory, program) 
> that they don't have rights to the event needs to be recorded

You can configure the audit system to audit specific system calls that
fail.
> 
> 2) if someone logs into a system and su's to another user or series of

> users their actions need to be traceable to the original login user's 
> id

The audit system keeps track of the login uid as well as the current
uid, so I believe it does what you want.
> 
> Can this be done with the current audit system in RHEL4 or will this 
> not be supported until RHEL5 is released?  Are there any other Linux 
> distro's that can do this?

SLES8 as of SP3 can do the same thing, only with a different audit
framework.

> If either of these are true where would I look for information how to 
> get this to work.

-- ljk
> 
> 
> Thanks!
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Current capabilities

[Steve Grubb]

On Thursday 14 December 2006 07:43, Boyce, Kevin P. (Melbourne, FL) wrote:
> If you need a record of failed login attempts, try using the syslog
> daemon.

Syslog is generally not good enough for people that *really* need to track 
this information. Syslog can be lossy due to udp. And the average user can do 
this to you:

while [ 1 ]; do
	logger "blah blah blah"
done

When your disk fills up...where's the login information going to go? The audit 
system has higher integrity due to needing CAP_AUDIT_WRITE to send login 
information. The kernel collects some of the data from the process 
credentials so its more trustworthy. It can alert the admin when the audit 
partition is starting to get full and then take the machine down if it does 
fill.

-Steve