Re: [PATCH] audit: file system auditing based on location and name

[Steve Grubb <sgrubb@redhat.com>]

On Thursday 07 July 2005 15:04, Greg KH wrote:
> You are adding auditfs, a new userspace access, right?

Not sure what you mean. This is using the same netlink interface that all the 
rest of the audit system is using for command and control. Nothing has 
changed here. What is different is the message I send into the kernel. The 
audit system dispatches it into Tim's code which in turn sets up the watch. 

The notification that the event has occurred uses the same interface that all 
other audit events use. Its just a different message type. It is filtered by 
some attributes and if it is still of interest, the event is placed in the 
queue so it is serialized with all other events.

> His email provided no documentation that I could see.  Am I just missing
> something?

The auditfs code is programmed by filling out the watch_transport structure 
and sending a AUDIT_WATCH_INS message type. The perms, pathlen, & keylen are 
all that's filled out. The path & key are stored back to back in the payload 
section. To delete, you do the same thing and send AUDIT_WATCH_REM message. 
Yes, this should be added to the documentation.

> > > So the userspace package in FC4 will not use auditfs?
> >
> > Right. You get a few warnings due to missing functionality. If the kernel
> > were patched with Tim's code, it all works as expected. We have worked
> > out the user space access and that shouldn't be changing.
>
> Then what use is auditfs for if you don't need it?

But we do. You cannot audit files who's inode may change using the current 
syscall techniques. I put the code into FC4 hoping that one day we will have 
a kernel that supports it.

The current audit system code lets you audit by syscall, which means you can 
audit open or write, but then you get it for all processes that open or 
write. Or you could limit it with a pid, but that's impossible since you 
would have to predict the future pid when putting the audit rule in.

Tim's code lets you say I want change notification to this file only. The 
notification follows the audit format with all relavant pieces of information 
gathered at the time of the event and serialized with all other events.

> Am I correct in thinking that you all need to split this patch into two
> pieces, the new inode stuff, and auditfs, as neither one has anything to
> do with the other?

It could be split to make it easier to read, but one's useless without the 
other.

-Steve