[PATCH] refpolicy: Add missing network related MLS constraints

[PATCH] refpolicy: Add missing network related MLS constraints

[Paul Moore]

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 <paul.moore@hp.com>

---
 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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints

[Paul Moore]

An embedded and charset-unspecified text was scrubbed...
Name: netpeer-constraints
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20090212/5b32db6c/attachment.pl 

RE: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson]

 
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.

-Chad
 

> -----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 <paul.moore@hp.com>
> 
> ---
>  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
> 


--
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson at TrustedCS.com]

 
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.

-Chad
 

> -----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 <paul.moore@hp.com>
> 
> ---
>  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
> 

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Paul Moore]

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 <paul.moore@hp.com>
> >
> > ---
> >  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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Paul Moore]

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 <paul.moore@hp.com>
> >
> > ---
> >  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

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Glenn Faden]

Paul Moore wrote:
> 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.
>   
I can provide a bit of history about some legacy systems. In Trusted 
Solaris 8 there was a privilege, net_mac_read, that allowed a server to 
accept connections from clients with labels it didn't dominate. In order 
to reply, the server either needed to set the socket label to match the 
incoming client's label, or assert the privilege net_reply_equal. There 
was no corresponding net_mac_write privilege, because privilege programs 
were expected to use the network API to set their socket labels 
appropriately.

In Solaris Trusted Extensions, neither the net_mac_read, net_mac_write, 
nor net_repy_equal privileges are implemented. It was viewed as a 
weakness in Trusted Solaris that MAC could be overridden by privilege. 
Instead, the administrator (who configures the system network policy) 
can enumerate multilevel network ports, and appropriately privileged 
services can bind to them.

Since MLS constraints are relatively new to UNIX, there isn't a 
compatibility requirement that the superuser should be able to override 
it. So don't provide any more rope than you need to.

--Glenn

--
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.

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Paul Moore]

On Friday 13 February 2009 04:38:03 pm Glenn Faden wrote:
> Paul Moore wrote:
> > 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.
>
> I can provide a bit of history about some legacy systems. In Trusted
> Solaris 8 there was a privilege, net_mac_read, that allowed a server to
> accept connections from clients with labels it didn't dominate. In order
> to reply, the server either needed to set the socket label to match the
> incoming client's label, or assert the privilege net_reply_equal. There
> was no corresponding net_mac_write privilege, because privilege programs
> were expected to use the network API to set their socket labels
> appropriately.

Thanks, that is good to know.

> In Solaris Trusted Extensions, neither the net_mac_read, net_mac_write,
> nor net_repy_equal privileges are implemented. It was viewed as a
> weakness in Trusted Solaris that MAC could be overridden by privilege.
> Instead, the administrator (who configures the system network policy)
> can enumerate multilevel network ports, and appropriately privileged
> services can bind to them.

I assume by multilevel network ports you are talking about port 
polyinstantiation and not a single (in every sense of the word) port that 
allows a range of labels?

If we assume polyports then I agree that it makes perfect sense to try and 
work around the MLS constraints.  I wonder about some privileged apps but I 
would need to think about that some more.

> Since MLS constraints are relatively new to UNIX, there isn't a
> compatibility requirement that the superuser should be able to override
> it. So don't provide any more rope than you need to.

Well, the MLS constraints aren't all that new to SELinux and several already 
exist in the networking space (the patch above didn't create any new ones, 
just used the existing constraints).  As I understand it, the SELinux 
constraints are also quite different from the TSOL/TX privileges; I'll concede 
that they are both rope, but I think the lengths are quite different ;)

Perhaps I'm missing something but I'm pretty sure that without any form of 
polyports (I highly doubt we will see these anytime soon) we are going to 
need/want network MLS constraint overrides.

-- 
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Paul Moore]

On Friday 13 February 2009 04:38:03 pm Glenn Faden wrote:
> Paul Moore wrote:
> > 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.
>
> I can provide a bit of history about some legacy systems. In Trusted
> Solaris 8 there was a privilege, net_mac_read, that allowed a server to
> accept connections from clients with labels it didn't dominate. In order
> to reply, the server either needed to set the socket label to match the
> incoming client's label, or assert the privilege net_reply_equal. There
> was no corresponding net_mac_write privilege, because privilege programs
> were expected to use the network API to set their socket labels
> appropriately.

Thanks, that is good to know.

> In Solaris Trusted Extensions, neither the net_mac_read, net_mac_write,
> nor net_repy_equal privileges are implemented. It was viewed as a
> weakness in Trusted Solaris that MAC could be overridden by privilege.
> Instead, the administrator (who configures the system network policy)
> can enumerate multilevel network ports, and appropriately privileged
> services can bind to them.

I assume by multilevel network ports you are talking about port 
polyinstantiation and not a single (in every sense of the word) port that 
allows a range of labels?

If we assume polyports then I agree that it makes perfect sense to try and 
work around the MLS constraints.  I wonder about some privileged apps but I 
would need to think about that some more.

> Since MLS constraints are relatively new to UNIX, there isn't a
> compatibility requirement that the superuser should be able to override
> it. So don't provide any more rope than you need to.

Well, the MLS constraints aren't all that new to SELinux and several already 
exist in the networking space (the patch above didn't create any new ones, 
just used the existing constraints).  As I understand it, the SELinux 
constraints are also quite different from the TSOL/TX privileges; I'll concede 
that they are both rope, but I think the lengths are quite different ;)

Perhaps I'm missing something but I'm pretty sure that without any form of 
polyports (I highly doubt we will see these anytime soon) we are going to 
need/want network MLS constraint overrides.

-- 
paul moore
linux @ hp

RE: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson]

You are correct, we want to keep the existing overrides, but not provide
anymore overrides. The network interface / node checking rope should be
very short. The few exceptions of unlabeled_t or kernel_t. kernel_t was
necessary for nfs awhile back (may not be necessary now), probably
iSCSI, or basically things where the kernel is generating the packet
instead of a process and not assuming other credentials.  

-Chad

> 
> > In Solaris Trusted Extensions, neither the net_mac_read, 
> > net_mac_write, nor net_repy_equal privileges are 
> implemented. It was 
> > viewed as a weakness in Trusted Solaris that MAC could be 
> overridden by privilege.
> > Instead, the administrator (who configures the system 
> network policy) 
> > can enumerate multilevel network ports, and appropriately 
> privileged 
> > services can bind to them.
> 
> I assume by multilevel network ports you are talking about 
> port polyinstantiation and not a single (in every sense of 
> the word) port that allows a range of labels?
> 
> If we assume polyports then I agree that it makes perfect 
> sense to try and work around the MLS constraints.  I wonder 
> about some privileged apps but I would need to think about 
> that some more.
> 
> > Since MLS constraints are relatively new to UNIX, there isn't a 
> > compatibility requirement that the superuser should be able to 
> > override it. So don't provide any more rope than you need to.
> 
> Well, the MLS constraints aren't all that new to SELinux and 
> several already exist in the networking space (the patch 
> above didn't create any new ones, just used the existing 
> constraints).  As I understand it, the SELinux constraints 
> are also quite different from the TSOL/TX privileges; I'll 
> concede that they are both rope, but I think the lengths are 
> quite different ;)
> 
> Perhaps I'm missing something but I'm pretty sure that 
> without any form of polyports (I highly doubt we will see 
> these anytime soon) we are going to need/want network MLS 
> constraint overrides.
> 


--
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson at TrustedCS.com]

You are correct, we want to keep the existing overrides, but not provide
anymore overrides. The network interface / node checking rope should be
very short. The few exceptions of unlabeled_t or kernel_t. kernel_t was
necessary for nfs awhile back (may not be necessary now), probably
iSCSI, or basically things where the kernel is generating the packet
instead of a process and not assuming other credentials.  

-Chad

> 
> > In Solaris Trusted Extensions, neither the net_mac_read, 
> > net_mac_write, nor net_repy_equal privileges are 
> implemented. It was 
> > viewed as a weakness in Trusted Solaris that MAC could be 
> overridden by privilege.
> > Instead, the administrator (who configures the system 
> network policy) 
> > can enumerate multilevel network ports, and appropriately 
> privileged 
> > services can bind to them.
> 
> I assume by multilevel network ports you are talking about 
> port polyinstantiation and not a single (in every sense of 
> the word) port that allows a range of labels?
> 
> If we assume polyports then I agree that it makes perfect 
> sense to try and work around the MLS constraints.  I wonder 
> about some privileged apps but I would need to think about 
> that some more.
> 
> > Since MLS constraints are relatively new to UNIX, there isn't a 
> > compatibility requirement that the superuser should be able to 
> > override it. So don't provide any more rope than you need to.
> 
> Well, the MLS constraints aren't all that new to SELinux and 
> several already exist in the networking space (the patch 
> above didn't create any new ones, just used the existing 
> constraints).  As I understand it, the SELinux constraints 
> are also quite different from the TSOL/TX privileges; I'll 
> concede that they are both rope, but I think the lengths are 
> quite different ;)
> 
> Perhaps I'm missing something but I'm pretty sure that 
> without any form of polyports (I highly doubt we will see 
> these anytime soon) we are going to need/want network MLS 
> constraint overrides.
> 

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Paul Moore]

On Friday 13 February 2009 05:17:13 pm chanson@trustedcs.com wrote:
> You are correct, we want to keep the existing overrides, but not provide
> anymore overrides. The network interface / node checking rope should be
> very short. The few exceptions of unlabeled_t or kernel_t. kernel_t was
> necessary for nfs awhile back (may not be necessary now), probably
> iSCSI, or basically things where the kernel is generating the packet
> instead of a process and not assuming other credentials.

Well, I suppose we can take the minimalistic, aka "short rope", approach right 
now since the ingress/egress controls are still new and not really integrated 
into policy in the form of templates.  As we continue to develop the policy 
and we find a need for them we can always [re-]add them.  Unless anyone chimes 
in over the weekend or next Monday I'll respin a patch next week.

Just out of curiosity, are you guys using any of the new stuff or are you 
still using your own special kernel with the rejected network controls?  I ask 
because I would be curious about any feedback you might have on the new bits 
in mainline.

-- 
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Paul Moore]

On Friday 13 February 2009 05:17:13 pm chanson at trustedcs.com wrote:
> You are correct, we want to keep the existing overrides, but not provide
> anymore overrides. The network interface / node checking rope should be
> very short. The few exceptions of unlabeled_t or kernel_t. kernel_t was
> necessary for nfs awhile back (may not be necessary now), probably
> iSCSI, or basically things where the kernel is generating the packet
> instead of a process and not assuming other credentials.

Well, I suppose we can take the minimalistic, aka "short rope", approach right 
now since the ingress/egress controls are still new and not really integrated 
into policy in the form of templates.  As we continue to develop the policy 
and we find a need for them we can always [re-]add them.  Unless anyone chimes 
in over the weekend or next Monday I'll respin a patch next week.

Just out of curiosity, are you guys using any of the new stuff or are you 
still using your own special kernel with the rejected network controls?  I ask 
because I would be curious about any feedback you might have on the new bits 
in mainline.

-- 
paul moore
linux @ hp

RE: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson]

 
> 
> Just out of curiosity, are you guys using any of the new 
> stuff or are you still using your own special kernel with the 
> rejected network controls?  I ask because I would be curious 
> about any feedback you might have on the new bits in mainline.
> 

We can't really use anything new since we use the same baseline for
multiple products, each of which may go through multiple accreditations,
some of which are much stricter than others as to changed content.
Therefore, we continue to use our patch on the approved baseline which
adds the same basic ideas as the mainline enhancements.

-Chad 


--
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson at TrustedCS.com]

 
> 
> Just out of curiosity, are you guys using any of the new 
> stuff or are you still using your own special kernel with the 
> rejected network controls?  I ask because I would be curious 
> about any feedback you might have on the new bits in mainline.
> 

We can't really use anything new since we use the same baseline for
multiple products, each of which may go through multiple accreditations,
some of which are much stricter than others as to changed content.
Therefore, we continue to use our patch on the approved baseline which
adds the same basic ideas as the mainline enhancements.

-Chad 

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Glenn Faden]

Paul Moore wrote:
> On Friday 13 February 2009 04:38:03 pm Glenn Faden wrote:
>   
>> Paul Moore wrote:
>>     
>>> 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.
>>>       
>> I can provide a bit of history about some legacy systems. In Trusted
>> Solaris 8 there was a privilege, net_mac_read, that allowed a server to
>> accept connections from clients with labels it didn't dominate. In order
>> to reply, the server either needed to set the socket label to match the
>> incoming client's label, or assert the privilege net_reply_equal. There
>> was no corresponding net_mac_write privilege, because privilege programs
>> were expected to use the network API to set their socket labels
>> appropriately.
>>     
>
> Thanks, that is good to know.
>
>   
>> In Solaris Trusted Extensions, neither the net_mac_read, net_mac_write,
>> nor net_repy_equal privileges are implemented. It was viewed as a
>> weakness in Trusted Solaris that MAC could be overridden by privilege.
>> Instead, the administrator (who configures the system network policy)
>> can enumerate multilevel network ports, and appropriately privileged
>> services can bind to them.
>>     
>
> I assume by multilevel network ports you are talking about port 
> polyinstantiation and not a single (in every sense of the word) port that 
> allows a range of labels?
>   
Our terminology is different. Polyinstantiated ports are virtualized so 
that a single-level instance appears to exist at each label. Multilevel 
ports are TCB objects which can be used by privileged subjects to accept 
packets within an explicitly enumerated range of set of labels, 
determined by the administrator.
> If we assume polyports then I agree that it makes perfect sense to try and 
> work around the MLS constraints.  I wonder about some privileged apps but I 
> would need to think about that some more.
>   
An example of such a privileged application is Xorg.
>   
>> Since MLS constraints are relatively new to UNIX, there isn't a
>> compatibility requirement that the superuser should be able to override
>> it. So don't provide any more rope than you need to.
>>     
>
> Well, the MLS constraints aren't all that new to SELinux and several already 
> exist in the networking space (the patch above didn't create any new ones, 
> just used the existing constraints).  As I understand it, the SELinux 
> constraints are also quite different from the TSOL/TX privileges; I'll concede 
> that they are both rope, but I think the lengths are quite different ;)
>   
Agreed.
> Perhaps I'm missing something but I'm pretty sure that without any form of 
> polyports (I highly doubt we will see these anytime soon) we are going to 
> need/want network MLS constraint overrides.
>
>   
You'll need overrides, but probably not based on Posix capabilities.

--Glenn


--
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.

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Paul Moore]

On Friday 13 February 2009 05:24:16 pm Glenn Faden wrote:
> Paul Moore wrote:
> > On Friday 13 February 2009 04:38:03 pm Glenn Faden wrote:
> >> Paul Moore wrote:
> >>> 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.
> >>
> >> I can provide a bit of history about some legacy systems. In Trusted
> >> Solaris 8 there was a privilege, net_mac_read, that allowed a server to
> >> accept connections from clients with labels it didn't dominate. In order
> >> to reply, the server either needed to set the socket label to match the
> >> incoming client's label, or assert the privilege net_reply_equal. There
> >> was no corresponding net_mac_write privilege, because privilege programs
> >> were expected to use the network API to set their socket labels
> >> appropriately.
> >
> > Thanks, that is good to know.
> >
> >> In Solaris Trusted Extensions, neither the net_mac_read, net_mac_write,
> >> nor net_repy_equal privileges are implemented. It was viewed as a
> >> weakness in Trusted Solaris that MAC could be overridden by privilege.
> >> Instead, the administrator (who configures the system network policy)
> >> can enumerate multilevel network ports, and appropriately privileged
> >> services can bind to them.
> >
> > I assume by multilevel network ports you are talking about port
> > polyinstantiation and not a single (in every sense of the word) port that
> > allows a range of labels?
>
> Our terminology is different. Polyinstantiated ports are virtualized so
> that a single-level instance appears to exist at each label. Multilevel
> ports are TCB objects which can be used by privileged subjects to accept
> packets within an explicitly enumerated range of set of labels,
> determined by the administrator.

I thought that might be the case, glad to have that clarified.

In the case of SELinux, actually Linux in general, we don't have the polyport 
concept so we have to make so with multilevel ports and trusted applications.  
The label aware xinetd setup is about the closest we can get to faking 
polyport on Linux right now.  Interesting enough, even with SELinux's 
multilevel ports you still need a MLS constraint exception if the traffic's 
effective label does not equal the receiving socket's effective label.

-- 
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.

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[Casey Schaufler]

chanson@TrustedCS.com wrote:
>  
> Traditionally network objects in a MLS system are not usually subject to
> the usual privilege overrides.
Hum. That wasn't true of Trusted Irix where sockets were the network
objects.
Of course, you can only apply privilege on the sending end because the
privilege state isn't transmitted.

On Smack the network object is the process, and privilege is required to
muck with the attributes of your own sockets, but otherwise it's the same,
again the privilege isn't getting transmitted, so you can't determine if
it's there on the other end.

If you want to transmit the privilege state, and SELinux (appears to)
allow that, you really ought to allow for that on the other end.


--
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.

RE: [refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson]

 
I realized I was imprecise in my description of "network object" when
writing this. I was more specifically referring to enforcement of
"Network / Host Level Access Decisions" of packets entering/exiting the
system. I concur that Trusted OSes have allowed trusted processes to
change socket attributes, such as labels, or read higher level data as
Glenn and you have mentioned. This coincides with the existing MLS
networking overrides in the MLS constraints today.

-Chad

> -----Original Message-----
> From: Casey Schaufler [mailto:casey@schaufler-ca.com] 
> 
> chanson@TrustedCS.com wrote:
> > Traditionally network objects in a MLS system are not 
> usually subject 
> > to the usual privilege overrides.
> Hum. That wasn't true of Trusted Irix where sockets were the 
> network objects.
> Of course, you can only apply privilege on the sending end 
> because the privilege state isn't transmitted.
> 
> On Smack the network object is the process, and privilege is 
> required to muck with the attributes of your own sockets, but 
> otherwise it's the same, again the privilege isn't getting 
> transmitted, so you can't determine if it's there on the other end.
> 
> If you want to transmit the privilege state, and SELinux 
> (appears to) allow that, you really ought to allow for that 
> on the other end. 


--
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLSconstraints

[chanson at TrustedCS.com]

 
I realized I was imprecise in my description of "network object" when
writing this. I was more specifically referring to enforcement of
"Network / Host Level Access Decisions" of packets entering/exiting the
system. I concur that Trusted OSes have allowed trusted processes to
change socket attributes, such as labels, or read higher level data as
Glenn and you have mentioned. This coincides with the existing MLS
networking overrides in the MLS constraints today.

-Chad

> -----Original Message-----
> From: Casey Schaufler [mailto:casey at schaufler-ca.com] 
> 
> chanson at TrustedCS.com wrote:
> > Traditionally network objects in a MLS system are not 
> usually subject 
> > to the usual privilege overrides.
> Hum. That wasn't true of Trusted Irix where sockets were the 
> network objects.
> Of course, you can only apply privilege on the sending end 
> because the privilege state isn't transmitted.
> 
> On Smack the network object is the process, and privilege is 
> required to muck with the attributes of your own sockets, but 
> otherwise it's the same, again the privilege isn't getting 
> transmitted, so you can't determine if it's there on the other end.
> 
> If you want to transmit the privilege state, and SELinux 
> (appears to) allow that, you really ought to allow for that 
> on the other end. 

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints

[Joe Nall]

On Feb 12, 2009, at 3:15 PM, Paul Moore wrote:

> 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 <paul.moore@hp.com>
>
> ---
> 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 ));

How do processes talk to each other on local netlabel interfaces? lo  
for example is s0-s15:c1.c1023, any process above s0 would fail the  
test above communicating on localhost. I don't think that was the  
intent.

type=AVC msg=audit(1235141104.160:134): avc:  denied  { egress } for   
pid=2980 comm="InputLog" saddr=172.16.142.134 src=10308  
daddr=172.16.142.134 dest=52831 netif=lo  
scontext=system_u:system_r:jcdx_icm_t:s6:c0.c511  
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
type=AVC msg=audit(1235141104.160:134): avc:  denied  { sendto } for   
pid=2980 comm="InputLog" saddr=172.16.142.134 src=10308  
daddr=172.16.142.134 dest=52831 netif=lo  
scontext=system_u:system_r:jcdx_icm_t:s6:c0.c511  
tcontext=system_u:object_r:node_t:s0-s15:c0.c1023 tclass=node

type=AVC msg=audit(1235177156.260:499): avc:  denied  { ingress } for   
pid=2923 comm="QManager" saddr=172.16.142.134 src=8998  
daddr=172.16.142.134 dest=34245 netif=lo  
scontext=system_u:system_r:jcdx_qm_t:s15:c0.c1023  
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
type=AVC msg=audit(1235177156.260:499): avc:  denied  { recvfrom }  
for  pid=2923 comm="QManager" saddr=172.16.142.134 src=8998  
daddr=172.16.142.134 dest=34245 netif=lo  
scontext=system_u:system_r:jcdx_qm_t:s15:c0.c1023  
tcontext=system_u:object_r:node_t:s0-s15:c0.c1023 tclass=node

I have avcs like the ones above for every pair of processes that are  
using IP to connect to each other after applying the patch.

where 172.16.142.134 is:
# netlabelctl -p map list
Configured NetLabel domain mappings (1)
  domain: DEFAULT
    address: 127.0.0.1/32
     protocol: CIPSOv4, DOI = 2
    address: 172.16.142.134/32
     protocol: CIPSOv4, DOI = 2
    address: 0.0.0.0/0
     protocol: UNLABELED

joe


>
>
> +# 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
>
> _______________________________________________
> refpolicy mailing list
> refpolicy@oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


--
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints

[Joe Nall]

On Feb 12, 2009, at 3:15 PM, Paul Moore wrote:

> 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 <paul.moore@hp.com>
>
> ---
> 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 ));

How do processes talk to each other on local netlabel interfaces? lo  
for example is s0-s15:c1.c1023, any process above s0 would fail the  
test above communicating on localhost. I don't think that was the  
intent.

type=AVC msg=audit(1235141104.160:134): avc:  denied  { egress } for   
pid=2980 comm="InputLog" saddr=172.16.142.134 src=10308  
daddr=172.16.142.134 dest=52831 netif=lo  
scontext=system_u:system_r:jcdx_icm_t:s6:c0.c511  
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
type=AVC msg=audit(1235141104.160:134): avc:  denied  { sendto } for   
pid=2980 comm="InputLog" saddr=172.16.142.134 src=10308  
daddr=172.16.142.134 dest=52831 netif=lo  
scontext=system_u:system_r:jcdx_icm_t:s6:c0.c511  
tcontext=system_u:object_r:node_t:s0-s15:c0.c1023 tclass=node

type=AVC msg=audit(1235177156.260:499): avc:  denied  { ingress } for   
pid=2923 comm="QManager" saddr=172.16.142.134 src=8998  
daddr=172.16.142.134 dest=34245 netif=lo  
scontext=system_u:system_r:jcdx_qm_t:s15:c0.c1023  
tcontext=system_u:object_r:lo_netif_t:s0-s15:c0.c1023 tclass=netif
type=AVC msg=audit(1235177156.260:499): avc:  denied  { recvfrom }  
for  pid=2923 comm="QManager" saddr=172.16.142.134 src=8998  
daddr=172.16.142.134 dest=34245 netif=lo  
scontext=system_u:system_r:jcdx_qm_t:s15:c0.c1023  
tcontext=system_u:object_r:node_t:s0-s15:c0.c1023 tclass=node

I have avcs like the ones above for every pair of processes that are  
using IP to connect to each other after applying the patch.

where 172.16.142.134 is:
# netlabelctl -p map list
Configured NetLabel domain mappings (1)
  domain: DEFAULT
    address: 127.0.0.1/32
     protocol: CIPSOv4, DOI = 2
    address: 172.16.142.134/32
     protocol: CIPSOv4, DOI = 2
    address: 0.0.0.0/0
     protocol: UNLABELED

joe


>
>
> +# 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
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

Re: [refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints

[Paul Moore]

On Friday 20 February 2009 08:37:30 pm Joe Nall wrote:
> How do processes talk to each other on local netlabel interfaces? lo
> for example is s0-s15:c1.c1023, any process above s0 would fail the
> test above communicating on localhost. I don't think that was the
> intent.

I suppose first things first: did you see the new patch posted on Friday 
(February 20th)?  It changed the constraints quite a bit based on feedback on 
the lists.  Please take a look at that patch and see if it looks okay to you, 
if not please yell loudly :)

-- 
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.

[refpolicy] [PATCH] refpolicy: Add missing network related MLS constraints

[Paul Moore]

On Friday 20 February 2009 08:37:30 pm Joe Nall wrote:
> How do processes talk to each other on local netlabel interfaces? lo
> for example is s0-s15:c1.c1023, any process above s0 would fail the
> test above communicating on localhost. I don't think that was the
> intent.

I suppose first things first: did you see the new patch posted on Friday 
(February 20th)?  It changed the constraints quite a bit based on feedback on 
the lists.  Please take a look at that patch and see if it looks okay to you, 
if not please yell loudly :)

-- 
paul moore
linux @ hp