[redhat-lspp] Getting rid of multilevel objects

[Klaus Weidner]

Hello,

currently the MLS policy supports multilevel objects (using a range where
the upper level is not equal to the lower level), for example
directories, sockets, and character devices.

In a LSPP system, untrusted processes should not be able to write such
objects since it's a data flow that bypasses the MLS restrictions, and
access should be limited to trusted processes with an appropriate
override attribute. For example, you can currently easily use filenames
in /tmp to exchange information, or automatically declassify information
using multilevel ptys.

My understanding is that the ranged ops were mainly a stopgap measure to
get a working system while we didn't have polyinstantiation and related
features yet. Currently the constraint looks like this:

    # the "ranged" file "write" ops
    mlsconstrain { dir chr_file blk_file sock_file } { write create ...}
	((( l1 dom l2 ) and ( l1 domby h2 ))
	 or ...)

I think a more appropriate constraint would be to allow only single level
write for these objects for untrusted subjects, effectively ignoring the
upper level in that case just like for regular files. Below I use
"mlsrangedobject" which doesn't currently exist as a specific override
attribute for this ability. (The existing "mlsfilewrite" override also
works if you don't need that level of granular permissions, in that case
the new constraint would be identical to the one for plain files.)

    # the "ranged" file "write" ops (only for trusted subjects or objects)
    mlsconstrain { dir chr_file blk_file sock_file } { write create ...}
	(( l1 eq l2 ) or 
	 ((( l1 dom l2 ) and ( l1 domby h2 )) and ( t1 == mlsrangedobject ))
	 or ...)

Alternatively, it would also work to add a constraint to refuse writing
to multilevel objects, but that would most likely require a lot more
changes to get the system working consistently:

    mlsconstrain { dir chr_file blk_file sock_file } { write create ...}
	(( l2 eq h2 ) or t1 == mlsrangedobject );

Any comments on this? I wanted to run this by the smaller group in this
list first before starting a bigger discussion on the selinux list...

As a side note, it doesn't appear to work to define constraints in a
loadable policy module, "checkmodule" just complains about a syntax error
when it gets to the "constrain" or "mlsconstrain" token. Is it not
supported or does it need special tricks?

-Klaus