RE: Networking policy patch

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.

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