From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amy Griffis Subject: Re: inotify_rm_watch behavior Date: Mon, 11 Sep 2006 15:34:51 -0400 Message-ID: <20060911193450.GA2542@fc.hp.com> References: <200609111505.24567.efleury@br.ibm.com> <20060911184903.GA32335@fc.hp.com> <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: redhat-lspp-bounces@redhat.com Errors-To: redhat-lspp-bounces@redhat.com To: Stephen Smalley Cc: redhat-lspp , linux-audit@redhat.com List-Id: linux-audit@redhat.com 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