Re: [redhat-lspp] Watch question

[Steve Grubb <sgrubb@redhat.com>]

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