[redhat-lspp] Getting rid of multilevel objects

[Stephen Smalley]

On Fri, 2006-06-30 at 18:46 -0500, Klaus Weidner wrote:
> 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?

Constraints aren't supported in non-base policy modules, only in the
base module.

-- 
Stephen Smalley
National Security Agency