Re: [redhat-lspp] Re: inotify_rm_watch behavior

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.