Re: Watch question

[Amy Griffis <amy.griffis@hp.com>]

Timothy R. Chavez wrote:     [Fri Apr 28 2006, 11:29:27AM EDT]
> On Fri, 2006-04-28 at 08:50 -0400, Steve Grubb wrote:
> > I completely disagree with the current file system auditing approach requiring 
> > explicit syscall coupling. I think it is a big problem for the security 
> > community to have a tool for auditing files that requires knowledge of 
> > syscalls. 

This audit subsystem was designed around knowledge of syscalls, to the
point that it requires the user to know whether a particular rule
field is applicable at syscall entry or exit time. (!)

The filesystem auditing capability that is currently upstream
(inode-based) requires a knowledge of syscalls.  The path-based
functionality I've been working on isn't supposed to be a replacement
for the current inode-based filtering.  It is supposed to complement
it to provide a way to audit config files.

> > I personally want to be able to tell the kernel that I want notification of: 
> > reads, writes, execution, or changes to attributes of a specific file or all 
> > files in that directory and subdirectories. User space should not have to 
> > know which syscalls implement each of the categories.
> 
> This is really simple and intuitive.  I like it.  These abstractions
> should be easily expressed.  I don't imagine that the majority of the
> users of audit are going to need the level of granularity that's been
> provided, which is why the above makes sense.

Agreed, I think this makes a lot of sense.  As Al also mentioned in
another thread, having auditctl specify a special bit or flag that
tells the kernel to set the appropriate bits in the syscall mask would
solve the problem for userspace.

--
redhat-lspp mailing list
redhat-lspp@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-lspp