[refpolicy] [RFC] Network MLS constraints

Paul Moore paul.moore at hp.com
Fri Feb 6 16:15:09 CST 2009


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.

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));

-- 
paul moore
linux @ hp


More information about the refpolicy mailing list