[RFC][PATCH 3/3] (#7U1) file system auditing

[Timothy R. Chavez]

On Sun, 2005-04-24 at 00:11 -0400, Valdis.Kletnieks at vt.edu wrote:
> On Sat, 23 Apr 2005 01:04:52 -0000, "Timothy R. Chavez" said:
> > I think for symmetry's sake, that makes sense.  But doing a "delete all" in
> > the kernel has these advantages:
> >
> > 1.  All watches can be deleted.  This might not be true in user space.  If the
> > path is invalid (ie: a namespace has changed or the path has become otherwise
> > inaccessible), you won't be able to delete the watch.
> 
> What should actually appear in the audit stream if this case happens?  Do we
> log enough info that the admin has a fighting chance of figuring out what happened
> even in the face of chroot or mount --bind or other similar things?

So when we list watches in user space what happens is the path used to
add the watch originally is checked.  If A) we can walk the path and B)
the watch exists we pass to user space a "valid=1" otherwise, "valid=0"
-- We also pass back the device the watch was added on (major:minor).

With regards to chroot and bind mounts, we assume that the admin is
aware of their namespaces and with bind mounts, we assume that as long
as the watch is still accessible by the original path provided (which
includes device), the watch should be removable regardless of the bind
mount.  There's a working assumption that in a CAPP environment the
Admin isn't going to do anything too bizarre or radical, and the likely
hood of namespace confusion is minimal at-best.  Is that reasonable?

-tim

> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit