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 <[email protected]>
>
> ---
> 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
>
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 <[email protected]>
> >
> > ---
> > 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