On Tue, Feb 22, 2005 at 01:58:42PM -0600, Timothy R. Chavez wrote: > And admitedly, I am also being a little redundant in that > the original code can already provide us with the read() and write() > exit code and the file/directory being read from/written to. However, > if we want to specifically monitor activity in the filesystem > surrounding watched objects, then wouldn't these hooks in read(), > write(), etc be vital? Klaus? How else will we know if a read() or > write() trully succeeded or failed on a watched filesystem object? read() and write() aren't considered security relevant operations since they don't do any permission checks. From the CC point of view the interesting call is open(), and if that's properly handled it's enough.

On Tue, Feb 22, 2005 at 01:58:42PM -0600, Timothy R. Chavez wrote: > And admitedly, I am also being a little redundant in that > the original code can already provide us with the read() and write() > exit code and the file/directory being read from/written to. However, > if we want to specifically monitor activity in the filesystem > surrounding watched objects, then wouldn't these hooks in read(), > write(), etc be vital? Klaus? How else will we know if a read() or > write() trully succeeded or failed on a watched filesystem object? read() and write() aren't considered security relevant operations since they don't do any permission checks. From the CC point of view the interesting call is open(), and if that's properly handled it's enough. In most real-world scenarios you probably won't want to be auditing read and write operations individually anyway. > Perhaps there's enough information in just an open(). The record will > give us the filesystem object information, plus it will tell us which > permission was used (READ/WRITE/EXEC/APPEND) provided it allows for > that permission in the mask and the exit code of the open(). However, > will the exit code necessarily be a reflection of a permission > failure? The only CAPP requirement is to record success/failure, you'll actually get a bit more if you audit the errno as reported by the kernel, that way permission failures should get EACCES as opposed to ENOENT or other error conditions. -Klaus

Ok, great. I've removed the hooks. I can also get away with taking the hooks out of unlink right because I should be hitting permission() in access(), before I do the unlink()?

Just a heads up. I've come across several glaring bugs (such as creating a cache with the wrong struct sizing), a couple bugs in audit_watch(), etc. I've also reduced redundant code and made some of my helper functions tighter. I'll be releasing an intermediary patch that has all these changes, including the elimination of whitespaces and other bogus information in the patch. I hope this patch will pretty much be patch #5 without the remaining feature to list all the watch points currently in the FS. On a similar note, I'd like to start getting feedback on linux-fsdevel with a CC directly to Al Viro about the design itself. What do you all think of this approach? Or perhaps I should bring it directly to LKML? Should I wait until the intermediary patch #5 is completed and tested before I start any dialog? I personally think overlapping the two would be fine. The reason I think this is because the first major stumbling block has nothing to do with the implementation itself, but the design and all the philosophy and politics surrounding it. As soon as I mention "filesystem auditing" I've noticed that people get antsy and immediately try to beat it down like a pianta made out of software patents J/K. Thus I feel a large part of this endeveour is going to revolve around explanation. Do you agree? I'd appreciate some feedback.

I'd like to start getting feedback on linux-fsdevel with a CC directly to Al Viro about the design itself. What do you all think of this approach? Or perhaps I should bring it directly to LKML? Should I wait until the intermediary patch #5 is completed and tested before I start any dialog? I personally think overlapping the two would be fine. The reason I think this is because the first major stumbling block has nothing to do with the implementation itself, but the design and all the philosophy and politics surrounding it. As soon as I mention "filesystem auditing" I've noticed that people get antsy and immediately try to beat it down like a pianta made out of software patents J/K. Thus I feel a large part of this endeveour is going to revolve around explanation. Do you agree? I'd appreciate some feedback.