Networking policy patch

Networking policy patch

[Venkat Yekkirala]

FYI- I have posted the following patches separate from this one.

1. A patch to address the "leask" issue. Once verified, it needs
to be rolled in with James' patch and sent on after verification.

2. A fix for flow_in and flow_out where we were using the unlabeled
   init sid. We would now use a new network_t with a range of (s0-s15...)
   to allow for mls traffic to flow out/in, in the absence of explicit secmark
   rules.


The following is a sample patch for networking using the new controls
in conjunction with secmark.

NOTE FOR JOSHUA: This patch also defines the constraints to force context
equality for association:sendto.

I couldn't readily figure out where to stick these in, but these would
help the system come up without any denials.

+allow domain network_t:packet { flow_in flow_out };
+auditallow domain network_t:packet { flow_in flow_out };
+allow unlabeled_t network_t:packet { flow_in flow_out };
+auditallow unlabeled_t network_t:packet { flow_in flow_out };
+allow domain domain:packet { recv };
+auditallow domain domain:packet { recv };
+allow initrc_t unlabeled_t:packet { recv };
+auditallow initrc_t unlabeled_t:packet { recv };
+allow portmap_t unlabeled_t:packet { recv };
+auditallow portmap_t unlabeled_t:packet { recv };
+allow portmap_t rpcd_t:packet { recv };
+auditallow portmap_t rpcd_t:packet { recv };
+allow hplip_t hplip_t:packet { recv };
+auditallow hplip_t hplip_t:packet { recv };
+allow hplip_t cupsd_t:packet { recv };
+auditallow hplip_t cupsd_t:packet { recv };
+allow domain unlabeled_t:packet { recv };
+auditallow domain unlabeled_t:packet { recv };
+allow avahi_t unlabeled_t:packet { recv };
+auditallow avahi_t unlabeled_t:packet { recv };


--- serefpolicy-2.3.2.vanilla/policy/mls	2006-07-09 04:51:24.000000000 -0500
+++ serefpolicy-2.3.2/policy/mls	2006-10-03 18:45:33.000000000 -0500
@@ -668,7 +668,30 @@ mlsconstrain xinput { setattr relabelinp
 # MLS policy for the association class
 #
 
-# these access vectors have no MLS restrictions
-# association *
+mlsconstrain association { recvfrom }
+	((( l1 dom l2 ) and ( l1 domby h2 )) or
+	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsnetread ) or
+	 ( t2 == unlabeled_t ));
+
+mlsconstrain association { sendto }
+	(( l1 eq l2 ) and ( h1 eq h2 ));
+
+mlsconstrain association { polmatch }
+	((( l1 dom l2 ) and ( l1 domby h2 )) or
+	 ( t2 == unlabeled_t ));
+
+#
+# MLS policy for the packet class
+#
+
+mlsconstrain packet { recv }
+	(( l1 eq l2 ) or
+	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
+	 ( t1 == mlsnetread ));
+
+mlsconstrain packet { flow_in flow_out }
+	((( l1 dom l2 ) and ( l1 domby h2 )) or
+	 ( t1 == mlsnetflow ));
 
 ') dnl end enable_mls
--- serefpolicy-2.3.2.vanilla/policy/flask/access_vectors	2006-07-09 04:51:24.000000000 -0500
+++ serefpolicy-2.3.2/policy/flask/access_vectors	2006-10-03 18:45:33.000000000 -0500
@@ -617,6 +618,8 @@ class packet
 	send
 	recv
 	relabelto
+	flow_in
+	flow_out
 }
 
 class key
--- serefpolicy-2.3.2.vanilla/policy/constraints	2006-07-09 04:51:24.000000000 -0500
+++ serefpolicy-2.3.2/policy/constraints	2006-10-03 18:45:33.000000000 -0500
@@ -90,3 +90,9 @@ constrain dir_file_class_set { create re
 
 constrain socket_class_set { create relabelto relabelfrom } 
 	( u1 == u2 or t1 == can_change_object_identity );
+
+#
+# SElinux association sendto constraint:
+#
+constrain association sendto
+	( u1 == u2 and r1 == r2 and t1 == t2 );
--- serefpolicy-2.3.2.vanilla/policy/modules/kernel/mls.te	2006-07-09 04:51:24.000000000 -0500
+++ serefpolicy-2.3.2/policy/modules/kernel/mls.te	2006-10-03 18:45:33.000000000 -0500
@@ -20,6 +20,7 @@ attribute mlsnetwritetoclr;
 attribute mlsnetupgrade;
 attribute mlsnetdowngrade;
 attribute mlsnetrecvall;
+attribute mlsnetflow;
 
 attribute mlsipcread;
 attribute mlsipcreadtoclr;
--- serefpolicy-2.3.2.vanilla/policy/modules/kernel/kernel.te	2006-07-09 04:51:24.000000000 -0500
+++ serefpolicy-2.3.2/policy/modules/kernel/kernel.te	2006-10-03 18:58:37.000000000 -0500
@@ -35,7 +35,7 @@ ifdef(`enable_mls',`
 # kernel_t is the domain of kernel threads.
 # It is also the target type when checking permissions in the system class.
 # 
-type kernel_t, can_load_kernmodule;
+type kernel_t, can_load_kernmodule, mlsnetflow;
 domain_base_type(kernel_t)
 mls_rangetrans_source(kernel_t)
 role system_r types kernel_t;
@@ -138,6 +138,18 @@ genfscon proc /sys/dev gen_context(syste
 type unlabeled_t;
 sid unlabeled gen_context(system_u:object_r:unlabeled_t,s15:c0.c255)
 
+# netmsg is now used for the unconditional (and redundant when a packet has
+# already been flow-controlled via [CONN]SECMARK) check that happens in the
+# SELinux post_route_last netfilter hook for ALL network traffic.
+# The following would need packet.flow_out access to network_t:
+# a. Any domains needing to access the network bypassing (CONN)SECMARK.
+# b. Outbound domains specified in the (CONN)SECMARK rule contexts specified
+#    via iptables. This shouldn't actually be needed (just like a packet.flow_in access
+#    of these domains to network_t isn't needed), but is currently required due to the
+#    underlying kernel implementation constraints.
+type network_t;
+sid netmsg		gen_context(system_u:object_r:network_t,s0 - s15:c0.c255)
+
 # These initial sids are no longer used, and can be removed:
 sid any_socket		gen_context(system_u:object_r:unlabeled_t,s15:c0.c255)
 sid file_labels		gen_context(system_u:object_r:unlabeled_t,s0)
@@ -145,7 +157,6 @@ sid icmp_socket		gen_context(system_u:ob
 sid igmp_packet		gen_context(system_u:object_r:unlabeled_t,s15:c0.c255)
 sid init		gen_context(system_u:object_r:unlabeled_t,s0)
 sid kmod		gen_context(system_u:object_r:unlabeled_t,s15:c0.c255)
-sid netmsg		gen_context(system_u:object_r:unlabeled_t,s15:c0.c255)
 sid policy		gen_context(system_u:object_r:unlabeled_t,s15:c0.c255)
 sid scmp_packet		gen_context(system_u:object_r:unlabeled_t,s15:c0.c255)
 sid sysctl_modprobe 	gen_context(system_u:object_r:unlabeled_t,s0)

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

Re: Networking policy patch

[Christopher J. PeBenito]

On Tue, 2006-10-03 at 21:54 -0500, Venkat Yekkirala wrote:
> FYI- I have posted the following patches separate from this one.
> 
> 1. A patch to address the "leask" issue. Once verified, it needs
> to be rolled in with James' patch and sent on after verification.
> 
> 2. A fix for flow_in and flow_out where we were using the unlabeled
>    init sid. We would now use a new network_t with a range of (s0-s15...)
>    to allow for mls traffic to flow out/in, in the absence of explicit secmark
>    rules.
> 
> 
> The following is a sample patch for networking using the new controls
> in conjunction with secmark.
> 
> NOTE FOR JOSHUA: This patch also defines the constraints to force context
> equality for association:sendto.

I'm starting a labeled networking branch of refpolicy to work with this.
I'm waiting until the dust settles before adding TE rules, but I have
some questions:

> +mlsconstrain association { recvfrom }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> +	 ( t1 == mlsnetread ) or
> +	 ( t2 == unlabeled_t ));

Don't we want network_t instead of unlabeled_t?

> +mlsconstrain association { sendto }
> +	(( l1 eq l2 ) and ( h1 eq h2 ));

or (t2 == network_t) ?

> +mlsconstrain association { polmatch }
> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> +	 ( t2 == unlabeled_t ));

same thing about network_t

> +constrain association sendto
> +	( u1 == u2 and r1 == r2 and t1 == t2 );

I talked with Joshua and we determined that there is a case were we
don't want this constraint (looking forward to policy management
server's use of labeled networking), so I've dropped it.

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

Re: [redhat-lspp] Re: Networking policy patch

[Paul Moore]

Christopher J. PeBenito wrote:
> On Tue, 2006-10-03 at 21:54 -0500, Venkat Yekkirala wrote:
> 
>>FYI- I have posted the following patches separate from this one.
>>
>>1. A patch to address the "leask" issue. Once verified, it needs
>>to be rolled in with James' patch and sent on after verification.
>>
>>2. A fix for flow_in and flow_out where we were using the unlabeled
>>   init sid. We would now use a new network_t with a range of (s0-s15...)
>>   to allow for mls traffic to flow out/in, in the absence of explicit secmark
>>   rules.
>>
>>
>>The following is a sample patch for networking using the new controls
>>in conjunction with secmark.
>>
>>NOTE FOR JOSHUA: This patch also defines the constraints to force context
>>equality for association:sendto.
> 
> I'm starting a labeled networking branch of refpolicy to work with this.

Is this available yet?  If so, how do I got about getting a copy to take a look?

> I'm waiting until the dust settles before adding TE rules, but I have
> some questions:

Now that things are starting to calm down a bit I'm trying to get a chance to
look at the current policy and how it affects NetLabel.  In the secid case I
believe NetLabel can just ride on the back of the policy work you and Venkat are
discussing, however, if the reference policy is also going to support the
network compatability mode I suspect there will need to be some changes to allow
NetLabel'd traffic to work.

In the network compatability mode there is really only one new access check for
NetLabel:

 avc_has_perm(sock_sid, netlbl_sid, sock_class, recv_perm, ...)

  sock_sid: the socket's SID
  netlbl_sid: SECINITSID_UNLABELED w/the MLS label of the connection
  sock_class: SECCLASS_{UDP,TCP,<other*>}_SOCKET
  recv_perm: {UDP,TCP,RAWIP}_SOCKET__RECVFROM

  *other: all sockets not either a UDP or TCP socket use the RAWIP recvfrom
          permission

Based on my very limited knowledge of SELinux policy I think we would need the
following allow rules:

 # assumes the socket's context matches the parent processes' domain
 allow <domain> self:{udp_socket tcp_socket rawip_socket} { recvfrom }

I don't believe the above rule currently exists in the reference policy.

There is also an issue of writing policy for netlabelctl, the NetLabel
configuration tool.  Klaus and I have passed around some simple policy modules
on the lspp list which have provided policy for netlabelctl.  I'm going to try
and revisit the last version posted and see if it needs to be updated, once it
is working I would like to try and have it included in the reference policy.
Would you prefer I post the policy as a standalone policy module or as a patch
against the reference policy currently in SVN?

-- 
paul moore
linux security @ 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.

Re: [redhat-lspp] Re: Networking policy patch

[Christopher J. PeBenito]

On Fri, 2006-10-06 at 10:10 -0400, Paul Moore wrote:
> Christopher J. PeBenito wrote:
> > On Tue, 2006-10-03 at 21:54 -0500, Venkat Yekkirala wrote:
> > 
> >>FYI- I have posted the following patches separate from this one.
> >>
> >>1. A patch to address the "leask" issue. Once verified, it needs
> >>to be rolled in with James' patch and sent on after verification.
> >>
> >>2. A fix for flow_in and flow_out where we were using the unlabeled
> >>   init sid. We would now use a new network_t with a range of (s0-s15...)
> >>   to allow for mls traffic to flow out/in, in the absence of explicit secmark
> >>   rules.
> >>
> >>
> >>The following is a sample patch for networking using the new controls
> >>in conjunction with secmark.
> >>
> >>NOTE FOR JOSHUA: This patch also defines the constraints to force context
> >>equality for association:sendto.
> > 
> > I'm starting a labeled networking branch of refpolicy to work with this.
> 
> Is this available yet?  If so, how do I got about getting a copy to take a look?

Yes, however it doesn't have anything interesting yet, just the flow_in
and flow_out perms.

svn co http://oss.tresys.com/repos/refpolicy/branches/labeled-networking-2029 refpolicy

> > I'm waiting until the dust settles before adding TE rules, but I have
> > some questions:
> 
> Now that things are starting to calm down a bit I'm trying to get a chance to
> look at the current policy and how it affects NetLabel.  In the secid case I
> believe NetLabel can just ride on the back of the policy work you and Venkat are
> discussing, however, if the reference policy is also going to support the
> network compatability mode I suspect there will need to be some changes to allow
> NetLabel'd traffic to work.
> 
> In the network compatability mode there is really only one new access check for
> NetLabel:

Changing the behavior of compat_net seems very bad, since the point of
it is compatibility.  If we need to update the policy, then that is not
compatibility.

> There is also an issue of writing policy for netlabelctl, the NetLabel
> configuration tool.  Klaus and I have passed around some simple policy modules
> on the lspp list which have provided policy for netlabelctl.  I'm going to try
> and revisit the last version posted and see if it needs to be updated, once it
> is working I would like to try and have it included in the reference policy.
> Would you prefer I post the policy as a standalone policy module or as a patch
> against the reference policy currently in SVN?

If it makes no changes to other modules, then either way is ok,
otherwise a patch would be better.  Use the labeled networking branch
above.

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

Re: [redhat-lspp] Re: Networking policy patch

[Paul Moore]

Christopher J. PeBenito wrote:
> On Fri, 2006-10-06 at 10:10 -0400, Paul Moore wrote:
> 
>>Christopher J. PeBenito wrote:
>>
>>>On Tue, 2006-10-03 at 21:54 -0500, Venkat Yekkirala wrote:
>>>
>>>
>>>>FYI- I have posted the following patches separate from this one.
>>>>
>>>>1. A patch to address the "leask" issue. Once verified, it needs
>>>>to be rolled in with James' patch and sent on after verification.
>>>>
>>>>2. A fix for flow_in and flow_out where we were using the unlabeled
>>>>  init sid. We would now use a new network_t with a range of (s0-s15...)
>>>>  to allow for mls traffic to flow out/in, in the absence of explicit secmark
>>>>  rules.
>>>>
>>>>
>>>>The following is a sample patch for networking using the new controls
>>>>in conjunction with secmark.
>>>>
>>>>NOTE FOR JOSHUA: This patch also defines the constraints to force context
>>>>equality for association:sendto.
>>>
>>>I'm starting a labeled networking branch of refpolicy to work with this.
>>
>>Is this available yet?  If so, how do I got about getting a copy to take a look?
> 
> Yes, however it doesn't have anything interesting yet, just the flow_in
> and flow_out perms.
> 
> svn co http://oss.tresys.com/repos/refpolicy/branches/labeled-networking-2029 refpolicy

Okay, thanks.

>>>I'm waiting until the dust settles before adding TE rules, but I have
>>>some questions:
>>
>>Now that things are starting to calm down a bit I'm trying to get a chance to
>>look at the current policy and how it affects NetLabel.  In the secid case I
>>believe NetLabel can just ride on the back of the policy work you and Venkat are
>>discussing, however, if the reference policy is also going to support the
>>network compatability mode I suspect there will need to be some changes to allow
>>NetLabel'd traffic to work.
>>
>>In the network compatability mode there is really only one new access check for
>>NetLabel:
> 
> Changing the behavior of compat_net seems very bad, since the point of
> it is compatibility.  If we need to update the policy, then that is not
> compatibility.

I think I misused the network compatability statement, I should have said "In
the non secid-reconiliation case".  As far as I can tell there are no other
users of the "recvfrom" permission so I can't imagine it being that disruptive
to existing policy.

>>There is also an issue of writing policy for netlabelctl, the NetLabel
>>configuration tool.  Klaus and I have passed around some simple policy modules
>>on the lspp list which have provided policy for netlabelctl.  I'm going to try
>>and revisit the last version posted and see if it needs to be updated, once it
>>is working I would like to try and have it included in the reference policy.
>>Would you prefer I post the policy as a standalone policy module or as a patch
>>against the reference policy currently in SVN?
>  
> If it makes no changes to other modules, then either way is ok,
> otherwise a patch would be better.  Use the labeled networking branch
> above.

Okay, I'll try to put a patch together as soon as the stuff with the lspp.51
kernel is sorted.

-- 
paul moore
linux security @ 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.

Re: Networking policy patch

[Joshua Brindle]

Venkat Yekkirala wrote:
> FYI- I have posted the following patches separate from this one.
>
> 1. A patch to address the "leask" issue. Once verified, it needs
> to be rolled in with James' patch and sent on after verification.
>
> 2. A fix for flow_in and flow_out where we were using the unlabeled
>    init sid. We would now use a new network_t with a range of (s0-s15...)
>    to allow for mls traffic to flow out/in, in the absence of explicit secmark
>    rules.
>
>
> The following is a sample patch for networking using the new controls
> in conjunction with secmark.
>
> NOTE FOR JOSHUA: This patch also defines the constraints to force context
> equality for association:sendto.
>
> I couldn't readily figure out where to stick these in, but these would
> help the system come up without any denials.
>
>   
Ok, this may be an unpopular email but I was going over how everything 
(sans netlabel) was working as of right now (as I understand it) and I 
came across some things that seem strange. Maybe my understanding is 
wrong...

Basically I was trying the most complex situation (which includes socket 
labels that are different from the domain).
spd 1 is  ipsec_spd_t.
domain 1 is pms_proxy_t
socket 1 is sysadm_t (via setsockcreatecon)
secmark 1 is pms_c_p_t

spd 2 is ipsec_spd2_t
domain 2 is inetd_t
socket 2 is pms_t
secmark 2 is pms_s_p_t

therefore SA 1 is pms_t and SA 2 is sysadm_t

So here are the rules I came up with
side1:
allow pms_proxy_t pms_c_p_t : packet { send recv }
 - straightforward, already how secmark works
allow sysadm_t pms_t : packet { flow_in flow_out }
 - don't understand this, pms_t isn't a packet object, why are we using 
the packet object class?
allow pms_proxy_t ipsec_spd_t : association { polmatch }
 - likewise, an spd isn't an association, maybe this class needs to be 
more generic
allow pms_proxy_t pms_t : association { sendto recvfrom }
 - Not sure if this one is right, is the source suppose to be the domain 
or the socket?

side2:
allow inetd_t pms_s_p_t : packet {send recv }
allow pms_t sysadm_t : packet { flow_in flow_out }
allow inetd_t ipsec_spd2_t : association { polmatch }
allow inetd_t sysadm_t : association { sendto recvfrom }


do these rules seem correct given the scenerio above?

If so there seems to be some object class confusion.

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

Re: Networking policy patch

[Joshua Brindle]

Joshua Brindle wrote:
> <snip>

> Ok, this may be an unpopular email but I was going over how everything 
> (sans netlabel) was working as of right now (as I understand it) and I 
> came across some things that seem strange. Maybe my understanding is 
> wrong...
>
> Basically I was trying the most complex situation (which includes 
> socket labels that are different from the domain).
> spd 1 is  ipsec_spd_t.
> domain 1 is pms_proxy_t
> socket 1 is sysadm_t (via setsockcreatecon)
> secmark 1 is pms_c_p_t
>
> spd 2 is ipsec_spd2_t
> domain 2 is inetd_t
> socket 2 is pms_t
> secmark 2 is pms_s_p_t
>
> therefore SA 1 is pms_t and SA 2 is sysadm_t
>
> So here are the rules I came up with
> side1:
> allow pms_proxy_t pms_c_p_t : packet { send recv }
> - straightforward, already how secmark works
> allow sysadm_t pms_t : packet { flow_in flow_out }
> - don't understand this, pms_t isn't a packet object, why are we using 
> the packet object class?
Er, I totally messed this up, it should have been
allow pms_t pms_c_p_t : packet { flow_in flow_out } which has the 
correct object class, not sure what I was thinking
> allow pms_proxy_t ipsec_spd_t : association { polmatch }
> - likewise, an spd isn't an association, maybe this class needs to be 
> more generic
this one still applies but its an aesthetic thing and I suppose noone is 
going to want to rename the object class
> allow pms_proxy_t pms_t : association { sendto recvfrom }
> - Not sure if this one is right, is the source suppose to be the 
> domain or the socket?
>
This is domain, right?



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

RE: Networking policy patch

[Venkat Yekkirala]

> > NOTE FOR JOSHUA: This patch also defines the constraints to 
> force context
> > equality for association:sendto.
> 
> I'm starting a labeled networking branch of refpolicy to work 
> with this.
> I'm waiting until the dust settles before adding TE rules, but I have
> some questions:
> 
> > +mlsconstrain association { recvfrom }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
> > +	 ( t1 == mlsnetread ) or
> > +	 ( t2 == unlabeled_t ));
> 
> Don't we want network_t instead of unlabeled_t?

Actually, the above only applies to the compat_net case
and there unlabeled_t is just fine.

So, there are different MLS constraints (and policy) for
the compat_net case as opposed to the new secmark controls.

I guess you are planning to have one policy for compat_net
and another for secmark?

> 
> > +mlsconstrain association { sendto }
> > +	(( l1 eq l2 ) and ( h1 eq h2 ));
> 
> or (t2 == network_t) ?

No. Not in the secmark case.

> 
> > +mlsconstrain association { polmatch }
> > +	((( l1 dom l2 ) and ( l1 domby h2 )) or
> > +	 ( t2 == unlabeled_t ));
> 
> same thing about network_t

Actually, chuck the t2 == unlabeled_t exception all together.
It doesn't apply to the secmark policy.

> 
> > +constrain association sendto
> > +	( u1 == u2 and r1 == r2 and t1 == t2 );
> 
> I talked with Joshua and we determined that there is a case were we
> don't want this constraint (looking forward to policy management
> server's use of labeled networking), so I've dropped it.

The above constraint is necessary for the kernel portions of SELinux
to work properly. In fact I was going to originally implement it in the
kernel and when Darrel made me aware of the constraint framework and the
benefits with avc caching, etc., I decided to use it.

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

Re: Networking policy patch

[Joshua Brindle]

Venkat Yekkirala wrote:
>>
>>> +mlsconstrain association { recvfrom }
>>> +	((( l1 dom l2 ) and ( l1 domby h2 )) or
>>> +	 (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
>>> +	 ( t1 == mlsnetread ) or
>>> +	 ( t2 == unlabeled_t ));
>>>       
>> Don't we want network_t instead of unlabeled_t?
>>     
>
> Actually, the above only applies to the compat_net case
> and there unlabeled_t is just fine.
>
>   
why isn't compat_net using the same default sid for associations?
> So, there are different MLS constraints (and policy) for
> the compat_net case as opposed to the new secmark controls.
>
>   
there shouldn't be, compat_net and secmark use different object classes 
(except association) and the behaviors should not conflict
> I guess you are planning to have one policy for compat_net
> and another for secmark?
>
>   
I'll let Chris comment here but I don't think that is ideal.
>>> +mlsconstrain association { sendto }
>>> +	(( l1 eq l2 ) and ( h1 eq h2 ));
>>>       
>> or (t2 == network_t) ?
>>     
>
> No. Not in the secmark case.
>   
If there are no ipsec associations at all it will default to 
network_t:SystemHigh-SystemLow so this would only allow domains that are 
SystemHigh-SystemLow to send plaintext? Not sure this is what we want

> <snip>
>>> +constrain association sendto
>>> +	( u1 == u2 and r1 == r2 and t1 == t2 );
>>>       
>> I talked with Joshua and we determined that there is a case were we
>> don't want this constraint (looking forward to policy management
>> server's use of labeled networking), so I've dropped it.
>>     
>
> The above constraint is necessary for the kernel portions of SELinux
> to work properly. In fact I was going to originally implement it in the
> kernel and when Darrel made me aware of the constraint framework and the
> benefits with avc caching, etc., I decided to use it.
>
>   
This completely disallows the use of setsockcreatecon() with labeled 
networking, not good.

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

Re: Networking policy patch

[Christopher J. PeBenito]

On Fri, 2006-10-06 at 11:13 -0400, Joshua Brindle wrote:
> Venkat Yekkirala wrote:
> > Actually, the above only applies to the compat_net case
> > and there unlabeled_t is just fine.
> >
> >   
> why isn't compat_net using the same default sid for associations?
> > So, there are different MLS constraints (and policy) for
> > the compat_net case as opposed to the new secmark controls.
> >
> >   
> there shouldn't be, compat_net and secmark use different object classes 
> (except association) and the behaviors should not conflict
> > I guess you are planning to have one policy for compat_net
> > and another for secmark?
> >
> >   
> I'll let Chris comment here but I don't think that is ideal.

Agreed, it would not be ideal.  The behaviors shouldn't conflict, so a
unified policy should be doable.

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