Re: [PATCH] audit: file system auditing based on location and name
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html