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