From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id n1DKipuA004821 for ; Fri, 13 Feb 2009 15:44:51 -0500 Received: from g4t0014.houston.hp.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id n1DKioAu025421 for ; Fri, 13 Feb 2009 20:44:50 GMT From: Paul Moore To: chanson@TrustedCS.com Subject: Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints Date: Fri, 13 Feb 2009 15:44:42 -0500 Cc: refpolicy@oss.tresys.com, selinux@tycho.nsa.gov References: <20090212211531.619341973@hp.com> <170D6ABBBA770349AA49582A86FCED15BA0199@HAVOC.tcs-sec.com> In-Reply-To: <170D6ABBBA770349AA49582A86FCED15BA0199@HAVOC.tcs-sec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200902131544.42460.paul.moore@hp.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Friday 13 February 2009 02:36:17 pm chanson@trustedcs.com wrote: > Traditionally network objects in a MLS system are not usually subject to > the usual privilege overrides. I would propose something like the below: > > mlsconstrain { netif } { egress ingress } > ((( l1 dom l2 ) and ( l1 domby h2 )) or > ( t1 == mlsnetflow )); > mlsconstrain { node } { recvfrom sendto } > ((( l1 dom l2 ) and ( l1 domby h2 )) or > ( t1 == mlsnetflow )); > mlsconstrain { packet } { forward_in forward_out } > ((( l1 dom l2 ) and ( l1 domby h2 )) or > ( t1 == mlsnetflow )); > > "mlsnetflow" would be a new attribute useful for special cases like > unlabeled_t or kernel_t. Why were network objects not subject to privilege overrides in legacy/traditional MLS systems? I ask because I think we are best off keeping the MLS constraints as consistent as possible. If there is a sound reason for avoiding policy overrides for just the network controls than perhaps we should consider "fixing" the rest of the constraints and not just the new ones. > > -----Original Message----- > > > > Add MLS constraints for several network related access > > controls including the new ingress/egress controls and the > > older Secmark controls. Based on the following post to the > > SELinux Reference Policy mailing list: > > > > * http://oss.tresys.com/pipermail/refpolicy/2009-February/000579.html > > > > Signed-off-by: Paul Moore > > > > --- > > policy/mls | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 51 insertions(+) > > > > Index: refpolicy_svn_repo/policy/mls > > =================================================================== > > --- refpolicy_svn_repo.orig/policy/mls > > +++ refpolicy_svn_repo/policy/mls > > @@ -295,8 +295,59 @@ mlsconstrain { netif node } { tcp_send u > > # these access vectors have no MLS restrictions # node enforce_dest > > > > +# > > +# MLS policy for the network ingress/egress controls # > > > > +# the netif ingress/egress ops, the ingress permission is a "write" > > +operation # because the subject in this particular case is > > the remote > > +domain which is # writing data out the network interface which is > > +acting as the object 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 ) or > > + ( t1 == unlabeled_t )); > > +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 )); > > > > +# the node recvfrom/sendto ops, the recvfrom permission is a "write" > > +operation # because the subject in this particular case is > > the remote > > +domain which is # writing data out the network node which is > > acting as > > +the object mlsconstrain { node } { recvfrom } > > + (( 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 ) or > > + ( 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 )); > > + > > +# the forward ops, the forward_in permission is a "write" operation > > +because the # subject in this particular case is the remote domain > > +which is writing data # to the network with a secmark label, > > the object > > +in this case mlsconstrain { packet } { forward_in 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 ) or > > + ( t1 == unlabeled_t )); > > + > > +# > > +# MLS policy for the secmark and peer controls # > > + > > +# the peer/packet recv op > > +mlsconstrain { peer packet } { recv } > > + (( l1 dom l2 ) or > > + (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or > > + ( t1 == mlsnetread )); > > > > # > > # MLS policy for the process class -- paul moore linux @ hp -- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: paul.moore@hp.com (Paul Moore) Date: Fri, 13 Feb 2009 15:44:42 -0500 Subject: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints In-Reply-To: <170D6ABBBA770349AA49582A86FCED15BA0199@HAVOC.tcs-sec.com> References: <20090212211531.619341973@hp.com> <170D6ABBBA770349AA49582A86FCED15BA0199@HAVOC.tcs-sec.com> Message-ID: <200902131544.42460.paul.moore@hp.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Friday 13 February 2009 02:36:17 pm chanson at trustedcs.com wrote: > Traditionally network objects in a MLS system are not usually subject to > the usual privilege overrides. I would propose something like the below: > > mlsconstrain { netif } { egress ingress } > ((( l1 dom l2 ) and ( l1 domby h2 )) or > ( t1 == mlsnetflow )); > mlsconstrain { node } { recvfrom sendto } > ((( l1 dom l2 ) and ( l1 domby h2 )) or > ( t1 == mlsnetflow )); > mlsconstrain { packet } { forward_in forward_out } > ((( l1 dom l2 ) and ( l1 domby h2 )) or > ( t1 == mlsnetflow )); > > "mlsnetflow" would be a new attribute useful for special cases like > unlabeled_t or kernel_t. Why were network objects not subject to privilege overrides in legacy/traditional MLS systems? I ask because I think we are best off keeping the MLS constraints as consistent as possible. If there is a sound reason for avoiding policy overrides for just the network controls than perhaps we should consider "fixing" the rest of the constraints and not just the new ones. > > -----Original Message----- > > > > Add MLS constraints for several network related access > > controls including the new ingress/egress controls and the > > older Secmark controls. Based on the following post to the > > SELinux Reference Policy mailing list: > > > > * http://oss.tresys.com/pipermail/refpolicy/2009-February/000579.html > > > > Signed-off-by: Paul Moore > > > > --- > > policy/mls | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 51 insertions(+) > > > > Index: refpolicy_svn_repo/policy/mls > > =================================================================== > > --- refpolicy_svn_repo.orig/policy/mls > > +++ refpolicy_svn_repo/policy/mls > > @@ -295,8 +295,59 @@ mlsconstrain { netif node } { tcp_send u > > # these access vectors have no MLS restrictions # node enforce_dest > > > > +# > > +# MLS policy for the network ingress/egress controls # > > > > +# the netif ingress/egress ops, the ingress permission is a "write" > > +operation # because the subject in this particular case is > > the remote > > +domain which is # writing data out the network interface which is > > +acting as the object 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 ) or > > + ( t1 == unlabeled_t )); > > +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 )); > > > > +# the node recvfrom/sendto ops, the recvfrom permission is a "write" > > +operation # because the subject in this particular case is > > the remote > > +domain which is # writing data out the network node which is > > acting as > > +the object mlsconstrain { node } { recvfrom } > > + (( 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 ) or > > + ( 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 )); > > + > > +# the forward ops, the forward_in permission is a "write" operation > > +because the # subject in this particular case is the remote domain > > +which is writing data # to the network with a secmark label, > > the object > > +in this case mlsconstrain { packet } { forward_in 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 ) or > > + ( t1 == unlabeled_t )); > > + > > +# > > +# MLS policy for the secmark and peer controls # > > + > > +# the peer/packet recv op > > +mlsconstrain { peer packet } { recv } > > + (( l1 dom l2 ) or > > + (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or > > + ( t1 == mlsnetread )); > > > > # > > # MLS policy for the process class -- paul moore linux @ hp