On Monday 01 May 2006 15:25, Amy Griffis wrote: > This audit subsystem was designed around knowledge of syscalls,
I think its fairer to say that syscall auditing is 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. (!) auditctl figures that out for people. > The filesystem auditing capability that is currently upstream > (inode-based) requires a knowledge of syscalls. I really don't consider this to be file system auditing because the perspective is from a syscall point of view. To me, and in RHEL4, file system auditing is a whole different approach. It does away with any knowledge of syscalls and just requires the system admin to state what path and access type they are interested in. The approach is decoupled from syscall auditing mostly because of the heavy performance penalty that syscall auditing incurs. The decoupling does several things. It keeps syscalls that have nothing to do with the file system from paying any performance penalty. It frees user space from having to maintain any kind of function/syscall mapping. Upgrading users space and kernel can happen independently and both pieces continue to work. But it also allows the structuring of the command to a simpler format because they are decoupled in the kernel. If we were to create a network auditing subsystem, I would want it designed similarly. Step back from the problem, ask what the user would really want to know about the network, and design a command interface to answer those questions. It would not be coupled to syscalls because they have little to do with the question a user might ask. (Besides, if syscalls figured into it in anyway, they should use the syscall interface.) It should have properties of maintaining performance, no coupling with other types of auditing, and be cohesive or focused on just its one area. > 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. Who is going to maintain that mask in the future ? What about people with old user space utilities? -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
