All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] refpolicy: Add missing network related MLS constraints
@ 2009-02-20 22:02 ` Paul Moore
  0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2009-02-20 22:02 UTC (permalink / raw)
  To: selinux, refpolicy; +Cc: 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                   |   45 +++++++++++++++++++++++++++++++++++++++++++
 policy/modules/kernel/mls.if |   42 ++++++++++++++++++++++++++++++++++++++++
 policy/modules/kernel/mls.te |    2 +
 3 files changed, 89 insertions(+)

Index: refpolicy_svn_repo/policy/mls
===================================================================
--- refpolicy_svn_repo.orig/policy/mls
+++ refpolicy_svn_repo/policy/mls
@@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
+	 ( t1 == mlsnetinbound ) or
+	 ( t1 == unlabeled_t ));
+mlsconstrain { netif } { egress }
+	((( l1 dom l2 ) and ( l1 domby 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 }
+	((( l1 dom l2 ) and ( l1 domby h2 )) or
+	 ( t1 == mlsnetinbound ) or
+	 ( t1 == unlabeled_t ));
+mlsconstrain { node } { sendto }
+	((( l1 dom l2 ) and ( l1 domby 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 }
+	((( l1 dom l2 ) and ( l1 domby h2 )) or
+	 ( t1 == mlsnetinbound ) or
+	 ( t1 == unlabeled_t ));
+mlsconstrain { packet } { forward_out }
+	((( l1 dom l2 ) and ( l1 domby h2 )) or
+	 ( t1 == mlsnetoutbound ) 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
Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
===================================================================
--- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
+++ refpolicy_svn_repo/policy/modules/kernel/mls.if
@@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
 
 ########################################
 ## <summary>
+##	Make specified domain trusted to
+##	write inbound packets regardless of the
+##	network's or node's MLS range.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`mls_net_inbound_all_levels',`
+	gen_require(`
+		attribute mlsnetinbound;
+	')
+
+	typeattribute $1 mlsnetinbound;
+')
+
+########################################
+## <summary>
+##	Make specified domain trusted to
+##	write outbound packets regardless of the
+##	network's or node's MLS range.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`mls_net_outbound_all_levels',`
+	gen_require(`
+		attribute mlsnetoutbound;
+	')
+
+	typeattribute $1 mlsnetoutbound;
+')
+
+########################################
+## <summary>
 ##	Make specified domain MLS trusted
 ##	for reading from System V IPC objects
 ##	up to its clearance.
Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
===================================================================
--- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
+++ refpolicy_svn_repo/policy/modules/kernel/mls.te
@@ -22,6 +22,8 @@ attribute mlsnetwriteranged;
 attribute mlsnetupgrade;
 attribute mlsnetdowngrade;
 attribute mlsnetrecvall;
+attribute mlsnetinbound;
+attribute mlsnetoutbound;
 
 attribute mlsipcread;
 attribute mlsipcreadtoclr;

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [refpolicy] [PATCH v2] refpolicy: Add missing network related MLS constraints
@ 2009-02-20 22:02 ` Paul Moore
  0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2009-02-20 22:02 UTC (permalink / raw)
  To: refpolicy

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: [refpolicy] [PATCH v2] refpolicy: Add missing network related MLSconstraints
  2009-02-20 22:02 ` [refpolicy] " Paul Moore
@ 2009-02-24 15:11   ` chanson at TrustedCS.com
  -1 siblings, 0 replies; 10+ messages in thread
From: chanson @ 2009-02-24 15:11 UTC (permalink / raw)
  To: paul.moore, selinux, refpolicy

Hi Paul,

Is there any reason we can't utilize the new interfaces to handle the
unlabeled_t lines in the constraints? I'm not a real big fan of putting
direct types into the constraints.

-Chad 

> -----Original Message-----
> From: refpolicy-bounces@oss.tresys.com 
> [mailto:refpolicy-bounces@oss.tresys.com] On Behalf Of Paul Moore
> Sent: Friday, February 20, 2009 4:03 PM
> To: selinux@tycho.nsa.gov; refpolicy@oss.tresys.com
> Subject: [refpolicy] [PATCH v2] refpolicy: Add missing 
> network related MLSconstraints
> 
> 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                   |   45 
> +++++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.if |   42 
> ++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.te |    2 +
>  3 files changed, 89 insertions(+)
> 
> Index: refpolicy_svn_repo/policy/mls
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/mls
> +++ refpolicy_svn_repo/policy/mls
> @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { netif } { egress }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { node } { sendto }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { packet } { forward_out }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetoutbound ) 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
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
>  
>  ########################################
>  ## <summary>
> +##	Make specified domain trusted to
> +##	write inbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_inbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetinbound;
> +	')
> +
> +	typeattribute $1 mlsnetinbound;
> +')
> +
> +########################################
> +## <summary>
> +##	Make specified domain trusted to
> +##	write outbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_outbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetoutbound;
> +	')
> +
> +	typeattribute $1 mlsnetoutbound;
> +')
> +
> +########################################
> +## <summary>
>  ##	Make specified domain MLS trusted
>  ##	for reading from System V IPC objects
>  ##	up to its clearance.
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;  attribute 
> mlsnetupgrade;  attribute mlsnetdowngrade;  attribute mlsnetrecvall;
> +attribute mlsnetinbound;
> +attribute mlsnetoutbound;
>  
>  attribute mlsipcread;
>  attribute mlsipcreadtoclr;
> 
> --
> 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [refpolicy] [PATCH v2] refpolicy: Add missing network related MLSconstraints
@ 2009-02-24 15:11   ` chanson at TrustedCS.com
  0 siblings, 0 replies; 10+ messages in thread
From: chanson at TrustedCS.com @ 2009-02-24 15:11 UTC (permalink / raw)
  To: refpolicy

Hi Paul,

Is there any reason we can't utilize the new interfaces to handle the
unlabeled_t lines in the constraints? I'm not a real big fan of putting
direct types into the constraints.

-Chad 

> -----Original Message-----
> From: refpolicy-bounces at oss.tresys.com 
> [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Paul Moore
> Sent: Friday, February 20, 2009 4:03 PM
> To: selinux at tycho.nsa.gov; refpolicy at oss.tresys.com
> Subject: [refpolicy] [PATCH v2] refpolicy: Add missing 
> network related MLSconstraints
> 
> 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                   |   45 
> +++++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.if |   42 
> ++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.te |    2 +
>  3 files changed, 89 insertions(+)
> 
> Index: refpolicy_svn_repo/policy/mls
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/mls
> +++ refpolicy_svn_repo/policy/mls
> @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { netif } { egress }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { node } { sendto }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { packet } { forward_out }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetoutbound ) 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
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
>  
>  ########################################
>  ## <summary>
> +##	Make specified domain trusted to
> +##	write inbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_inbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetinbound;
> +	')
> +
> +	typeattribute $1 mlsnetinbound;
> +')
> +
> +########################################
> +## <summary>
> +##	Make specified domain trusted to
> +##	write outbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_outbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetoutbound;
> +	')
> +
> +	typeattribute $1 mlsnetoutbound;
> +')
> +
> +########################################
> +## <summary>
>  ##	Make specified domain MLS trusted
>  ##	for reading from System V IPC objects
>  ##	up to its clearance.
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;  attribute 
> mlsnetupgrade;  attribute mlsnetdowngrade;  attribute mlsnetrecvall;
> +attribute mlsnetinbound;
> +attribute mlsnetoutbound;
>  
>  attribute mlsipcread;
>  attribute mlsipcreadtoclr;
> 
> --
> paul moore
> linux @ hp
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [refpolicy] [PATCH v2] refpolicy: Add missing network related MLSconstraints
  2009-02-24 15:11   ` chanson at TrustedCS.com
@ 2009-02-24 15:33     ` Paul Moore
  -1 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2009-02-24 15:33 UTC (permalink / raw)
  To: chanson; +Cc: selinux, refpolicy

On Tuesday 24 February 2009 10:11:56 am chanson@trustedcs.com wrote:
> Hi Paul,
>
> Is there any reason we can't utilize the new interfaces to handle the
> unlabeled_t lines in the constraints? I'm not a real big fan of putting
> direct types into the constraints.

Convention and consistency with the other network constraints.  I suppose this 
is really a judgment call because what is the real difference between using 
direct types and simply loading up the types with the MLS 
overrides/attributes?  The "unlabeled_t" type really is special and it seems 
cleaner to me to use it directly in the constraints rather than adding a bunch 
of attributes to it.

> > -----Original Message-----
> > From: refpolicy-bounces@oss.tresys.com
> > [mailto:refpolicy-bounces@oss.tresys.com] On Behalf Of Paul Moore
> > Sent: Friday, February 20, 2009 4:03 PM
> > To: selinux@tycho.nsa.gov; refpolicy@oss.tresys.com
> > Subject: [refpolicy] [PATCH v2] refpolicy: Add missing
> > network related MLSconstraints
> >
> > 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                   |   45
> > +++++++++++++++++++++++++++++++++++++++++++
> >  policy/modules/kernel/mls.if |   42
> > ++++++++++++++++++++++++++++++++++++++++
> >  policy/modules/kernel/mls.te |    2 +
> >  3 files changed, 89 insertions(+)
> >
> > Index: refpolicy_svn_repo/policy/mls
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/mls
> > +++ refpolicy_svn_repo/policy/mls
> > @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetinbound ) or
> > +	 ( t1 == unlabeled_t ));
> > +mlsconstrain { netif } { egress }
> > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetinbound ) or
> > +	 ( t1 == unlabeled_t ));
> > +mlsconstrain { node } { sendto }
> > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetinbound ) or
> > +	 ( t1 == unlabeled_t ));
> > +mlsconstrain { packet } { forward_out }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetoutbound ) 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
> > Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> > +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> > @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
> >
> >  ########################################
> >  ## <summary>
> > +##	Make specified domain trusted to
> > +##	write inbound packets regardless of the
> > +##	network's or node's MLS range.
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`mls_net_inbound_all_levels',`
> > +	gen_require(`
> > +		attribute mlsnetinbound;
> > +	')
> > +
> > +	typeattribute $1 mlsnetinbound;
> > +')
> > +
> > +########################################
> > +## <summary>
> > +##	Make specified domain trusted to
> > +##	write outbound packets regardless of the
> > +##	network's or node's MLS range.
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`mls_net_outbound_all_levels',`
> > +	gen_require(`
> > +		attribute mlsnetoutbound;
> > +	')
> > +
> > +	typeattribute $1 mlsnetoutbound;
> > +')
> > +
> > +########################################
> > +## <summary>
> >  ##	Make specified domain MLS trusted
> >  ##	for reading from System V IPC objects
> >  ##	up to its clearance.
> > Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> > +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> > @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;  attribute
> > mlsnetupgrade;  attribute mlsnetdowngrade;  attribute mlsnetrecvall;
> > +attribute mlsnetinbound;
> > +attribute mlsnetoutbound;
> >
> >  attribute mlsipcread;
> >  attribute mlsipcreadtoclr;
> >
> > --
> > paul moore
> > linux @ hp
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy@oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [refpolicy] [PATCH v2] refpolicy: Add missing network related MLSconstraints
@ 2009-02-24 15:33     ` Paul Moore
  0 siblings, 0 replies; 10+ messages in thread
From: Paul Moore @ 2009-02-24 15:33 UTC (permalink / raw)
  To: refpolicy

On Tuesday 24 February 2009 10:11:56 am chanson at trustedcs.com wrote:
> Hi Paul,
>
> Is there any reason we can't utilize the new interfaces to handle the
> unlabeled_t lines in the constraints? I'm not a real big fan of putting
> direct types into the constraints.

Convention and consistency with the other network constraints.  I suppose this 
is really a judgment call because what is the real difference between using 
direct types and simply loading up the types with the MLS 
overrides/attributes?  The "unlabeled_t" type really is special and it seems 
cleaner to me to use it directly in the constraints rather than adding a bunch 
of attributes to it.

> > -----Original Message-----
> > From: refpolicy-bounces at oss.tresys.com
> > [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Paul Moore
> > Sent: Friday, February 20, 2009 4:03 PM
> > To: selinux at tycho.nsa.gov; refpolicy at oss.tresys.com
> > Subject: [refpolicy] [PATCH v2] refpolicy: Add missing
> > network related MLSconstraints
> >
> > 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                   |   45
> > +++++++++++++++++++++++++++++++++++++++++++
> >  policy/modules/kernel/mls.if |   42
> > ++++++++++++++++++++++++++++++++++++++++
> >  policy/modules/kernel/mls.te |    2 +
> >  3 files changed, 89 insertions(+)
> >
> > Index: refpolicy_svn_repo/policy/mls
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/mls
> > +++ refpolicy_svn_repo/policy/mls
> > @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetinbound ) or
> > +	 ( t1 == unlabeled_t ));
> > +mlsconstrain { netif } { egress }
> > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetinbound ) or
> > +	 ( t1 == unlabeled_t ));
> > +mlsconstrain { node } { sendto }
> > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetinbound ) or
> > +	 ( t1 == unlabeled_t ));
> > +mlsconstrain { packet } { forward_out }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t1 == mlsnetoutbound ) 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
> > Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> > +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> > @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
> >
> >  ########################################
> >  ## <summary>
> > +##	Make specified domain trusted to
> > +##	write inbound packets regardless of the
> > +##	network's or node's MLS range.
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`mls_net_inbound_all_levels',`
> > +	gen_require(`
> > +		attribute mlsnetinbound;
> > +	')
> > +
> > +	typeattribute $1 mlsnetinbound;
> > +')
> > +
> > +########################################
> > +## <summary>
> > +##	Make specified domain trusted to
> > +##	write outbound packets regardless of the
> > +##	network's or node's MLS range.
> > +## </summary>
> > +## <param name="domain">
> > +##	<summary>
> > +##	Domain allowed access.
> > +##	</summary>
> > +## </param>
> > +## <rolecap/>
> > +#
> > +interface(`mls_net_outbound_all_levels',`
> > +	gen_require(`
> > +		attribute mlsnetoutbound;
> > +	')
> > +
> > +	typeattribute $1 mlsnetoutbound;
> > +')
> > +
> > +########################################
> > +## <summary>
> >  ##	Make specified domain MLS trusted
> >  ##	for reading from System V IPC objects
> >  ##	up to its clearance.
> > Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> > +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> > @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;  attribute
> > mlsnetupgrade;  attribute mlsnetdowngrade;  attribute mlsnetrecvall;
> > +attribute mlsnetinbound;
> > +attribute mlsnetoutbound;
> >
> >  attribute mlsipcread;
> >  attribute mlsipcreadtoclr;
> >
> > --
> > paul moore
> > linux @ hp
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
paul moore
linux @ hp

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [refpolicy] [PATCH v2] refpolicy: Add missing network related MLSconstraints
  2009-02-24 15:33     ` Paul Moore
@ 2009-02-24 16:06       ` Christopher J. PeBenito
  -1 siblings, 0 replies; 10+ messages in thread
From: Christopher J. PeBenito @ 2009-02-24 16:06 UTC (permalink / raw)
  To: Paul Moore; +Cc: chanson, refpolicy, selinux

On Tue, 2009-02-24 at 10:33 -0500, Paul Moore wrote:
> On Tuesday 24 February 2009 10:11:56 am chanson@trustedcs.com wrote:
> > Hi Paul,
> >
> > Is there any reason we can't utilize the new interfaces to handle the
> > unlabeled_t lines in the constraints? I'm not a real big fan of putting
> > direct types into the constraints.
> 
> Convention and consistency with the other network constraints.  I suppose this 
> is really a judgment call because what is the real difference between using 
> direct types and simply loading up the types with the MLS 
> overrides/attributes?  The "unlabeled_t" type really is special and it seems 
> cleaner to me to use it directly in the constraints rather than adding a bunch 
> of attributes to it.

There would also be a behavior change with the netif:egress and
node:sendto permissions.  Though I'm not sure it would matter in this
case, I don't think doing something similar for the other two
constraints that currently have explicit unlabeled_t references would
work.  I'm fine with the explicit references for now.  If someone can
make a patch that removes all the explicit references in a reasonable
way, then I'd be interested.

> > > -----Original Message-----
> > > From: refpolicy-bounces@oss.tresys.com
> > > [mailto:refpolicy-bounces@oss.tresys.com] On Behalf Of Paul Moore
> > > Sent: Friday, February 20, 2009 4:03 PM
> > > To: selinux@tycho.nsa.gov; refpolicy@oss.tresys.com
> > > Subject: [refpolicy] [PATCH v2] refpolicy: Add missing
> > > network related MLSconstraints
> > >
> > > 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                   |   45
> > > +++++++++++++++++++++++++++++++++++++++++++
> > >  policy/modules/kernel/mls.if |   42
> > > ++++++++++++++++++++++++++++++++++++++++
> > >  policy/modules/kernel/mls.te |    2 +
> > >  3 files changed, 89 insertions(+)
> > >
> > > Index: refpolicy_svn_repo/policy/mls
> > > ===================================================================
> > > --- refpolicy_svn_repo.orig/policy/mls
> > > +++ refpolicy_svn_repo/policy/mls
> > > @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetinbound ) or
> > > +	 ( t1 == unlabeled_t ));
> > > +mlsconstrain { netif } { egress }
> > > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetinbound ) or
> > > +	 ( t1 == unlabeled_t ));
> > > +mlsconstrain { node } { sendto }
> > > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetinbound ) or
> > > +	 ( t1 == unlabeled_t ));
> > > +mlsconstrain { packet } { forward_out }
> > > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetoutbound ) 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
> > > Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> > > ===================================================================
> > > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> > > +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> > > @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
> > >
> > >  ########################################
> > >  ## <summary>
> > > +##	Make specified domain trusted to
> > > +##	write inbound packets regardless of the
> > > +##	network's or node's MLS range.
> > > +## </summary>
> > > +## <param name="domain">
> > > +##	<summary>
> > > +##	Domain allowed access.
> > > +##	</summary>
> > > +## </param>
> > > +## <rolecap/>
> > > +#
> > > +interface(`mls_net_inbound_all_levels',`
> > > +	gen_require(`
> > > +		attribute mlsnetinbound;
> > > +	')
> > > +
> > > +	typeattribute $1 mlsnetinbound;
> > > +')
> > > +
> > > +########################################
> > > +## <summary>
> > > +##	Make specified domain trusted to
> > > +##	write outbound packets regardless of the
> > > +##	network's or node's MLS range.
> > > +## </summary>
> > > +## <param name="domain">
> > > +##	<summary>
> > > +##	Domain allowed access.
> > > +##	</summary>
> > > +## </param>
> > > +## <rolecap/>
> > > +#
> > > +interface(`mls_net_outbound_all_levels',`
> > > +	gen_require(`
> > > +		attribute mlsnetoutbound;
> > > +	')
> > > +
> > > +	typeattribute $1 mlsnetoutbound;
> > > +')
> > > +
> > > +########################################
> > > +## <summary>
> > >  ##	Make specified domain MLS trusted
> > >  ##	for reading from System V IPC objects
> > >  ##	up to its clearance.
> > > Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> > > ===================================================================
> > > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> > > +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> > > @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;  attribute
> > > mlsnetupgrade;  attribute mlsnetdowngrade;  attribute mlsnetrecvall;
> > > +attribute mlsnetinbound;
> > > +attribute mlsnetoutbound;
> > >
> > >  attribute mlsipcread;
> > >  attribute mlsipcreadtoclr;
> > >
> > > --
> > > paul moore
> > > linux @ hp
> > >
> > > _______________________________________________
> > > refpolicy mailing list
> > > refpolicy@oss.tresys.com
> > > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [refpolicy] [PATCH v2] refpolicy: Add missing network related MLSconstraints
@ 2009-02-24 16:06       ` Christopher J. PeBenito
  0 siblings, 0 replies; 10+ messages in thread
From: Christopher J. PeBenito @ 2009-02-24 16:06 UTC (permalink / raw)
  To: refpolicy

On Tue, 2009-02-24 at 10:33 -0500, Paul Moore wrote:
> On Tuesday 24 February 2009 10:11:56 am chanson at trustedcs.com wrote:
> > Hi Paul,
> >
> > Is there any reason we can't utilize the new interfaces to handle the
> > unlabeled_t lines in the constraints? I'm not a real big fan of putting
> > direct types into the constraints.
> 
> Convention and consistency with the other network constraints.  I suppose this 
> is really a judgment call because what is the real difference between using 
> direct types and simply loading up the types with the MLS 
> overrides/attributes?  The "unlabeled_t" type really is special and it seems 
> cleaner to me to use it directly in the constraints rather than adding a bunch 
> of attributes to it.

There would also be a behavior change with the netif:egress and
node:sendto permissions.  Though I'm not sure it would matter in this
case, I don't think doing something similar for the other two
constraints that currently have explicit unlabeled_t references would
work.  I'm fine with the explicit references for now.  If someone can
make a patch that removes all the explicit references in a reasonable
way, then I'd be interested.

> > > -----Original Message-----
> > > From: refpolicy-bounces at oss.tresys.com
> > > [mailto:refpolicy-bounces at oss.tresys.com] On Behalf Of Paul Moore
> > > Sent: Friday, February 20, 2009 4:03 PM
> > > To: selinux at tycho.nsa.gov; refpolicy at oss.tresys.com
> > > Subject: [refpolicy] [PATCH v2] refpolicy: Add missing
> > > network related MLSconstraints
> > >
> > > 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                   |   45
> > > +++++++++++++++++++++++++++++++++++++++++++
> > >  policy/modules/kernel/mls.if |   42
> > > ++++++++++++++++++++++++++++++++++++++++
> > >  policy/modules/kernel/mls.te |    2 +
> > >  3 files changed, 89 insertions(+)
> > >
> > > Index: refpolicy_svn_repo/policy/mls
> > > ===================================================================
> > > --- refpolicy_svn_repo.orig/policy/mls
> > > +++ refpolicy_svn_repo/policy/mls
> > > @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetinbound ) or
> > > +	 ( t1 == unlabeled_t ));
> > > +mlsconstrain { netif } { egress }
> > > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetinbound ) or
> > > +	 ( t1 == unlabeled_t ));
> > > +mlsconstrain { node } { sendto }
> > > +	((( l1 dom l2 ) and ( l1 domby 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 }
> > > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetinbound ) or
> > > +	 ( t1 == unlabeled_t ));
> > > +mlsconstrain { packet } { forward_out }
> > > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > > +	 ( t1 == mlsnetoutbound ) 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
> > > Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> > > ===================================================================
> > > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> > > +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> > > @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
> > >
> > >  ########################################
> > >  ## <summary>
> > > +##	Make specified domain trusted to
> > > +##	write inbound packets regardless of the
> > > +##	network's or node's MLS range.
> > > +## </summary>
> > > +## <param name="domain">
> > > +##	<summary>
> > > +##	Domain allowed access.
> > > +##	</summary>
> > > +## </param>
> > > +## <rolecap/>
> > > +#
> > > +interface(`mls_net_inbound_all_levels',`
> > > +	gen_require(`
> > > +		attribute mlsnetinbound;
> > > +	')
> > > +
> > > +	typeattribute $1 mlsnetinbound;
> > > +')
> > > +
> > > +########################################
> > > +## <summary>
> > > +##	Make specified domain trusted to
> > > +##	write outbound packets regardless of the
> > > +##	network's or node's MLS range.
> > > +## </summary>
> > > +## <param name="domain">
> > > +##	<summary>
> > > +##	Domain allowed access.
> > > +##	</summary>
> > > +## </param>
> > > +## <rolecap/>
> > > +#
> > > +interface(`mls_net_outbound_all_levels',`
> > > +	gen_require(`
> > > +		attribute mlsnetoutbound;
> > > +	')
> > > +
> > > +	typeattribute $1 mlsnetoutbound;
> > > +')
> > > +
> > > +########################################
> > > +## <summary>
> > >  ##	Make specified domain MLS trusted
> > >  ##	for reading from System V IPC objects
> > >  ##	up to its clearance.
> > > Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> > > ===================================================================
> > > --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> > > +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> > > @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;  attribute
> > > mlsnetupgrade;  attribute mlsnetdowngrade;  attribute mlsnetrecvall;
> > > +attribute mlsnetinbound;
> > > +attribute mlsnetoutbound;
> > >
> > >  attribute mlsipcread;
> > >  attribute mlsipcreadtoclr;
> > >
> > > --
> > > paul moore
> > > linux @ hp
> > >
> > > _______________________________________________
> > > refpolicy mailing list
> > > refpolicy at oss.tresys.com
> > > http://oss.tresys.com/mailman/listinfo/refpolicy
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [refpolicy] [PATCH v2] refpolicy: Add missing network related MLS constraints
  2009-02-20 22:02 ` [refpolicy] " Paul Moore
@ 2009-03-02 15:39   ` Christopher J. PeBenito
  -1 siblings, 0 replies; 10+ messages in thread
From: Christopher J. PeBenito @ 2009-03-02 15:39 UTC (permalink / raw)
  To: Paul Moore; +Cc: selinux, refpolicy

On Fri, 2009-02-20 at 17:02 -0500, Paul Moore wrote:
> plain text document attachment (netpeer-constraints)
> 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

Merged.

> Signed-off-by: Paul Moore <paul.moore@hp.com>
> 
> ---
>  policy/mls                   |   45 +++++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.if |   42 ++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.te |    2 +
>  3 files changed, 89 insertions(+)
> 
> Index: refpolicy_svn_repo/policy/mls
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/mls
> +++ refpolicy_svn_repo/policy/mls
> @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { netif } { egress }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { node } { sendto }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { packet } { forward_out }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetoutbound ) 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
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
>  
>  ########################################
>  ## <summary>
> +##	Make specified domain trusted to
> +##	write inbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_inbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetinbound;
> +	')
> +
> +	typeattribute $1 mlsnetinbound;
> +')
> +
> +########################################
> +## <summary>
> +##	Make specified domain trusted to
> +##	write outbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_outbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetoutbound;
> +	')
> +
> +	typeattribute $1 mlsnetoutbound;
> +')
> +
> +########################################
> +## <summary>
>  ##	Make specified domain MLS trusted
>  ##	for reading from System V IPC objects
>  ##	up to its clearance.
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;
>  attribute mlsnetupgrade;
>  attribute mlsnetdowngrade;
>  attribute mlsnetrecvall;
> +attribute mlsnetinbound;
> +attribute mlsnetoutbound;
>  
>  attribute mlsipcread;
>  attribute mlsipcreadtoclr;
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [refpolicy] [PATCH v2] refpolicy: Add missing network related MLS constraints
@ 2009-03-02 15:39   ` Christopher J. PeBenito
  0 siblings, 0 replies; 10+ messages in thread
From: Christopher J. PeBenito @ 2009-03-02 15:39 UTC (permalink / raw)
  To: refpolicy

On Fri, 2009-02-20 at 17:02 -0500, Paul Moore wrote:
> plain text document attachment (netpeer-constraints)
> 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

Merged.

> Signed-off-by: Paul Moore <paul.moore@hp.com>
> 
> ---
>  policy/mls                   |   45 +++++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.if |   42 ++++++++++++++++++++++++++++++++++++++++
>  policy/modules/kernel/mls.te |    2 +
>  3 files changed, 89 insertions(+)
> 
> Index: refpolicy_svn_repo/policy/mls
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/mls
> +++ refpolicy_svn_repo/policy/mls
> @@ -295,8 +295,53 @@ 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 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { netif } { egress }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { node } { sendto }
> +	((( l1 dom l2 ) and ( l1 domby 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 }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetinbound ) or
> +	 ( t1 == unlabeled_t ));
> +mlsconstrain { packet } { forward_out }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t1 == mlsnetoutbound ) 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
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.if
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.if
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.if
> @@ -332,6 +332,48 @@ interface(`mls_net_write_within_range',`
>  
>  ########################################
>  ## <summary>
> +##	Make specified domain trusted to
> +##	write inbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_inbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetinbound;
> +	')
> +
> +	typeattribute $1 mlsnetinbound;
> +')
> +
> +########################################
> +## <summary>
> +##	Make specified domain trusted to
> +##	write outbound packets regardless of the
> +##	network's or node's MLS range.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain allowed access.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`mls_net_outbound_all_levels',`
> +	gen_require(`
> +		attribute mlsnetoutbound;
> +	')
> +
> +	typeattribute $1 mlsnetoutbound;
> +')
> +
> +########################################
> +## <summary>
>  ##	Make specified domain MLS trusted
>  ##	for reading from System V IPC objects
>  ##	up to its clearance.
> Index: refpolicy_svn_repo/policy/modules/kernel/mls.te
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/mls.te
> +++ refpolicy_svn_repo/policy/modules/kernel/mls.te
> @@ -22,6 +22,8 @@ attribute mlsnetwriteranged;
>  attribute mlsnetupgrade;
>  attribute mlsnetdowngrade;
>  attribute mlsnetrecvall;
> +attribute mlsnetinbound;
> +attribute mlsnetoutbound;
>  
>  attribute mlsipcread;
>  attribute mlsipcreadtoclr;
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-03-02 15:40 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-20 22:02 [PATCH v2] refpolicy: Add missing network related MLS constraints Paul Moore
2009-02-20 22:02 ` [refpolicy] " Paul Moore
2009-02-24 15:11 ` [refpolicy] [PATCH v2] refpolicy: Add missing network related MLSconstraints chanson
2009-02-24 15:11   ` chanson at TrustedCS.com
2009-02-24 15:33   ` Paul Moore
2009-02-24 15:33     ` Paul Moore
2009-02-24 16:06     ` Christopher J. PeBenito
2009-02-24 16:06       ` Christopher J. PeBenito
2009-03-02 15:39 ` [refpolicy] [PATCH v2] refpolicy: Add missing network related MLS constraints Christopher J. PeBenito
2009-03-02 15:39   ` Christopher J. PeBenito

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.