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