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.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |