Red Hat Bugzilla – Bug 222384
LSPP: a user is not prevented from removing watches created by a user at a higher or lower MLS level.
Last modified: 2007-11-30 17:07:40 EST
Description of problem:
As discussed in this thread
(http://email@example.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):
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
Able to remove the watch
Unable to remove watch.
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
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 .
The above causes all login programs to have this priv
grep -r mls_fd_use_all_levels .
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
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.