From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 06 Oct 2009 09:20:11 -0400
Subject: [refpolicy] [RFC PATCH v1] refpol: Add netif,
 node and peer constraints for MCS based policies
In-Reply-To: <20091001213527.16869.87442.stgit@flek.lan>
References: <20091001213527.16869.87442.stgit@flek.lan>
Message-ID: <1254835214.17694.46.camel@gorn>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Thu, 2009-10-01 at 17:35 -0400, 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 )".

These need to be switched to MCS-specific attributes.

> 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 b8dc0d6..0759021 100644
> --- a/policy/mcs
> +++ b/policy/mcs
> @@ -99,6 +99,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 == mlsnetinbound ) or ( t1 == unlabeled_t ));
> +mlsconstrain { netif } { egress }
> +	(( h1 dom h2 ) or ( t1 == mlsnetoutbound ));
> +
> +# 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 == mlsnetinbound ) or ( t1 == unlabeled_t ));
> +mlsconstrain { node } { sendto }
> +	(( h1 dom h2 ) or ( t1 == mlsnetoutbound ));
> +
> +# 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 == mlsnetinbound ) or ( t1 == unlabeled_t ));
> +mlsconstrain { packet } { forward_out }
> +	(( h1 dom h2 ) or ( t1 == mlsnetoutbound ) 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 == mlsnetread ));
> +
> +#
>  # MCS policy for SELinux-enabled databases
>  #

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150