Re: [RFC][PATCH] filesystem auditing by location+name

[Timothy R. Chavez]

On Friday 10 June 2005 17:38, Christoph Hellwig wrote:
> most of this looks like a copy & paste of the inotify code.  Could you
> please arrange with the inotify folks to merge the patches?
> 

Christoph,

Thank you for the response.

When we first started this project we had assessed whether or not inotify 
would be a feasible starting point, but ultimately rejected it.  What it came 
down to was that the objectives of inotify were distinctly different from the 
objectives of auditfs.  These distinctions were rooted in the very design of 
inotify.  Why?  Inotify is not a generic fs events notification subsystem.

Some of the cursory problems with using inotify which would need changing 
were:

1) Coverage

Inotify is only interested in a portion of the fs ops that we are interested 
in.  Most notably, we need the ability to generate records every time the 
[exec_]permission[_lite]() function is called.

2) Processing

The processing of events has to occur in the kernel, not in user space.  
Inotify collects events and tosses them back over the fence for processing.  
We cannot introduce any window of opportunity for audit subversion.

You see, auditfs is interested in the inode at location+name, whatever it may 
be when the auditable event occurs.  Thus, we've had to hook dcache to help 
us with this processing.  This is something Inotify does not care about nor 
should it.

Inotify will resolve a path to its inode and watch _that_ inode, we're saying 
"watch any inode at this path"

To build auditfs on top of inotify would require watching directories for 
events on its children and processing the events in the kernel (and not 
simply tossing them over the fence to user space).  This gets very... 
hackish ;)

3) Queue

Depending on the work, there may be a requirement that no audit record can be 
lost.  The message queue structure of inotify has the potential to overflow 
and drop events.  This is a no-go for us, but perfectly reasonable for 
inotify.

To make this work for us we'd have to hook the queueing functions to forward 
events on to the audit subsystem.  This would basically mean fitting a system 
that has been designed for interaction with userspace to also have 
interaction with other parts of the kernel... again, hackish.

4) Context

We require information regarding the process and system call associated with 
the fs event.  This is not necessarily evident from where the event occurred 
(ie: permission()).  Inotify would have to hook into the audit subsystem to 
get at this information. 


The only place that the two projects converge is in fs/namei.c where they both 
collect information about events.  One project notifies the audit subsystem 
and the other notifies user space.  I think it is here where a collaboration 
could take place without skewing the objectives of either project.

-tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/