[redhat-lspp] Watch question

[Steve Grubb]

On Thursday 27 April 2006 18:44, Loulwa Salem wrote:
> And from some analysis, when I do a listing of rules and watches .. it
> looks like the following syscalls are audited when a watch is added:
>         open, truncate, rename, mkdir, rmdir, creat, link, unlink, symlink,
> chmod, fchmod, chown, fchown, lchown.

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. I've coded the exact list that Amy supplied. So, now what if 
someone sends a patch to lkml to add a new syscall that does something with 
the file system? Looking at what's happened between 2.6.15 & 2.6.17rc3...its 
already happened. 

Every kernel update, someone is going to have to go over all syscalls and see 
what is new and make new user space tools for people to use with the new 
kernel. This is Not Good for the community. Distributions that rebase their 
kernel will always have a problem since they will always need a new user 
space tool update to just to keep watches working.

The RHEL4 audit system was hooked into the code paths that touched the file 
system so that user space did not have to be aware of syscalls to get it to 
work properly. I really think this is the way to do it.

> Is that what we intended? should execve be also included?

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.

Not being able to express it this way will be a regression for Enterprise 
customers. We need -w unhooked from -S. We need to have the concept of -p 
added back to the current implementation. The 'a' option to -p should be 
redefined from 'append' to 'attribute'.

> Do we need to specifically add a syscall rule for execve now to capture the
> audit record associated with it?

That depends on what the group decides. I don't like the coupling.

-Steve