From: paul.moore@hp.com (Paul Moore)
Date: Wed, 7 Oct 2009 16:30:36 -0400
Subject: [refpolicy] [RFC PATCH v2] refpol: Add netif,
	node and peer constraints for MCS based policies
In-Reply-To: <1254939619.29663.3.camel@gorn>
References: <20091007172556.3117.39527.stgit@flek.lan>
	<1254939619.29663.3.camel@gorn>
Message-ID: <200910072030.36504.paul.moore@hp.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wednesday 07 October 2009 06:20:17 pm Christopher J. PeBenito wrote:
> On Wed, 2009-10-07 at 17:25 +0000, Paul Moore wrote:
> > Adapt the MLS netif, node and peer networking constraints for MCS.  This
> > patch preserves the basic structure of the MLS constraints and converts
> > them to use the MCS model which means the "(( l1 dom l2 ) and ( l1 domby
> > h2 ))" constraints are converted to "( h1 dom h2 )".
> 
> It still needs the attribute declarations, along with interfaces for
> each of them.

Ah yes, of course it does ...

> > Signed-of-by: Paul Moore <paul.moore@hp.com>
> > ---
> >
> >  policy/mcs |   36 ++++++++++++++++++++++++++++++++++++
> >  1 files changed, 36 insertions(+), 0 deletions(-)
> >
> > diff --git a/policy/mcs b/policy/mcs
> > index af90ef2..5aedab8 100644
> > --- a/policy/mcs
> > +++ b/policy/mcs
> > @@ -102,6 +102,42 @@ mlsconstrain process { sigkill sigstop }
> >  	(( h1 dom h2 ) or ( t1 == mcskillall ));
> >
> >  #
> > +# MCS 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 }
> > +	(( h1 dom h2 ) or ( t1 == mcsnetinbound ) or ( t1 == unlabeled_t ));
> > +mlsconstrain { netif } { egress }
> > +	(( h1 dom h2 ) or ( t1 == mcsnetoutbound ));
> > +
> > +# 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 }
> > +	(( h1 dom h2 ) or ( t1 == mcsnetinbound ) or ( t1 == unlabeled_t ));
> > +mlsconstrain { node } { sendto }
> > +	(( h1 dom h2 ) or ( t1 == mcsnetoutbound ));
> > +
> > +# 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 }
> > +	(( h1 dom h2 ) or ( t1 == mcsnetinbound ) or ( t1 == unlabeled_t ));
> > +mlsconstrain { packet } { forward_out }
> > +	(( h1 dom h2 ) or ( t1 == mcsnetoutbound ) or ( t1 == unlabeled_t ));
> > +
> > +#
> > +# MCS policy for the secmark and peer controls
> > +#
> > +
> > +# the peer/packet recv op
> > +mlsconstrain { peer packet } { recv }
> > +	(( h1 dom h2 ) or ( t1 == mcsnetread ));
> > +
> > +#
> >  # MCS policy for SELinux-enabled databases
> >  #
> >
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> 

-- 
paul moore
linux @ hp