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. -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
