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

["Timothy R. Chavez" <tinytim@us.ibm.com>]

On Friday 08 July 2005 12:46, Greg KH wrote:
> On Thu, Jul 07, 2005 at 02:49:15PM -0500, Timothy R. Chavez wrote:
> > 
> > Even if access control prohibits us from actually seeing the content of 
> > /etc/shadow, if we're auditing /etc/shadow, attempts should be logged 
> > and not gone unnoticed.
> > 
> > watch /etc/shadow
> > passwd
> > <inode changes before execution ends>
> > cat /etc/shadow (goes unaudited)
> > <send event to user space>
> > ln /etc/shadow /home/foo/evil_shadow (goes unaudited)
> > <process in user space>
> > cat /home/foo/evil_shadow (goes unaudited)
> > <send back instructions to kernel to watch the new /etc/shadow>
> > cat /etc/shadow (audited)
> > 
> > Hmmm...
> 
> Then you watch the directory /etc/ which would have caught all of this,
> right?  My argument is that wouldn't inotify also want to know this
> exact same thing?
> 
> > > > I've yet to be convinced that merging these two projects or implementing 
> > > > one in terms of the other has any real benefit to either project in terms of
> > > > their individual goals and requirements.
> > > 
> > > You have common hooks in the kernel.  You do almost the same thing
> > > (report fs changes to userspace.)  Seems a natural thing to me.
> > 
> > This patch reports "fs changes" to the audit subsystem which then adds them 
> > to the audit_context of the current task.  Then, at system call exit, the audit_context 
> > is sent to user space, effectively logging not only the "fs change", but information 
> > regarding the process, system call, path, etc, to give the complete account.
> 
> Great, so your userspace notification is different than inotify, that's
> fine.  But what you are trying to do within the kernel is pretty much
> the same, which is my main point.
> 
> > > > The only real similarty between the two projects from my POV is that they 
> > > > are both interested in reporting a subset of file system activity and could 
> > > > benefit from a set of common hooks (ie: fsnotify) where it makes sense.
> > > 
> > > Exactly.  What else is there?
> > 
> > The fact that audit is interested in more activity then Inotify (like permission()),
> 
> Fine, inotify users can just ignore those messages.  Or perhaps they
> will grow to want to see them.
> 
> > must strive to never lose events,
> 
> Why is this not a good goal for inotify to also have?
> 
> > interacts with the audit subsystem directly, 
> 
> Ok, a difference.
> 
> > must conform to security requirements placed on it by various
> > Protection Profiles (for the time being, CAPP),
> 
> And those "security requirements" are what?
> 
> > defers sending the event record to user space until system call exit,
> 
> Again, not a big deal for inotify.
> 
> > the inode is relevant only if it's associated with the last component
> > of an audited path (not just the inode targetted initially)...
> 
> Again, something that I think inotify would like to also know.
> 
> > And I'm sure Robert could point out things that Inotify does that
> > audit doesn't do (and isn't very interested in doing).
> 
> Sure, just because you all do some things differently, doesn't mean that
> you shouldn't use the same core code.
> 
> Now I know you don't want to worry about another project's code getting
> into the kernel tree to depend on your changes, but hey, that's life.
> Try working with the inotify developers instead of ignoring them and
> duplicating the same stuff.
> 
> Also, you still have not pointed out what auditfs is for and how to use
> it.
> 

Yeah, it's admittedly named badly.  Perhaps that can change.

kernel/audit.c
kernel/auditsc.c
kernel/auditfs.c

> 
> thanks,
> 
> greg k-h

Hello Greg,

I've chosen not to respond to individual segments because the overall theme
is that the right thing to do is to not duplicate functionality.  Your suggestion 
is to merge the two projects.  In your mind, this benefits both projects.  It will 
consolidate the common functionality and enhance Inotify such that it is not 
only an event notification system for user space, but for other parts of the 
kernel -- namely audit -- as well.  Is this a fair assessment?

I think we can all agree that functionality should not be duplicated.  I have 
conceded that having two seperate hooks side-by-side that have the same 
purpose should be consolidated.  Because this would be generic, all other
notification hooks should be available to Inotify (and any other subsystem) 
as well.  Agreed?

My vision is that audit, Inotify, and whatever else plugs into this framework 
and receives notifications this way -- a file system event notification system 
for the kernel.  Then, audit, Inotify, etc would process this even information 
it receives and does with it what they will.

Ultimately, the part where we differ most, is the processing of information in 
fs/dcache.c to give dynamic updates in response to file system activity (such 
as attaching audit information to an auditable file whose inode just changed).  
I believe this should be kept seperate and not part of this framework nor Inotify.  
It's a specific requirement for audit, but not for Inotify.  This is one of the places 
the two systems are functionally different.

By doing it this way, both projects can retain their original goals and meet 
their individual requirements, and all the common pieces are consolidated in 
a logical way.  This is something Robert and I had discussed on LKML in early  
December 2004, and was brought up in a discussion more recently for an RFC 
on LKML in early June between Christoph Hellwig and myself.

Can this patch not be placed in -mm for the time being, as-is?  Surely the 
logic it implements, what I envision will ultimately be retained, could benefit 
from the exposure in the interim?

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