From mboxrd@z Thu Jan 1 00:00:00 1970 From: Darrel Goeddel Subject: Re: [redhat-lspp] Re: inotify_rm_watch behavior Date: Tue, 12 Sep 2006 09:09:31 -0500 Message-ID: <4506BF9B.5040808@trustedcs.com> References: <200609111505.24567.efleury@br.ibm.com> <20060911184903.GA32335@fc.hp.com> <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> <20060911193450.GA2542@fc.hp.com> <1158068757.324.94.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1158068757.324.94.camel@moss-spartans.epoch.ncsc.mil> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Stephen Smalley Cc: linux-audit@redhat.com, redhat-lspp List-Id: linux-audit@redhat.com Stephen Smalley wrote: > On Mon, 2006-09-11 at 15:34 -0400, Amy Griffis wrote: > >>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. > > > Yes, I pointed this out during the "Syscalls questions" discussion back > in June. Not sure why no one bothered adding such a constraint to MLS > policy at the time. It would be something like: > policy/mls: > # No sharing of open file descriptions between levels unless > # the process type is authorized to use fds created by > # other levels (mlsfduse) or the fd type is authorized to > # shared among levels (mlsfdshare). > mlsconstrain fd use ( l1 eq l2 or t1 == mlsfduse or t2 == mlsfdshare); > > policy/modules/kernel/mls.te: > attribute mlsfduse; > attribute mlsfdshare; > > policy/modules/kernel/mls.if: > interface(`mls_fd_use',` > gen_require(` > attribute mlsfduse; > ') > > typeattribute $1 mlsfduse; > ') > > interface(`mls_fd_share',` > gen_require(` > attribute mlsfdshare; > ') > > typeattribute $1 mlsfdshare; > ') > > > And then one would add mls_fd_use() and mls_fd_share() as appropriate to > types in the policy, e.g. > policy/modules/system/selinuxtil.te: > mls_fd_share(newrole_t) > > and likewise for login and friends. > > Naturally, one would need to exercise the system quite a bit to work out > exactly what domains require such use/sharing. The approach outlined above looks good. -- Darrel