[redhat-lspp] Watch question

[Timothy R. Chavez]

On Fri, 2006-04-28 at 08:50 -0400, Steve Grubb wrote:
> 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.

We've always assumed that either the user has knowledge of system calls
(e.g. auditctl -a exit,always -S open -F uid=501) or will use a profile
provided to them (capp/lspp).  I don't see a huge difference here with
regards to the new file auditing code.  I'm also operating under the
assumption that you can do the following:

    auditctl -a watch,always -S execv -F path=/tmp/foo

I don't see how that is much different than

    auditctl -a exit,always -S execv -F inode=`ls -i /tmp/foo`

I haven't played with the tools recently.  I thought there was going to
be a feature where you could create system-call aliases which alllow me
to conceptually specify an intuitive name like "fs_all" (which would be
a summation of "fs_read", "fs_write", and "fs_exec") which mapped to a
given set of system calls.  This approach requires a minor update to a
file.

This work is not trivial and we've struggled with the "right solution"
for.. years.. now :)  Amy was able to increase the granularity of file
auditing as well as homogenize the interface.  I don't think she really
assumed the user would require anymore knowledge than the knowledge one
would need to add any other system call rule.

> 
> 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.

I do concede on this point.  You're right that having to update a user
space tool in this fashion is going to be quite annoying.  If there was
an easy mechanism to add a system-call to a group / alias, for example
an /etc/audit/aliases file, it might not be so annoying??

> 
> 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.
> 

This worked, it was easy... it did produce some cruft... it was also
ugly as sin... By hooking critical paths, we ensured that anything new,
would be automatically audited if it touched this path.  Not exactly
sure if operating under this assumption would have been wise, though.  I
think the audit community is going to always have to be vigilant when it
comes to new features that affect our work.  System calls get added,
yes, but code also gets reorganized... new code gets added.

> > 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.

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.

> 
> 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'.

Yah... I think this is a bit unfortunate.  However, I think the concept
of -p can be generalized for system-call auditing like I've mentioned
above with groups / aliases.

> 
> -Steve

-tim