[redhat-lspp] Re: [PATCH] testing new audit features

[Amy Griffis]

Steve Grubb wrote:     [Thu Apr 06 2006, 05:03:20PM EDT]
> On Thursday 06 April 2006 16:39, Amy Griffis wrote:
> > > 2) What about perms? If someone wanted to express that they want to get
> > > write changes to /etc/passwd, how do they do it?
> >
> > Assuming you mean writes to the file itself,
> >
> > ? ? auditctl -a exit,always -S open -F watch=/etc/passwd
> 
> Maybe it should be:
> auditctl -a exit,always -S write -F watch=/etc/passwd

I guess you'd also want to include truncate calls.  Having an
audit-rules-writing howto would be pretty helpful I think.

> So what about execution of a certain program? For example, we need
> to see if a user tries to reset the audit rules. Would the audit
> rule be:
> 
> auditctl -a exit,always -S execve -F watch=/sbin/auditctl

Yes.

> > > 3) Does this mean that the file system auditing is handled by the syscall
> > > exit filter ?
> >
> > Yes, in that way it is like inode-based filtering.
> 
> Then this is truly bad news. Suppose that we typically have 20-30 watches. 
> Every single syscall will be affected since it will have to scan through 
> 30-40 rules to see if any apply. (There's about 10 syscall auditing rules.)
> 
> Have you considered this problem? Are there any ways to separate your file 
> system auditing from syscall auditing? Do you see any optimizations to it?
> 
> Can we do wildcard matching? If not, we have a real problem since I know of  
> one person has tried to audit writes to about 5000 individual files. Imagine 
> that affecting every single syscall.

There are a couple of ways to approach this issue.  What you describe
is not really specific to filesystem auditing.  It happens anytime
someone has a large number of rules that are weighted to a small set
of syscalls.  We need to improve the intelligence of the audit
filtering so audit doesn't spend so much time checking filters that do
not apply.

Additionally, we can work on providing options for reducing the number
of filesystem-related rules.  One thing we've discussed in the past is
providing a feature which would allow someone to watch an entire
subtree with a single rule.

I view both of these as follow-on projects to providing the basic
watch functionality.

> > > 7) Also...what becomes of the watch_filter? Does it still work ? Is it
> > > still needed ?
> >
> > No, the same feature is now provided using the exit filter list.
> > Additionally, you may now specify different filters per watched file
> > if you like, instead of being forced to apply a filter to all watched
> > files.
> 
> Should we delete it from audit.h ?

Hmm.  Maybe just mark it as deprecated for now.