inotify_rm_watch behavior

[Amy Griffis]

Stephen Smalley wrote:  [Mon Sep 11 2006, 03:15:59PM EDT]
> On Mon, 2006-09-11 at 14:49 -0400, Amy Griffis wrote:
> > Eduardo Madeira Fleury wrote:  [Mon Sep 11 2006, 02:05:24PM EDT]
> > > I'm doing some tests and currently inotify_rm_watch is not performing any 
> > > permission checks, i.e., an ordinary user can remove a watch set by root on a 
> > > file with root:root 400 permission.
> > > 
> > > Is this the expected behavior? Seems like neither MAC nor MLS checks are being 
> > > done.
> > 
> > Yes.  As I understand it, an inotify watch is not a data object, and
> > so does not require DAC or MAC checks.
> 
> Not sure I follow the rationale for MAC.  Process in security context C1
> creates an inotify instance, adds some watches to files/directories it
> can read (read permission checked between C1 and file context upon
> inotify_add_watch), provides the instance descriptor to a process in
> security context C2 via execve inheritance or local IPC.  Process in
> security context C2 can now read events on those watched
> files/directories even if it lacks direct read permission to them and
> can add and remove watches on the inotify instance, indirectly signaling
> the C1 process via the shared inotify instance.
> 
> All of which would be avoided if the MLS policy included a constraint on
> fd use permission, thereby preventing such sharing of inotify instances
> among processes in different levels except for trusted subjects or
> objects identified by a type attribute.

Agreed.  I was trying to say that there shouldn't be a constraint on
the inotify watch itself.  Until I saw your mail, I wasn't aware that
there aren't currently any constraints on sharing inotify instances.

Amy