Description of problem: As discussed in this thread (http://osdir.com/ml/linux-audit@redhat.com/msg00588.html) inotify is not a data object and not subject to DAC. However, a scheme was laid out for subjecting it to MLS constraints; however, these don't appear to have been added to the policy. I can create an inotify object and add watches to it as a user at one level and remove those watches as the user at the same level. However, I can also remove those watches as the user with a higher or lower MLS level, neither of which I would expect to be able to do. Version-Release number of selected component (if applicable): selinux-policy-mls-2.4.6-22.el5.noarch.rpm How reproducible: very Steps to Reproduce: 1. Create an inotify instance as a user and add a watch to it. 2. Change MLS level 3. Attempt to remove the watch Actual results: Able to remove the watch Expected results: Unable to remove watch. Additional info:
Steven is this something we can prevent?
If the MLS constraint on fd use was added to the -mls policy as per that discussion, then that should prevent inheritance or transfer of inotify instances from one level to another level (the fd use check would fail, and the descriptor would be closed and replaced with a descriptor to the null device). Can someone a) confirm presence of that MLS constraint in that policy, and b) provide a test case?
The mls fd constraint was added to the upstream refpolicy on Sep 15 2006 per svn log.
RHEL5 mls policy has the following: # No sharing of open file descriptors 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 ); grep -r mls_fd_share . ./policy/modules/services/cron.te:mls_fd_share_all_levels(crond_t) ./policy/modules/services/cron.te:mls_fd_share_all_levels(crond_t) ./policy/modules/system/selinuxutil.te:mls_fd_share_all_levels(newrole_t) ./policy/modules/system/authlogin.if: mls_fd_share_all_levels($1) The above causes all login programs to have this priv grep -r mls_fd_use_all_levels . ./policy/modules/services/cups.te:mls_fd_use_all_levels(cupsd_t) ./policy/modules/system/setrans.te:mls_fd_use_all_levels(setrans_t) ./policy/modules/system/init.te:mls_fd_use_all_levels(init_t) ./policy/modules/system/logging.te:mls_fd_use_all_levels(auditd_t)
Policy looks fine. What is the test case to demonstrate the bug? Seems rather complicated to set up, as you are dealing with process-private file descriptors and instance-private watch descriptors here, not global identifiers. Process A would need to create (inotify_init) and add a watch (inotify_add_watch), obtaining a fd and a wd. Then it would need to pass the actual fd (not just the number, but the object) to another process (fork+execve or local IPC) along with the wd value. Then the other process could try to inotify_rm_watch(fd, wd). But doing that between processes in different levels should be prevented by the exec-time inheritance checks and the local IPC file receive checks, and you shouldn't be able to exec into a different level without going through newrole anyway.
Sorry not a bug. I didn't look at the output from my testcase well enough to see that it was simply a different error code than I was expecting.