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.