Audit config for NISPOM req's

[Curtas, Anthony R.]

Thanks for the response.  What it looks like I need is a few syscalls
and a lot of file watches.  The sample capp.rules I was looking at seems
to fit the bill, although I'll have to add some extra watches to the
/etc directory.

One thing that still confuses me is how "possible" is implemented.  From
what I've read in the documentation, it looks like if you set a rule for
entry,possible -- the audit system waits until a file watch is thrown,
then it writes the event.  Do I have this right?  If I always want to
see when /etc/shadow is opened:

-w /etc/shadow -rwxa
-a entry,possible -S open 

Will that work?  And if I understand the mechanism correctly, that would
log an open of ANY file that has a watch on it?

One last thing, if I only want unsuccessful open attempts on the watch
files, would this work?
-a entry,possible -S open -F success!=1

Thanks again,
Anthony


_____________
Anthony Curtas
SAIC, Division 35


-----Original Message-----
From: Steve Grubb [mailto:sgrubb at redhat.com] 
Sent: Friday, December 22, 2006 9:20 AM
To: linux-audit at redhat.com
Cc: Curtas, Anthony R.
Subject: Re: Audit config for NISPOM req's

On Friday 22 December 2006 08:38, Curtas, Anthony R. wrote:
> My main confusion on getting started is the difference between
syscalls
> and watches.

Syscalls audit syscalls based on the various parameters accessible
during the 
syscall. This means that every syscall is affected since it has to be 
analyzed to determine if it meets the criteria to trigger or suppress an

audit event. If you use syscalls to audit files, you have to do it by
inode. 
This is fine for files that do not move. You can also use devmajor/minor
to 
watch whole disks or devices.

Watches solve the problem by allowing you to audit a file by its name.
The 
kernel then converts it to inode auditing internally and changes the
inode 
that is being audited whenever the file is moved/renamed. Watches also
do not 
affect the performance of every syscall.

> It seems watches can do almost all of what I need, but they seem to be
> less "configurable" than the syscalls (like ignoring if root changes
> anything).

This is true in RHEL4. RHEL5/FC6 is more configurable.

> Can someone explain the difference and where one is more appropriate
than
> the other.

Syscalls are appropriate whenever you have something global to audit.
Watches 
are more appropriate when you are interested in specific files.

-Steve