path-based filesystem watch limitation

[Timothy R. Chavez]

On Thursday 18 August 2005 11:31, Amy Griffis wrote:
> On Tue, Aug 16, 2005 at 05:19:06PM -0400, Steve Grubb wrote:
> > In practice, though, it doesn't cause problems. I don't know of any
> > trusted app that renames a directory and creates a new data file. 
> 
> If we aren't trying to watch all path components, I don't understand
> why we need the dcache hooks.  

The dcache hooks are used to manage the watches after they've been
created.  So let's say you've said,

watch /etc/shadow

When you then later decide to do,

passwd

During the execution of 'passwd', /etc/shadow will momentarily cease to exist.  
When /etc/shadow comes back, it'll be a new inode.  We must then update that 
inode with the necessary watch information.  Thus, the watch point, 
"/etc/shadow" is preserved.

Using the same 'passwd' execution, we might also consider this scenario, 

watch /etc/nshadow

During the execution of 'passwd', /etc/shadow will be renamed to "nshadow".
If we have watched /etc/nshadow, then when the rename occurs, we add
the to the inode under /etc/nshadow, and thus, it becomes auditable.t

In this light, the feature does a decent job at auditing well-defined (and 
hopefully security critical) locations and names.

> 
> If we want to watch a particular dentry, it seems like watching its
> parent's inode for filesystem events would suffice.

We must rely both on the dentry and the inode.  We're really watching the 
inode, but the way we discover this inode, is through its dentry.  So even if 
this were the approach we took, it'd still need to use the dcache right?

> An inode is 
> always held by the i_sem through the execution of any event-catching
> hook.  Thus we are able to add a watch for the inode appearing
> at the watched location in time to catch any further events.
>
> I've read through quite a bit of the archives for this list, and
> haven't found the reason for the dcache hooks.  Could someone comment
> on this?

Hope this helps.

-tim

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