Bug 222384 - LSPP: a user is not prevented from removing watches created by a user at a higher or lower MLS level.
LSPP: a user is not prevented from removing watches created by a user at a hi...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-strict (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-11 17:58 EST by Kylene J Hall
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-15 10:49:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kylene J Hall 2007-01-11 17:58:33 EST
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:
Comment 1 Daniel Walsh 2007-01-12 13:13:55 EST
Steven is this something we can prevent?
Comment 2 Stephen Smalley 2007-01-12 13:27:20 EST
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?
Comment 3 Stephen Smalley 2007-01-12 13:33:53 EST
The mls fd constraint was added to the upstream refpolicy on Sep 15 2006 per svn
log.

Comment 4 Daniel Walsh 2007-01-12 13:54:18 EST
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)
Comment 5 Stephen Smalley 2007-01-12 14:49:51 EST
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.   
Comment 6 Kylene J Hall 2007-01-12 18:39:31 EST
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.

Note You need to log in before you can comment on or make changes to this bug.