From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 07 Oct 2009 14:20:17 -0400
Subject: [refpolicy] [RFC PATCH v2] refpol: Add netif,
 node and peer constraints for MCS based policies
In-Reply-To: <20091007172556.3117.39527.stgit@flek.lan>
References: <20091007172556.3117.39527.stgit@flek.lan>
Message-ID: <1254939619.29663.3.camel@gorn>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

> 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
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150