Re: MLS directory write constraints

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On Mon, 2007-08-20 at 15:52 -0500, Klaus Weidner wrote: 
> On Mon, Aug 20, 2007 at 08:34:57AM -0400, Christopher J. PeBenito wrote:
> > After doing some work on some MLS systems last week, I observed some
> > constraint denials like this:
> > 
> > type=AVC msg=audit(1187122358.679:120): avc:  denied  { write } for
> > pid=2829 comm="foo" name="run" dev=dm-0 ino=3309608
> > scontext=system_u:system_r:foo_t:s15:c0.c1023
> > tcontext=system_u:object_r:var_run_t:s0-s15:c0.c1023
> > tclass=dir
> > 
> > Where a daemon has TE rules for creating it's PID file in /var/run, but
> > gets denied by this MLS constraint:
> > 
> > mlsconstrain { file ... dir ... } { write create setattr relabelfrom append unlink link rename mounton }
> > 	(( l1 eq l2 ) or
> > 	 (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> > 	 (( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
> > 	 ( t1 == mlsfilewrite ) or
> > 	 ( t2 == mlstrustedobject ));
> > 
> > It seems like it should be able to create a file in the directory, since
> > the daemon's level is within the range of the directory.
> 
> Ranged directories are an information leak in an MLS system, the current
> restrictions are intentionally set the way they are to prevent them.
> 
> For the CC evaluation of LSPP compliance, we needed to draw a line
> between explicit data flows (which need to be enforced by the OS), and
> covert channels (which are beyond the scope of the evaluation). 
> 
> The method we used to decide this was to check if an interface allows
> creation of arbitrary textual/binary data that can be read at another
> level - if that's the case, the OS needs to enforce the strict LSPP MLS
> constraints and prevent write down. Unfortunately directory write
> operations to ranged directories would break this constraint since the
> filenames can be chosen arbitrarily and read at lower levels, and this
> must not be allowed for untrusted subjects.

Does RHEL5 LSPP have a polyinstantiated /var/run?  If not, then every
daemon that doesn't run with a system low level will need this at a
minimum, thus partially negating what you are trying to do.

> You'd need to use one of the subject or object override attributes to
> permit this access if you need it - that's what they are there for, and
> if you need more granularity it may make sense to define a
> "mlswritetorangeddir" attribute to allow only this specific override. For
> LSPP compliance, the default behavior for untrusted subjects should
> remain not to allow it.

I see that the constraints are different in the 2.4.6-67 LSPP policy.
Is this the final one?  I want to make sure that the LSPP policy changes
have been integrated upstream.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.