From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 10 Feb 2009 09:05:03 -0500
Subject: [refpolicy] [RFC] Network MLS constraints
In-Reply-To: <200902061715.10030.paul.moore@hp.com>
References: <200902061715.10030.paul.moore@hp.com>
Message-ID: <1234274705.4921.16.camel@gorn>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, 2009-02-06 at 17:15 -0500, Paul Moore wrote:
> In the course of looking into a problem with the new network 
> ingress/egress controls with the MLS policy I realized we were missing 
> MLS constraints for a lot of the new network controls ... Ooops.  Some 
> of the missing constraints are due to the new ingress/egress and peer 
> controls but I realized we are also missing the secmark controls.  I 
> just finished putting a patch together (still need to test it) but I'm 
> not 100% certain about some of these constraints (the inbound controls) 
> so I wanted to send out this email to try and generate some discussion.

These seem reasonable to me.  Perhaps including the SELinux list would
be a good idea to include, in case there are some MLS people on that
list that aren't on this list?

> The first set of new constraints we need deal with the secmark and peer 
> controls.  Both controls are applied to packets as they are received by 
> a socket and in both cases the subject is the socket and the packet is 
> the object.  The constraints below should be fairly obvious:
> 
> mlsconstrain { peer packet } { recv }
> 	(( l1 dom l2 ) or
> 	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> 	 ( t1 == mlsnetread ));
> 
> The next set of constraints deal with the egress controls, packets that 
> are leaving the system.  In this case the subject is the packet's peer 
> which is the originating domain; the object varies from the network 
> interface (netif/egress), destination (node/sendto) and outbound 
> secmark (packet/forward_out).  Once again, I expect these constraints 
> to be fairly straightforward:
> 
> mlsconstrain { netif } { egress }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> 	 (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 ( t1 == mlsnetwrite));
> 
> mlsconstrain { node } { sendto }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> 	 (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 ( t1 == mlsnetwrite));
> 
> mlsconstrain { packet } { forward_out }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> 	 (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 ( t1 == mlsnetwrite)
> 	 ( t1 == unlabeled_t));
> 
> The last set of constraints deal with the ingress controls, packets that 
> are entering the system.  Here is where things become a bit less 
> obvious and while I spent a good deal of time convincing myself they 
> are "correct", I would appreciate some comments/feedback before I go 
> much further.  The funny part about these constraints is that they look 
> very similar to the outbound constraints in that they are "write" 
> constraints.  The reason for this is that the subject in each of these 
> constraints is not a local domain, but rather the remote system's 
> domain (the packet's peer).  Take the netif/ingress constraint as an 
> example: even though this access control happens when the packet is 
> received by the local system, the permission/constraint is controlling 
> the peer's ability to write data to a network interface.  While 
> treating the constraint as a "write" might not be the obvious first 
> choice I think it makes the most sense.  You will note that the special 
> handling (pass) for unlabeled_t packets is to prevent any problems with 
> unlabeled traffic.
> 
> mlsconstrain { netif } { ingress }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> 	 (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 ( t1 == mlsnetwrite)
> 	 ( t1 == unlabeled_t));
> 
> mlsconstrain { node } { sendto }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> 	 (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 ( t1 == mlsnetwrite));
> 
> # identical to the forward_out case
> mlsconstrain { packet } { forward_in }
> 	(( l1 eq l2 ) or
> 	 (( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
> 	 (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> 	 ( t1 == mlsnetwrite)
> 	 ( t1 == unlabeled_t));



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