[redhat-lspp] Re: inotify_rm_watch behavior
Stephen Smalley
sds at tycho.nsa.gov
Tue Sep 12 13:45:57 UTC 2006
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.
--
Stephen Smalley
National Security Agency
More information about the redhat-lspp
mailing list