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

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

On Wednesday 06 July 2005 18:50, Greg KH wrote:
> On Wed, Jul 06, 2005 at 03:23:10PM -0500, Timothy R. Chavez wrote:
> > This is similar to Inotify in that the audit subsystem watches for file
> > system activity and collects information about inodes its interested 
> > in, but this is where the similarities stop.  Despite the fact that the
> > Inotify requirements only dictate a subset of the activity the audit
> > subsystem is interested in, there is a more fundamental divergence 
> > between the two projects.  Like audit, Inotify takes paths and resolves 
> > them to a single inode.  But, unlike audit, Inotify does not find the path 
> > itself interesting.
> 
> Huh?  inotify users find that path interesting, as they use it to act
> apon.

I really didn't want to go back and forth on this (my fingers are still sore from
our convo on ltc-interlock :-)), but I might as well oblige.

> 
> > Much like the (device,inode)-based system call filters 
> > currently available in the audit subsystem, Inotify targets only individual 
> > inodes.  Thus, if the underlying inode associated with the file /etc/shadow 
> > was changed, and /etc/shadow was being "watched", we'd lose auditability 
> > on /etc/shadow across transactions.
> 
> That's why you watch /etc/ instead, which catches that rename.  That
> being said, why would not inotify also want this functionality if you
> think it is important?

Sure, by watching a directory with Inotify, you receive notification upon rename() 
events.  Now, as far as Inotify is concerned, how this is finally interpreted is up to 
the user space programs it's feeding.  In terms of audit, there must never be a
chance for subversion.  If this feature were implemented in terms of Inotify as it 
stands now, the processing we do in fs/dcache.c would need to be shifted to a
user space app which is obviously out of the question.  One alternative, the one 
I believe you're in favor of, is to augment Inotify itself.  But, AFAICT, nothing in 
Inotify's documentation leads me to believe that this adds anything to Inotify itself 
(with the exception of complication and obfuscation), especially in terms of event 
notification.  IMO, by tieing our logic to Inotify we'd inadvertently be dooming it to 
the dreaded Second-system syndrome:

http://en.wikipedia.org/wiki/Second-system_effect

> 
> > More so, Inotify cannot watch inodes that do not yet exist (because
> > the file does not yet exist).  To do this, the audit subsystem must
> > hook deeper than Inotify (in fs/dcache.c) to adapt with the file
> > system as it changes.  Where it makes sense, the small set of
> > notification hooks in the VFS that Inotify and audit could share
> > should be consolidated.
> 
> As inotify works off of open file descriptors, yes, this is true.  But,
> again, if you think this is really important, then why not just work
> with inotify to provide that kind of support to it?

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.

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.

> 
> I suggest you work together with the inotify developers to hash out your
> differences, as it sounds like you are duplicating a lot of the same
> functionality.

Where functionality is the same or similar, we can address that, but surely 
in the interim the inclusion of this patch into -mm would be beneficial to the 
98% of dissimilar functionality :)

> 
> Also, inotify handles the namespace issues of processes by working off
> of a file descriptor.  How do you handle this?

Well I guess this boils down to what you consider an issue.  In terms of audit 
and this patch, tagging audit info to the inode ensures that it's auditable from 
any namespace.  When a location and name is audited, the administrator does 
so from what they consider a meaningful namespace and device (ie: for most, 
the path /etc/shadow is meaningful, so by "watching" it, you've made a file 
containing security secrets auditable and not your favorite LOTR ascii art) .

-tim

> 
> Do you have any documetation or example userspace code that shows how to
> use this auditfs interface you have created?

> 
> thanks,
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
-
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/