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.

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.

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.