RE: security context for SPD entries of labeled IPsec

RE: security context for SPD entries of labeled IPsec

[Venkat Yekkirala]

<snip>
> > There are 2 aspects:
> > 
> > 1. IPsec policy matching discussed above:
> >    allow domain-that-should-use-labeled-ipsec 
> ipsec_spd_t:association { polmatch };
> > 
> > 2. Use of IPsec associations themselves:
> > 
> >    For sending:
> >    allow 
> domain-that-should-use-labeled-ipsec-to-label-its-packets 
> self:association { sendto };
> > 
> >    For receiving:
> >    allow domain-that-should-received-from-peer  peer-domain 
> self:association { recvfrom };
> 
> When we consider the case unconfined_t process tries to 
> communicate with a postgresql_t
> process running on another host via labeled IPsec, the 
> following policy will be needed.
> 
> 1.  allow unconfined_t ipsec_spd_t : association { polmatch };

Also, allow postgresql_t ipsec_spd_t : association { polmatch };
since the incoming packet labeled postgresql_t should be checked
against IPsec policy (SPD) rule labeled with ipsec_spd_t.

> 2s. allow unconfined_t self : association { sendto };

OK.

> 2r. allow postgresql_t unconfined_t : association { recvfrom };

This should actually be:

allow unconfined_t postgresql_t : association { recvfrom };

since it would be the unconfined_t socket that would be receiving
a packet using the postgresql_t association.

> 
> Is it correct?
> 
<snip>

--
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: security context for SPD entries of labeled IPsec

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]

Hi, Venkat

Thanks for your suggestion.

I got a success to set up labeled ipsec connection with modified
reference policy, as follows:

----------------------------------------------------------------
[kaigai@fedora8 ~]$ psql -q -h 192.168.1.10 postgres
Password:
postgres=# SELECT sepgsql_getcon();
                 sepgsql_getcon
-------------------------------------------------
 root:system_r:unconfined_t:SystemLow-SystemHigh
(1 row)

postgres=#

[kaigai@fedora8 ~]$ runcon -l s0 psql -q -h 192.168.1.10 postgres
Password:
postgres=# SELECT sepgsql_getcon();
       sepgsql_getcon
----------------------------
 root:system_r:unconfined_t
(1 row)

postgres=#
----------------------------------------------------------------

The attached patch provides two new interfaces to access the default
context of SPD entries (ipsec_spd_t), and enables unconfined domains
to set up SPD entries with the default context.
In addition, any unconfined domain, user domain and daemon domain
got being possible to communicate others via labeled ipsec.

Please review it,

Thanks,

Venkat Yekkirala wrote:
> <snip>
>>> There are 2 aspects:
>>>
>>> 1. IPsec policy matching discussed above:
>>>    allow domain-that-should-use-labeled-ipsec 
>> ipsec_spd_t:association { polmatch };
>>> 2. Use of IPsec associations themselves:
>>>
>>>    For sending:
>>>    allow 
>> domain-that-should-use-labeled-ipsec-to-label-its-packets 
>> self:association { sendto };
>>>    For receiving:
>>>    allow domain-that-should-received-from-peer  peer-domain 
>> self:association { recvfrom };
>>
>> When we consider the case unconfined_t process tries to 
>> communicate with a postgresql_t
>> process running on another host via labeled IPsec, the 
>> following policy will be needed.
>>
>> 1.  allow unconfined_t ipsec_spd_t : association { polmatch };
> 
> Also, allow postgresql_t ipsec_spd_t : association { polmatch };
> since the incoming packet labeled postgresql_t should be checked
> against IPsec policy (SPD) rule labeled with ipsec_spd_t.
> 
>> 2s. allow unconfined_t self : association { sendto };
> 
> OK.
> 
>> 2r. allow postgresql_t unconfined_t : association { recvfrom };
> 
> This should actually be:
> 
> allow unconfined_t postgresql_t : association { recvfrom };
> 
> since it would be the unconfined_t socket that would be receiving
> a packet using the postgresql_t association.
> 
>> Is it correct?
>>
> <snip>
> 
> --
> 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.
> 


-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


[-- Attachment #2: refpolicy-labeled-ipsec.patch --]
[-- Type: text/plain, Size: 3890 bytes --]

Index: refpolicy/policy/modules/system/ipsec.if
===================================================================
--- refpolicy/policy/modules/system/ipsec.if	(revision 2483)
+++ refpolicy/policy/modules/system/ipsec.if	(working copy)
@@ -114,6 +114,43 @@
 
 ########################################
 ## <summary>
+##      Allow to communicate another peer via labeled IPsec.
+## </summary>
+## <param name="domain">
+##      <summary>
+##      The type of the process performing this action.
+##      </summary>
+## </param>
+#
+interface(`ipsec_default_sendrecv',`
+	gen_require(`
+		type ipsec_spd_t;
+	')
+
+	allow $1 ipsec_spd_t : association { polmatch };
+	domain_ipsec_labels($1)
+')
+
+########################################
+## <summary>
+##      Allow to set an default security context of IPsec Policy.
+## </summary>
+## <param name="domain">
+##      <summary>
+##      The type of the process performing this action.
+##      </summary>
+## </param>
+#
+interface(`ipsec_default_setcontext',`
+	gen_require(`
+		type ipsec_spd_t;
+	')
+
+	allow $1 ipsec_spd_t : association { setcontext };
+')
+
+########################################
+## <summary>
 ##	Execute racoon in the racoon domain.
 ## </summary>
 ## <param name="domain">
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2483)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -547,6 +547,10 @@
 	corenet_udp_sendrecv_all_ports($1_t)
 	corenet_tcp_connect_all_ports($1_t)
 	corenet_sendrecv_all_client_packets($1_t)
+
+	optional_policy(`
+		ipsec_default_sendrecv($1_t)
+	')
 ')
 
 #######################################
Index: refpolicy/policy/modules/system/init.if
===================================================================
--- refpolicy/policy/modules/system/init.if	(revision 2483)
+++ refpolicy/policy/modules/system/init.if	(working copy)
@@ -134,6 +134,10 @@
 	')
 
 	optional_policy(`
+		ipsec_default_sendrecv($1)
+	')
+
+	optional_policy(`
 		nscd_socket_use($1)
 	')
 ')
Index: refpolicy/policy/modules/system/unconfined.if
===================================================================
--- refpolicy/policy/modules/system/unconfined.if	(revision 2483)
+++ refpolicy/policy/modules/system/unconfined.if	(working copy)
@@ -73,6 +73,11 @@
 	')
 
 	optional_policy(`
+		ipsec_default_setcontext($1)
+		ipsec_default_sendrecv($1)
+	')
+
+	optional_policy(`
 		# this is to handle execmod on shared
 		# libs with text relocations
 		libs_use_shared_libs($1)
Index: refpolicy/policy/modules/system/ipsec.te
===================================================================
--- refpolicy/policy/modules/system/ipsec.te	(revision 2483)
+++ refpolicy/policy/modules/system/ipsec.te	(working copy)
@@ -6,6 +6,9 @@
 # Declarations
 #
 
+# Default type for IPSEC SPD entries
+type ipsec_spd_t;
+
 type ipsec_t;
 type ipsec_exec_t;
 init_daemon_domain(ipsec_t,ipsec_exec_t)
@@ -19,9 +22,6 @@
 type ipsec_key_file_t;
 files_type(ipsec_key_file_t)
 
-# Default type for IPSEC SPD entries
-type ipsec_spd_t;
-
 # type for runtime files, including pluto.ctl
 type ipsec_var_run_t;
 files_pid_file(ipsec_var_run_t)
@@ -297,7 +297,7 @@
 read_files_pattern(racoon_t,ipsec_key_file_t,ipsec_key_file_t)
 read_lnk_files_pattern(racoon_t,ipsec_key_file_t,ipsec_key_file_t)
 
-allow racoon_t ipsec_spd_t:association setcontext;
+ipsec_default_setcontext(racoon_t)
 
 kernel_read_network_state(racoon_t)
 
@@ -339,7 +339,7 @@
 read_lnk_files_pattern(setkey_t,ipsec_conf_file_t,ipsec_conf_file_t)
 
 # allow setkey to set the context for ipsec SAs and policy.
-allow setkey_t ipsec_spd_t:association setcontext;
+ipsec_default_setcontext(setkey_t)
 
 # allow setkey utility to set contexts on SA's and policy
 domain_ipsec_setcontext_all_domains(setkey_t)

Re: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Thu, 2007-11-15 at 01:36 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Tue, 2007-11-13 at 00:36 +0900, KaiGai Kohei wrote:
>>>> Did you notice that a patch was attached in my previous posting?
>>>> Because I put a description about this patch on the bottom of the message,
>>>> it might be easy to overlook it.
>>>>
>>>> Could you review it? It is desirable for me to enable to communicate
>>>> between different domains via labeled ipsec.
>>> I committed an alternate version,
>>>
>>> http://oss.tresys.com/projects/refpolicy/changeset/2499
>>> http://oss.tresys.com/projects/refpolicy/changeset/2500
>>>
>> Thanks to apply them,
>>
>> However, it does not contain any permissions which allows
>> users and daemons domain to communicate via labeled ipsec.
>>
>> In my patch, these permissions were allowed at system/init.if
>> and system/userdomain.if. Do you consider these permissions
>> should not be allowed implicitly inside these interfaces?
>>
>> Currently, it is not enough for SE-PostgreSQL to communicate
>> peers using a SPD with default security context.
>> They are requiring a bit more permissions.
> 
> I reject the blanket permissions that you had in your previous patch.

OK, I can agree.

I also suggest two minor improvement toward these updates.

1. Is it considerable to add "allow $1 self : association { sendto };"
   at ipsec_match_default_spd interface of ipsec.if?

   I think it should be packed with polmatch permission to the default
   SPD context, because any domain which want to communicate others using
   SPD with default context always have to have 'sendto' permission to
   itself.

2. Is it considerable to add "ipsec_match_default_spd($1_t)"
   in the userdom_basic_networking_template of userdomain.if?

   This interface allows a given userdomain widespread basic networking
   permissions. But it is not enough yet, if the networking tunnel
   is configured with labeled ipsec.
   I think it can be contained in the basic networking permissions
   to use ipsec SPD with default context.

> I'll consider a patch that adds it to a postresql interface.  Perhaps
> postgresql_tcp_connect should be un-deprecated.

I think similar interfaces are necessary for any other daemon-domain which
provides networking-services, even if they don't use getpeercon().

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Christopher J. PeBenito]

On Thu, 2007-11-15 at 11:51 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Thu, 2007-11-15 at 01:36 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> >>> On Tue, 2007-11-13 at 00:36 +0900, KaiGai Kohei wrote:
> >>>> Did you notice that a patch was attached in my previous posting?
> >>>> Because I put a description about this patch on the bottom of the message,
> >>>> it might be easy to overlook it.
> >>>>
> >>>> Could you review it? It is desirable for me to enable to communicate
> >>>> between different domains via labeled ipsec.
> >>> I committed an alternate version,
> >>>
> >>> http://oss.tresys.com/projects/refpolicy/changeset/2499
> >>> http://oss.tresys.com/projects/refpolicy/changeset/2500
> >>>
> >> Thanks to apply them,
> >>
> >> However, it does not contain any permissions which allows
> >> users and daemons domain to communicate via labeled ipsec.
> >>
> >> In my patch, these permissions were allowed at system/init.if
> >> and system/userdomain.if. Do you consider these permissions
> >> should not be allowed implicitly inside these interfaces?
> >>
> >> Currently, it is not enough for SE-PostgreSQL to communicate
> >> peers using a SPD with default security context.
> >> They are requiring a bit more permissions.
> > 
> > I reject the blanket permissions that you had in your previous patch.
> 
> OK, I can agree.
> 
> I also suggest two minor improvement toward these updates.
> 
> 1. Is it considerable to add "allow $1 self : association { sendto };"
>    at ipsec_match_default_spd interface of ipsec.if?
> 
>    I think it should be packed with polmatch permission to the default
>    SPD context, because any domain which want to communicate others using
>    SPD with default context always have to have 'sendto' permission to
>    itself.

Perhaps.  Though I thought that dropping the sendto check was being
considered, since it really doesn't gain anything.

> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
>    in the userdom_basic_networking_template of userdomain.if?
> 
>    This interface allows a given userdomain widespread basic networking
>    permissions. But it is not enough yet, if the networking tunnel
>    is configured with labeled ipsec.
>    I think it can be contained in the basic networking permissions
>    to use ipsec SPD with default context.

Sounds reasonable.

> > I'll consider a patch that adds it to a postresql interface.  Perhaps
> > postgresql_tcp_connect should be un-deprecated.
> 
> I think similar interfaces are necessary for any other daemon-domain which
> provides networking-services, even if they don't use getpeercon().

The recvfrom is needed if the networking is labeled, regardless of
whether getpeercon() is used or not.

-- 
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Paul Moore]

On Thursday 15 November 2007 9:26:53 am Christopher J. PeBenito wrote:
> Perhaps.  Though I thought that dropping the sendto check was being
> considered, since it really doesn't gain anything.

Yes, Darrel and Venkat (both added to the CC line) proposed removing the IPsec 
sendto check and it sounds reasonable to me.  I believe this will be part of 
the upcoming flow control patches, if not we should probably make this change 
for 2.6.25 so we can trigger it with the new netpeer capability.

Regardless, the refpol will most likely need to continue to support the sendto 
check for some time to preserve proper behavior with older kernels.

-- 
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[KaiGai Kohei]

>> I also suggest two minor improvement toward these updates.
>>
>> 1. Is it considerable to add "allow $1 self : association { sendto };"
>>    at ipsec_match_default_spd interface of ipsec.if?
>>
>>    I think it should be packed with polmatch permission to the default
>>    SPD context, because any domain which want to communicate others using
>>    SPD with default context always have to have 'sendto' permission to
>>    itself.
> 
> Perhaps.  Though I thought that dropping the sendto check was being
> considered, since it really doesn't gain anything.
> 
>> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
>>    in the userdom_basic_networking_template of userdomain.if?
>>
>>    This interface allows a given userdomain widespread basic networking
>>    permissions. But it is not enough yet, if the networking tunnel
>>    is configured with labeled ipsec.
>>    I think it can be contained in the basic networking permissions
>>    to use ipsec SPD with default context.
> 
> Sounds reasonable.

The attached patch enables the above two features.

Paul mentioned to drop the checks of association:{sendto} permission and
integrate them with the upcaming flow control checks in the future kernel.
However, a rule of "allow <domain> self : association {sendto}" will be
necessary for the backward compatibility.

>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
>>> postgresql_tcp_connect should be un-deprecated.
>> I think similar interfaces are necessary for any other daemon-domain which
>> provides networking-services, even if they don't use getpeercon().
> 
> The recvfrom is needed if the networking is labeled, regardless of
> whether getpeercon() is used or not.

Do you intend to describe the labeled networking rules for each combination
between a server domain and a client domain?

Is it a considerable idea that adding a new attribute to comunicate via
labeled ipsec with default SPD, and attaching it both a server domain and
a client domain?

e.g)
  attribute labeled_communicatable_domain;  # I want to get more shorl naming.
  allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};

  typeattribute postgresql_t, labeled_communicate_domain;
  typeattribute user_t, labeled_communicate_domain;

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Index: refpolicy/policy/modules/system/ipsec.if
===================================================================
--- refpolicy/policy/modules/system/ipsec.if	(revision 2524)
+++ refpolicy/policy/modules/system/ipsec.if	(working copy)
@@ -109,6 +109,7 @@
 	')

 	allow $1 ipsec_spd_t:association polmatch;
+	allow $1 self:association sendto;
 ')

 ########################################
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2524)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -548,6 +548,8 @@
 	corenet_udp_sendrecv_all_ports($1_t)
 	corenet_tcp_connect_all_ports($1_t)
 	corenet_sendrecv_all_client_packets($1_t)
+
+	ipsec_match_default_spd($1_t)
 ')

 #######################################


--
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Christopher J. PeBenito]

On Mon, 2007-11-19 at 11:21 +0900, KaiGai Kohei wrote:
> >> I also suggest two minor improvement toward these updates.
> >>
> >> 1. Is it considerable to add "allow $1 self : association { sendto };"
> >>    at ipsec_match_default_spd interface of ipsec.if?
> >>
> >>    I think it should be packed with polmatch permission to the default
> >>    SPD context, because any domain which want to communicate others using
> >>    SPD with default context always have to have 'sendto' permission to
> >>    itself.
> > 
> > Perhaps.  Though I thought that dropping the sendto check was being
> > considered, since it really doesn't gain anything.
> > 
> >> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
> >>    in the userdom_basic_networking_template of userdomain.if?
> >>
> >>    This interface allows a given userdomain widespread basic networking
> >>    permissions. But it is not enough yet, if the networking tunnel
> >>    is configured with labeled ipsec.
> >>    I think it can be contained in the basic networking permissions
> >>    to use ipsec SPD with default context.
> > 
> > Sounds reasonable.
> 
> The attached patch enables the above two features.
> 
> Paul mentioned to drop the checks of association:{sendto} permission and
> integrate them with the upcaming flow control checks in the future kernel.
> However, a rule of "allow <domain> self : association {sendto}" will be
> necessary for the backward compatibility.
> 
> >>> I'll consider a patch that adds it to a postresql interface.  Perhaps
> >>> postgresql_tcp_connect should be un-deprecated.
> >> I think similar interfaces are necessary for any other daemon-domain which
> >> provides networking-services, even if they don't use getpeercon().
> > 
> > The recvfrom is needed if the networking is labeled, regardless of
> > whether getpeercon() is used or not.
> 
> Do you intend to describe the labeled networking rules for each combination
> between a server domain and a client domain?

Yes.  It seems like a lot, but if you think about it, there are already
the base networking rules in the policy.  This actually gives more of an
opportunity to abstract the rules, so you get something like

interface postgresql_tcp_connect()
	corenet_tcp_sendrecv_postgresql_port($1)
	corenet_tcp_connect_postgresql_port($1)
	corenet_sendrecv_postgresql_client_packets($1)
	# labeled ipsec and (future) TE netlabel
	allow $1 postgresql_t:{ association tcp_socket } recvfrom;
	# compat labeled ipsec rule
	allow $1 self:association sendto;

and then even the labeled networking part could be put into a policy
pattern.

> Is it a considerable idea that adding a new attribute to comunicate via
> labeled ipsec with default SPD, and attaching it both a server domain and
> a client domain?
> 
> e.g)
>   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
>   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
> 
>   typeattribute postgresql_t, labeled_communicate_domain;
>   typeattribute user_t, labeled_communicate_domain;

I'm hesitant to add permissions like this as any domain that networks
can have labeled networking.  At best it seems like a stopgap measure
until interfaces like the example above are in place.

-- 
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: [PATCH] IPsec SPD default security context

[KaiGai Kohei]

>>>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
>>>>> postgresql_tcp_connect should be un-deprecated.
>>>> I think similar interfaces are necessary for any other daemon-domain which
>>>> provides networking-services, even if they don't use getpeercon().
>>> The recvfrom is needed if the networking is labeled, regardless of
>>> whether getpeercon() is used or not.
>> Do you intend to describe the labeled networking rules for each combination
>> between a server domain and a client domain?
> 
> Yes.  It seems like a lot, but if you think about it, there are already
> the base networking rules in the policy.  This actually gives more of an
> opportunity to abstract the rules, so you get something like
> 
> interface postgresql_tcp_connect()
> 	corenet_tcp_sendrecv_postgresql_port($1)
> 	corenet_tcp_connect_postgresql_port($1)
> 	corenet_sendrecv_postgresql_client_packets($1)
> 	# labeled ipsec and (future) TE netlabel
> 	allow $1 postgresql_t:{ association tcp_socket } recvfrom;

Is it necessary to add "allow postgresql_t $1 : association recvfrom" ?
(It's unclear for me, whether tcp_socket should be also, or not.)

$1 domain can receive replies from postgresql_t, but postgresql_t cannot
receive messages from $1 domain.

> 	# compat labeled ipsec rule
> 	allow $1 self:association sendto;
> 
> and then even the labeled networking part could be put into a policy
> pattern.

What does it means policy pattern?
It's a bit unclear for me whether you intend to make a new template
interface like the one defined at kernel/corenetwork.if.m4, or make
a new interface for each daemon domains.

>> Is it a considerable idea that adding a new attribute to comunicate via
>> labeled ipsec with default SPD, and attaching it both a server domain and
>> a client domain?
>>
>> e.g)
>>   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
>>   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
>>
>>   typeattribute postgresql_t, labeled_communicate_domain;
>>   typeattribute user_t, labeled_communicate_domain;
> 
> I'm hesitant to add permissions like this as any domain that networks
> can have labeled networking.  At best it seems like a stopgap measure
> until interfaces like the example above are in place.

OK, I understood it.

Is it same for the unconfined_domain_type? They can receive messages from
any domain, but the peer domain without unconfined_domain_type cannot receive
messages from unconfined_domain_type.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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: [PATCH] IPsec SPD default security context

[Christopher J. PeBenito]

On Tue, 2007-11-20 at 18:14 +0900, KaiGai Kohei wrote:
> >>>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
> >>>>> postgresql_tcp_connect should be un-deprecated.
> >>>> I think similar interfaces are necessary for any other daemon-domain which
> >>>> provides networking-services, even if they don't use getpeercon().
> >>> The recvfrom is needed if the networking is labeled, regardless of
> >>> whether getpeercon() is used or not.
> >> Do you intend to describe the labeled networking rules for each combination
> >> between a server domain and a client domain?
> > 
> > Yes.  It seems like a lot, but if you think about it, there are already
> > the base networking rules in the policy.  This actually gives more of an
> > opportunity to abstract the rules, so you get something like
> > 
> > interface postgresql_tcp_connect()
> > 	corenet_tcp_sendrecv_postgresql_port($1)
> > 	corenet_tcp_connect_postgresql_port($1)
> > 	corenet_sendrecv_postgresql_client_packets($1)
> > 	# labeled ipsec and (future) TE netlabel
> > 	allow $1 postgresql_t:{ association tcp_socket } recvfrom;
> 
> Is it necessary to add "allow postgresql_t $1 : association recvfrom" ?
> (It's unclear for me, whether tcp_socket should be also, or not.)
> 
> $1 domain can receive replies from postgresql_t, but postgresql_t cannot
> receive messages from $1 domain.

Right, you'd need both, my mistake.

> > 	# compat labeled ipsec rule
> > 	allow $1 self:association sendto;
> > 
> > and then even the labeled networking part could be put into a policy
> > pattern.
> 
> What does it means policy pattern?

Its a support macro.  See support/file_patterns.spt for file access
patterns.

> It's a bit unclear for me whether you intend to make a new template
> interface like the one defined at kernel/corenetwork.if.m4, or make
> a new interface for each daemon domains.

Each of the daemons would need it.

> >> Is it a considerable idea that adding a new attribute to comunicate via
> >> labeled ipsec with default SPD, and attaching it both a server domain and
> >> a client domain?
> >>
> >> e.g)
> >>   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
> >>   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
> >>
> >>   typeattribute postgresql_t, labeled_communicate_domain;
> >>   typeattribute user_t, labeled_communicate_domain;
> > 
> > I'm hesitant to add permissions like this as any domain that networks
> > can have labeled networking.  At best it seems like a stopgap measure
> > until interfaces like the example above are in place.
> 
> OK, I understood it.
> 
> Is it same for the unconfined_domain_type? They can receive messages from
> any domain, but the peer domain without unconfined_domain_type cannot receive
> messages from unconfined_domain_type.

Good question.  I'm not sure.

-- 
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: [PATCH] IPsec SPD default security context

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

Hi,

The attached patch provides the followins features:
 - Two new policy pattern "labeled_(tcp|udp)_pattern" are added
 - The postgresql_tcp_connect interface is revised to allow a domain
   to communicate with postgresql_t.
 - postgresql_t can communicate others via default SPD.
 - An obvious permission of "$1 self association:{sendto}" is allowed
   to any domain using ipsec_spd_t.
 - Any user-domain using core-networks can communicate others via
   default SPD.
 - Any user-domain can communicate postgresql_t via labeled networks.

>>> 	# compat labeled ipsec rule
>>> 	allow $1 self:association sendto;
>>>
>>> and then even the labeled networking part could be put into a policy
>>> pattern.
>> What does it means policy pattern?
> 
> Its a support macro.  See support/file_patterns.spt for file access
> patterns.

I see.
The attached patch provides "labeled_(tcp|udp)_pattern".

>> It's a bit unclear for me whether you intend to make a new template
>> interface like the one defined at kernel/corenetwork.if.m4, or make
>> a new interface for each daemon domains.
> 
> Each of the daemons would need it.

The attached patch revises the postgresql_tcp_connect interface
as the first one of them.

>> Is it same for the unconfined_domain_type? They can receive messages from
>> any domain, but the peer domain without unconfined_domain_type cannot receive
>> messages from unconfined_domain_type.
> 
> Good question.  I'm not sure.

There is an idea that a new boolean enables to turn on/off whether any domain
can accept labeled packets come from unconfined domain, or not.
Therefore, the attached patch does not touch the unconfined domain.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-labeled-network.2.patch --]
[-- Type: text/x-patch, Size: 4390 bytes --]

Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if	(revision 2530)
+++ refpolicy/policy/modules/services/postgresql.if	(working copy)
@@ -79,7 +79,7 @@
 
 ########################################
 ## <summary>
-##	Allow the specified domain to connect to postgresql with a tcp socket.  (Deprecated)
+##	Allow the specified domain to connect to postgresql with a tcp socket.
 ## </summary>
 ## <param name="domain">
 ##	<summary>
@@ -88,7 +88,13 @@
 ## </param>
 #
 interface(`postgresql_tcp_connect',`
-	refpolicywarn(`$0($*) has been deprecated.')
+	gen_require(`
+		type postgresql_t;
+	')
+	corenet_tcp_sendrecv_postgresql_port($1)
+	corenet_tcp_connect_postgresql_port($1)
+	corenet_sendrecv_postgresql_client_packets($1)
+	labeled_tcp_pattern($1,postgresql_t)
 ')
 
 ########################################
Index: refpolicy/policy/modules/services/apache.te
===================================================================
--- refpolicy/policy/modules/services/apache.te	(revision 2530)
+++ refpolicy/policy/modules/services/apache.te	(working copy)
@@ -369,14 +369,6 @@
 	corenet_tcp_connect_all_ports(httpd_t)
 ')
 
-tunable_policy(`httpd_can_network_connect_db',`
-	# allow httpd to connect to mysql/posgresql
-	corenet_tcp_connect_postgresql_port(httpd_t)
-	corenet_tcp_connect_mysqld_port(httpd_t)
-	corenet_sendrecv_postgresql_client_packets(httpd_t)
-	corenet_sendrecv_mysqld_client_packets(httpd_t)
-')
-
 tunable_policy(`httpd_can_network_relay',`
 	# allow httpd to work as a relay
 	corenet_tcp_connect_gopher_port(httpd_t)
@@ -457,8 +449,13 @@
 ')
 
 optional_policy(`
+	# Allow httpd to work with mysql
 	mysql_stream_connect(httpd_t)
 	mysql_rw_db_sockets(httpd_t)
+	tunable_policy(`httpd_can_network_connect_db',`
+		corenet_tcp_connect_mysqld_port(httpd_t)
+		corenet_sendrecv_mysqld_client_packets(httpd_t)
+	')
 ')
 
 optional_policy(`
@@ -476,6 +473,9 @@
 optional_policy(`
 	# Allow httpd to work with postgresql
 	postgresql_stream_connect(httpd_t)
+	tunable_policy(`httpd_can_network_connect_db',`
+		postgresql_tcp_connect(httpd_t)
+	')
 ')
 
 optional_policy(`
Index: refpolicy/policy/modules/services/postgresql.te
===================================================================
--- refpolicy/policy/modules/services/postgresql.te	(revision 2530)
+++ refpolicy/policy/modules/services/postgresql.te	(working copy)
@@ -154,6 +154,10 @@
 ')
 
 optional_policy(`
+	ipsec_match_default_spd(postgresql_t)
+')
+
+optional_policy(`
 	kerberos_use(postgresql_t)
 ')
 
Index: refpolicy/policy/modules/system/ipsec.if
===================================================================
--- refpolicy/policy/modules/system/ipsec.if	(revision 2530)
+++ refpolicy/policy/modules/system/ipsec.if	(working copy)
@@ -109,6 +109,7 @@
 	')
 
 	allow $1 ipsec_spd_t:association polmatch;
+	allow $1 self:association sendto;
 ')
 
 ########################################
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2530)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -548,6 +548,8 @@
 	corenet_udp_sendrecv_all_ports($1_t)
 	corenet_tcp_connect_all_ports($1_t)
 	corenet_sendrecv_all_client_packets($1_t)
+
+	ipsec_match_default_spd($1_t)
 ')
 
 #######################################
@@ -840,6 +842,7 @@
 	optional_policy(`
 		tunable_policy(`allow_user_postgresql_connect',`
 			postgresql_stream_connect($1_t)
+			postgresql_tcp_connect($1_t)
 		')
 	')
 
Index: refpolicy/policy/support/ipc_patterns.spt
===================================================================
--- refpolicy/policy/support/ipc_patterns.spt	(revision 2530)
+++ refpolicy/policy/support/ipc_patterns.spt	(working copy)
@@ -12,3 +12,18 @@
 	allow $1 $3:sock_file { getattr write };
 	allow $1 $4:unix_dgram_socket sendto;
 ')
+
+#
+# labeled networking patterns
+#
+define(`labeled_tcp_pattern',`
+	allow $1 $2:{association tcp_socket} recvfrom;
+	allow $2 $1:{association tcp_socket} recvfrom;
+	allow $1 self:association sendto;
+')
+
+define(`labeled_udp_pattern',`
+	allow $1 $2:{association udp_socket} recvfrom;
+	allow $2 $1:{association udp_socket} recvfrom;
+	allow $1 self:association sendto;
+')

Re: [PATCH] IPsec SPD default security context

[Christopher J. PeBenito]

On Wed, 2007-11-21 at 13:26 +0900, KaiGai Kohei wrote:
> The attached patch provides the followins features:
>  - Two new policy pattern "labeled_(tcp|udp)_pattern" are added
>  - The postgresql_tcp_connect interface is revised to allow a domain
>    to communicate with postgresql_t.
>  - postgresql_t can communicate others via default SPD.
>  - An obvious permission of "$1 self association:{sendto}" is allowed
>    to any domain using ipsec_spd_t.
>  - Any user-domain using core-networks can communicate others via
>    default SPD.
>  - Any user-domain can communicate postgresql_t via labeled networks.

Merged [1], but I made some changes.  I created corenetwork interfaces
to use instead of the patterns, so the current MLS-only netlabel case
can be handled too.  I also updated the domain module to use the
interfaces.

The thing that makes me a little nervous, which I didn't realize at
first, is if you use non-labeled networking, the peer policy will still
be needed, since the corenet connect/sendrecv calls are abstracted into
the interface.  Consider the non-labeled case for apache.  The
httpd_can_network_connect_db tunable won't work for postgresql, if the
postgresql module isn't in the apache server's policy.  Whats worse is,
to make it work, you need to bring in the entire postgresql policy, even
though you only need one type, and only need the recvfrom rules.

[1] http://oss.tresys.com/projects/refpolicy/changeset/2531

-- 
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: [PATCH] IPsec SPD default security context

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Wed, 2007-11-21 at 13:26 +0900, KaiGai Kohei wrote:
>> The attached patch provides the followins features:
>>  - Two new policy pattern "labeled_(tcp|udp)_pattern" are added
>>  - The postgresql_tcp_connect interface is revised to allow a domain
>>    to communicate with postgresql_t.
>>  - postgresql_t can communicate others via default SPD.
>>  - An obvious permission of "$1 self association:{sendto}" is allowed
>>    to any domain using ipsec_spd_t.
>>  - Any user-domain using core-networks can communicate others via
>>    default SPD.
>>  - Any user-domain can communicate postgresql_t via labeled networks.
> 
> Merged [1], but I made some changes.  I created corenetwork interfaces
> to use instead of the patterns, so the current MLS-only netlabel case
> can be handled too.  I also updated the domain module to use the
> interfaces.
> 
> The thing that makes me a little nervous, which I didn't realize at
> first, is if you use non-labeled networking, the peer policy will still
> be needed, since the corenet connect/sendrecv calls are abstracted into
> the interface.  Consider the non-labeled case for apache.  The
> httpd_can_network_connect_db tunable won't work for postgresql, if the
> postgresql module isn't in the apache server's policy.  Whats worse is,
> to make it work, you need to bring in the entire postgresql policy, even
> though you only need one type, and only need the recvfrom rules.
> 
> [1] http://oss.tresys.com/projects/refpolicy/changeset/2531

I've considered to resolve the matter for a while, but I could not get
any good idea. I think the most appropriate way is to separate corenet
part from labeled networking part again, and to put corenet sendrecv
pattern and an interface optionally to communicate via labeled networking.

I also considered a method to utilize the second argument of the
"optional_policy" macro, but it seemed to me a bit ugly more.

How do you think the idea to revert apache.te and create a new interface
to communicate via labeled networking only?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Ted X Toth]

KaiGai Kohei wrote:
>>> I also suggest two minor improvement toward these updates.
>>>
>>> 1. Is it considerable to add "allow $1 self : association { sendto };"
>>>    at ipsec_match_default_spd interface of ipsec.if?
>>>
>>>    I think it should be packed with polmatch permission to the default
>>>    SPD context, because any domain which want to communicate others using
>>>    SPD with default context always have to have 'sendto' permission to
>>>    itself.
>>>       
>> Perhaps.  Though I thought that dropping the sendto check was being
>> considered, since it really doesn't gain anything.
>>
>>     
>>> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
>>>    in the userdom_basic_networking_template of userdomain.if?
>>>
>>>    This interface allows a given userdomain widespread basic networking
>>>    permissions. But it is not enough yet, if the networking tunnel
>>>    is configured with labeled ipsec.
>>>    I think it can be contained in the basic networking permissions
>>>    to use ipsec SPD with default context.
>>>       
>> Sounds reasonable.
>>     
>
> The attached patch enables the above two features.
>
> Paul mentioned to drop the checks of association:{sendto} permission and
> integrate them with the upcaming flow control checks in the future kernel.
> However, a rule of "allow <domain> self : association {sendto}" will be
> necessary for the backward compatibility.
>
>   
>>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
>>>> postgresql_tcp_connect should be un-deprecated.
>>>>         
>>> I think similar interfaces are necessary for any other daemon-domain which
>>> provides networking-services, even if they don't use getpeercon().
>>>       
>> The recvfrom is needed if the networking is labeled, regardless of
>> whether getpeercon() is used or not.
>>     
>
> Do you intend to describe the labeled networking rules for each combination
> between a server domain and a client domain?
>
> Is it a considerable idea that adding a new attribute to comunicate via
> labeled ipsec with default SPD, and attaching it both a server domain and
> a client domain?
>
> e.g)
>   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
>   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
>
>   typeattribute postgresql_t, labeled_communicate_domain;
>   typeattribute user_t, labeled_communicate_domain;
>
> Thanks,
>   
It doesn't seem that the issue of allowing domain polmatch, sendto and
recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure
what the right answer is but I do know that ipsec is does not work with
the current policy.

--
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Christopher J. PeBenito]

On Thu, 2007-12-13 at 08:00 -0600, Ted X Toth wrote:
> KaiGai Kohei wrote:
> >>> I also suggest two minor improvement toward these updates.
> >>>
> >>> 1. Is it considerable to add "allow $1 self : association { sendto };"
> >>>    at ipsec_match_default_spd interface of ipsec.if?
> >>>
> >>>    I think it should be packed with polmatch permission to the default
> >>>    SPD context, because any domain which want to communicate others using
> >>>    SPD with default context always have to have 'sendto' permission to
> >>>    itself.
> >>>       
> >> Perhaps.  Though I thought that dropping the sendto check was being
> >> considered, since it really doesn't gain anything.
> >>
> >>     
> >>> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
> >>>    in the userdom_basic_networking_template of userdomain.if?
> >>>
> >>>    This interface allows a given userdomain widespread basic networking
> >>>    permissions. But it is not enough yet, if the networking tunnel
> >>>    is configured with labeled ipsec.
> >>>    I think it can be contained in the basic networking permissions
> >>>    to use ipsec SPD with default context.
> >>>       
> >> Sounds reasonable.
> >>     
> >
> > The attached patch enables the above two features.
> >
> > Paul mentioned to drop the checks of association:{sendto} permission and
> > integrate them with the upcaming flow control checks in the future kernel.
> > However, a rule of "allow <domain> self : association {sendto}" will be
> > necessary for the backward compatibility.
> >
> >   
> >>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
> >>>> postgresql_tcp_connect should be un-deprecated.
> >>>>         
> >>> I think similar interfaces are necessary for any other daemon-domain which
> >>> provides networking-services, even if they don't use getpeercon().
> >>>       
> >> The recvfrom is needed if the networking is labeled, regardless of
> >> whether getpeercon() is used or not.
> >>     
> >
> > Do you intend to describe the labeled networking rules for each combination
> > between a server domain and a client domain?
> >
> > Is it a considerable idea that adding a new attribute to comunicate via
> > labeled ipsec with default SPD, and attaching it both a server domain and
> > a client domain?
> >
> > e.g)
> >   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
> >   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
> >
> >   typeattribute postgresql_t, labeled_communicate_domain;
> >   typeattribute user_t, labeled_communicate_domain;
> >
> > Thanks,
> >   
> It doesn't seem that the issue of allowing domain polmatch, sendto and
> recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure
> what the right answer is but I do know that ipsec is does not work with
> the current policy.

Right, its not completely resolved at the moment.  The only labeled
networking rules are the ones that KaiGai sent, so I wouldn't expect it
to work.

-- 
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Xavier Toth]

I ask because the thread seemed to end. Is there a discussion of a
resolution off the list? Is there an issue with adding :
allow domain ipsec_spd_t : association { polmatch sendto recvfrom };


On Dec 13, 2007 8:14 AM, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
>
> On Thu, 2007-12-13 at 08:00 -0600, Ted X Toth wrote:
> > KaiGai Kohei wrote:
> > >>> I also suggest two minor improvement toward these updates.
> > >>>
> > >>> 1. Is it considerable to add "allow $1 self : association { sendto };"
> > >>>    at ipsec_match_default_spd interface of ipsec.if?
> > >>>
> > >>>    I think it should be packed with polmatch permission to the default
> > >>>    SPD context, because any domain which want to communicate others using
> > >>>    SPD with default context always have to have 'sendto' permission to
> > >>>    itself.
> > >>>
> > >> Perhaps.  Though I thought that dropping the sendto check was being
> > >> considered, since it really doesn't gain anything.
> > >>
> > >>
> > >>> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
> > >>>    in the userdom_basic_networking_template of userdomain.if?
> > >>>
> > >>>    This interface allows a given userdomain widespread basic networking
> > >>>    permissions. But it is not enough yet, if the networking tunnel
> > >>>    is configured with labeled ipsec.
> > >>>    I think it can be contained in the basic networking permissions
> > >>>    to use ipsec SPD with default context.
> > >>>
> > >> Sounds reasonable.
> > >>
> > >
> > > The attached patch enables the above two features.
> > >
> > > Paul mentioned to drop the checks of association:{sendto} permission and
> > > integrate them with the upcaming flow control checks in the future kernel.
> > > However, a rule of "allow <domain> self : association {sendto}" will be
> > > necessary for the backward compatibility.
> > >
> > >
> > >>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
> > >>>> postgresql_tcp_connect should be un-deprecated.
> > >>>>
> > >>> I think similar interfaces are necessary for any other daemon-domain which
> > >>> provides networking-services, even if they don't use getpeercon().
> > >>>
> > >> The recvfrom is needed if the networking is labeled, regardless of
> > >> whether getpeercon() is used or not.
> > >>
> > >
> > > Do you intend to describe the labeled networking rules for each combination
> > > between a server domain and a client domain?
> > >
> > > Is it a considerable idea that adding a new attribute to comunicate via
> > > labeled ipsec with default SPD, and attaching it both a server domain and
> > > a client domain?
> > >
> > > e.g)
> > >   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
> > >   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
> > >
> > >   typeattribute postgresql_t, labeled_communicate_domain;
> > >   typeattribute user_t, labeled_communicate_domain;
> > >
> > > Thanks,
> > >
> > It doesn't seem that the issue of allowing domain polmatch, sendto and
> > recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure
> > what the right answer is but I do know that ipsec is does not work with
> > the current policy.
>
> Right, its not completely resolved at the moment.  The only labeled
> networking rules are the ones that KaiGai sent, so I wouldn't expect it
> to work.
>
>
> --
> 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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Christopher J. PeBenito]

On Thu, 2007-12-13 at 08:58 -0600, Xavier Toth wrote:
> I ask because the thread seemed to end. Is there a discussion of a
> resolution off the list? Is there an issue with adding :
> allow domain ipsec_spd_t : association { polmatch sendto recvfrom };

I generally have a problem with across-the-board rules like this
upstream.  Neglecting that, the sendto/recvfrom part doesn't make much
sense since sendto should be on self and recvfrom should be on the peer
domain.

> On Dec 13, 2007 8:14 AM, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
> >
> > On Thu, 2007-12-13 at 08:00 -0600, Ted X Toth wrote:
> > > KaiGai Kohei wrote:
> > > >>> I also suggest two minor improvement toward these updates.
> > > >>>
> > > >>> 1. Is it considerable to add "allow $1 self : association { sendto };"
> > > >>>    at ipsec_match_default_spd interface of ipsec.if?
> > > >>>
> > > >>>    I think it should be packed with polmatch permission to the default
> > > >>>    SPD context, because any domain which want to communicate others using
> > > >>>    SPD with default context always have to have 'sendto' permission to
> > > >>>    itself.
> > > >>>
> > > >> Perhaps.  Though I thought that dropping the sendto check was being
> > > >> considered, since it really doesn't gain anything.
> > > >>
> > > >>
> > > >>> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
> > > >>>    in the userdom_basic_networking_template of userdomain.if?
> > > >>>
> > > >>>    This interface allows a given userdomain widespread basic networking
> > > >>>    permissions. But it is not enough yet, if the networking tunnel
> > > >>>    is configured with labeled ipsec.
> > > >>>    I think it can be contained in the basic networking permissions
> > > >>>    to use ipsec SPD with default context.
> > > >>>
> > > >> Sounds reasonable.
> > > >>
> > > >
> > > > The attached patch enables the above two features.
> > > >
> > > > Paul mentioned to drop the checks of association:{sendto} permission and
> > > > integrate them with the upcaming flow control checks in the future kernel.
> > > > However, a rule of "allow <domain> self : association {sendto}" will be
> > > > necessary for the backward compatibility.
> > > >
> > > >
> > > >>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
> > > >>>> postgresql_tcp_connect should be un-deprecated.
> > > >>>>
> > > >>> I think similar interfaces are necessary for any other daemon-domain which
> > > >>> provides networking-services, even if they don't use getpeercon().
> > > >>>
> > > >> The recvfrom is needed if the networking is labeled, regardless of
> > > >> whether getpeercon() is used or not.
> > > >>
> > > >
> > > > Do you intend to describe the labeled networking rules for each combination
> > > > between a server domain and a client domain?
> > > >
> > > > Is it a considerable idea that adding a new attribute to comunicate via
> > > > labeled ipsec with default SPD, and attaching it both a server domain and
> > > > a client domain?
> > > >
> > > > e.g)
> > > >   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
> > > >   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
> > > >
> > > >   typeattribute postgresql_t, labeled_communicate_domain;
> > > >   typeattribute user_t, labeled_communicate_domain;
> > > >
> > > > Thanks,
> > > >
> > > It doesn't seem that the issue of allowing domain polmatch, sendto and
> > > recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure
> > > what the right answer is but I do know that ipsec is does not work with
> > > the current policy.
> >
> > Right, its not completely resolved at the moment.  The only labeled
> > networking rules are the ones that KaiGai sent, so I wouldn't expect it
> > to work.
> >
> >
> > --
> > Chris PeBenito
> > Tresys Technology, LLC
> > (410) 290-1411 x150
> >
> >
-- 
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: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Xavier Toth]

Certainly I agree with you on the issue of across-the-board rules.
However something we have been doing (previously on RHEL5) is
configuring ipsec for all local connections and this is why when we
tried to get our code working on F8 it all failed because of polmatch
avcs. We are already talking about how to handle these issues, new
interfaces, our own 'domain' ... So maybe this doesn't need to be
handled in refpolicy but what I'm not yet sure about is whether other
services/servers/clients will fail if ipsec is configured for all
local connections.

As for the sendto and recvfrom I removed them from:

allow domain ipsec_spd_t : association { polmatch sendto recvfrom };

and added:

allow domain self:association { sendto recvfrom };

for now. Yes, there were recvfrom denials for self association.
(Honestly I'm not really clear on what sendto and recvfrom self
actually means.) And we will continue to work on strategy for handling
recvfrom in our servers policies.

On Dec 14, 2007 1:20 PM, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
> On Thu, 2007-12-13 at 08:58 -0600, Xavier Toth wrote:
> > I ask because the thread seemed to end. Is there a discussion of a
> > resolution off the list? Is there an issue with adding :
> > allow domain ipsec_spd_t : association { polmatch sendto recvfrom };
>
> I generally have a problem with across-the-board rules like this
> upstream.  Neglecting that, the sendto/recvfrom part doesn't make much
> sense since sendto should be on self and recvfrom should be on the peer
> domain.
>
>
> > On Dec 13, 2007 8:14 AM, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
> > >
> > > On Thu, 2007-12-13 at 08:00 -0600, Ted X Toth wrote:
> > > > KaiGai Kohei wrote:
> > > > >>> I also suggest two minor improvement toward these updates.
> > > > >>>
> > > > >>> 1. Is it considerable to add "allow $1 self : association { sendto };"
> > > > >>>    at ipsec_match_default_spd interface of ipsec.if?
> > > > >>>
> > > > >>>    I think it should be packed with polmatch permission to the default
> > > > >>>    SPD context, because any domain which want to communicate others using
> > > > >>>    SPD with default context always have to have 'sendto' permission to
> > > > >>>    itself.
> > > > >>>
> > > > >> Perhaps.  Though I thought that dropping the sendto check was being
> > > > >> considered, since it really doesn't gain anything.
> > > > >>
> > > > >>
> > > > >>> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
> > > > >>>    in the userdom_basic_networking_template of userdomain.if?
> > > > >>>
> > > > >>>    This interface allows a given userdomain widespread basic networking
> > > > >>>    permissions. But it is not enough yet, if the networking tunnel
> > > > >>>    is configured with labeled ipsec.
> > > > >>>    I think it can be contained in the basic networking permissions
> > > > >>>    to use ipsec SPD with default context.
> > > > >>>
> > > > >> Sounds reasonable.
> > > > >>
> > > > >
> > > > > The attached patch enables the above two features.
> > > > >
> > > > > Paul mentioned to drop the checks of association:{sendto} permission and
> > > > > integrate them with the upcaming flow control checks in the future kernel.
> > > > > However, a rule of "allow <domain> self : association {sendto}" will be
> > > > > necessary for the backward compatibility.
> > > > >
> > > > >
> > > > >>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
> > > > >>>> postgresql_tcp_connect should be un-deprecated.
> > > > >>>>
> > > > >>> I think similar interfaces are necessary for any other daemon-domain which
> > > > >>> provides networking-services, even if they don't use getpeercon().
> > > > >>>
> > > > >> The recvfrom is needed if the networking is labeled, regardless of
> > > > >> whether getpeercon() is used or not.
> > > > >>
> > > > >
> > > > > Do you intend to describe the labeled networking rules for each combination
> > > > > between a server domain and a client domain?
> > > > >
> > > > > Is it a considerable idea that adding a new attribute to comunicate via
> > > > > labeled ipsec with default SPD, and attaching it both a server domain and
> > > > > a client domain?
> > > > >
> > > > > e.g)
> > > > >   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
> > > > >   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
> > > > >
> > > > >   typeattribute postgresql_t, labeled_communicate_domain;
> > > > >   typeattribute user_t, labeled_communicate_domain;
> > > > >
> > > > > Thanks,
> > > > >
> > > > It doesn't seem that the issue of allowing domain polmatch, sendto and
> > > > recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure
> > > > what the right answer is but I do know that ipsec is does not work with
> > > > the current policy.
> > >
> > > Right, its not completely resolved at the moment.  The only labeled
> > > networking rules are the ones that KaiGai sent, so I wouldn't expect it
> > > to work.
> > >
> > >
> > > --
> > > Chris PeBenito
> > > Tresys Technology, LLC
> > > (410) 290-1411 x150
> > >
> > >
> --
>
> 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: [PATCH] IPsec SPD default security context

[Kohei KaiGai]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

Sorry for a long silence.

I want to resume the discussion again.

>> Merged [1], but I made some changes.  I created corenetwork interfaces
>> to use instead of the patterns, so the current MLS-only netlabel case
>> can be handled too.  I also updated the domain module to use the
>> interfaces.
>>
>> The thing that makes me a little nervous, which I didn't realize at
>> first, is if you use non-labeled networking, the peer policy will still
>> be needed, since the corenet connect/sendrecv calls are abstracted into
>> the interface.  Consider the non-labeled case for apache.  The
>> httpd_can_network_connect_db tunable won't work for postgresql, if the
>> postgresql module isn't in the apache server's policy.  Whats worse is,
>> to make it work, you need to bring in the entire postgresql policy, even
>> though you only need one type, and only need the recvfrom rules.
>>
>> [1] http://oss.tresys.com/projects/refpolicy/changeset/2531
> 
> I've considered to resolve the matter for a while, but I could not get
> any good idea. I think the most appropriate way is to separate corenet
> part from labeled networking part again, and to put corenet sendrecv
> pattern and an interface optionally to communicate via labeled networking.
> 
> I also considered a method to utilize the second argument of the
> "optional_policy" macro, but it seemed to me a bit ugly more.
> 
> How do you think the idea to revert apache.te and create a new interface
> to communicate via labeled networking only?

The attached patch revert the previous changes in postgresql.if, apache.te.
postgresql_tcp_connect() got deprecated again, and we separate the permissions
for unlabeled network and one for labeled networking.

The permissions for unlabeled network are allowed with previous way.
Ones for labeled network are allowed using corenet_tcp_recvfrom_labeled()
macro within optional_policy, because it requires the definition of peer's
domain.
In addition, ipsec_match_default_spd() is put on all domains which have
possibility to attend labeled network communication.

We can apply same process from any othe domain's policy, as follows:
1. add ipsec_match_default_spd() within definitions of domain which can
   attend lebeled network.
2. add corenet_(all|tcp|udp|raw)_recvfrom_labeled() within definitions
   of client domain.

What is your opinion?
Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-use-corenet-for-ipsec.patch --]
[-- Type: text/x-patch, Size: 3613 bytes --]

Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if	(revision 2582)
+++ refpolicy/policy/modules/services/postgresql.if	(working copy)
@@ -79,7 +79,7 @@
 
 ########################################
 ## <summary>
-##	Allow the specified domain to connect to postgresql with a tcp socket.
+##	Allow the specified domain to connect to postgresql with a tcp socket. (Deprecated)
 ## </summary>
 ## <param name="domain">
 ##	<summary>
@@ -88,14 +88,7 @@
 ## </param>
 #
 interface(`postgresql_tcp_connect',`
-	gen_require(`
-		type postgresql_t;
-	')
-
-	corenet_tcp_recvfrom_labeled($1,postgresql_t)
-	corenet_tcp_sendrecv_postgresql_port($1)
-	corenet_tcp_connect_postgresql_port($1)
-	corenet_sendrecv_postgresql_client_packets($1)
+	refpolicywarn(`$0($*) has been deprecated.')
 ')
 
 ########################################
Index: refpolicy/policy/modules/services/apache.te
===================================================================
--- refpolicy/policy/modules/services/apache.te	(revision 2582)
+++ refpolicy/policy/modules/services/apache.te	(working copy)
@@ -370,6 +370,14 @@
 	corenet_tcp_connect_all_ports(httpd_t)
 ')
 
+tunable_policy(`httpd_can_network_connect_db',`
+	# allow httpd to connect to mysql/posgresql
+	corenet_tcp_connect_postgresql_port(httpd_t)
+	corenet_tcp_connect_mysqld_port(httpd_t)
+	corenet_sendrecv_postgresql_client_packets(httpd_t)
+	corenet_sendrecv_mysqld_client_packets(httpd_t)
+')
+
 tunable_policy(`httpd_can_network_relay',`
 	# allow httpd to work as a relay
 	corenet_tcp_connect_gopher_port(httpd_t)
@@ -437,6 +445,10 @@
 ')
 
 optional_policy(`
+	ipsec_match_default_spd(httpd_t)
+')
+
+optional_policy(`
 	kerberos_use(httpd_t)
 	kerberos_read_kdc_config(httpd_t)
 ')
@@ -455,8 +467,7 @@
 	mysql_rw_db_sockets(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		corenet_tcp_connect_mysqld_port(httpd_t)
-		corenet_sendrecv_mysqld_client_packets(httpd_t)
+		corenet_tcp_recvfrom_labeled(httpd_t,mysqld_t)
 	')
 ')
 
@@ -477,7 +488,7 @@
 	postgresql_stream_connect(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		postgresql_tcp_connect(httpd_t)
+		corenet_tcp_recvfrom_labeled(httpd_t,postgresql_t)
 	')
 ')
 
Index: refpolicy/policy/modules/services/apache.if
===================================================================
--- refpolicy/policy/modules/services/apache.if	(revision 2582)
+++ refpolicy/policy/modules/services/apache.if	(working copy)
@@ -196,6 +196,11 @@
 
 		sysnet_read_config(httpd_$1_script_t)
 	')
+	optional_policy(`
+		tunable_policy(`httpd_enable_cgi && httpd_can_network_connect_db',`
+			corenet_tcp_recvfrom_labeled(httpd_$1_script_t,postgresql_t)
+		')
+	')
 
 	tunable_policy(`httpd_enable_cgi && httpd_can_network_connect',`
 		allow httpd_$1_script_t self:tcp_socket create_stream_socket_perms;
@@ -214,6 +219,9 @@
 
 		sysnet_read_config(httpd_$1_script_t)
 	')
+	optional_policy(`
+		ipsec_match_default_spd(httpd_$1_script_t)
+	')
 
 	optional_policy(`
 		mta_send_mail(httpd_$1_script_t)
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2582)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -844,7 +844,7 @@
 	optional_policy(`
 		tunable_policy(`allow_user_postgresql_connect',`
 			postgresql_stream_connect($1_t)
-			postgresql_tcp_connect($1_t)
+			corenet_tcp_recvfrom_labeled($1_t,postgresql_t)
 		')
 	')
 

[PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Kohei KaiGai]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

>>> Merged [1], but I made some changes.  I created corenetwork interfaces
>>> to use instead of the patterns, so the current MLS-only netlabel case
>>> can be handled too.  I also updated the domain module to use the
>>> interfaces.
>>>
>>> The thing that makes me a little nervous, which I didn't realize at
>>> first, is if you use non-labeled networking, the peer policy will still
>>> be needed, since the corenet connect/sendrecv calls are abstracted into
>>> the interface.  Consider the non-labeled case for apache.  The
>>> httpd_can_network_connect_db tunable won't work for postgresql, if the
>>> postgresql module isn't in the apache server's policy.  Whats worse is,
>>> to make it work, you need to bring in the entire postgresql policy, even
>>> though you only need one type, and only need the recvfrom rules.
>>>
>>> [1] http://oss.tresys.com/projects/refpolicy/changeset/2531

Chris, what is the current status of my patch submitted previously?

You pointed out that undeprecating postgresql_tcp_connect() to allow
permissions for labeled and traditional networks can make unneeded
dependency.

The attached patch reverts postgresql_tcp_connect() and related part,
and puts corenet_tcp_recvfrom_labeled() and ipsec_match_default_spd()
within optional_policy block, if necessary.
It enables any userdomain to communicate PostgreSQL/MySQL/SSHd via
labeled networking, at first.
However, I believe we can apply this method for other domains also.

Please consider to apply.
Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-use-corenet-for-ipsec.patch --]
[-- Type: text/x-patch, Size: 3411 bytes --]

Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if	(revision 2614)
+++ refpolicy/policy/modules/services/postgresql.if	(working copy)
@@ -79,7 +79,7 @@
 
 ########################################
 ## <summary>
-##	Allow the specified domain to connect to postgresql with a tcp socket.
+##	Allow the specified domain to connect to postgresql with a tcp socket.  (Deprecated)
 ## </summary>
 ## <param name="domain">
 ##	<summary>
@@ -88,14 +88,7 @@
 ## </param>
 #
 interface(`postgresql_tcp_connect',`
-	gen_require(`
-		type postgresql_t;
-	')
-
-	corenet_tcp_recvfrom_labeled($1,postgresql_t)
-	corenet_tcp_sendrecv_postgresql_port($1)
-	corenet_tcp_connect_postgresql_port($1)
-	corenet_sendrecv_postgresql_client_packets($1)
+	refpolicywarn(`$0($*) has been deprecated.')
 ')
 
 ########################################
Index: refpolicy/policy/modules/services/ssh.te
===================================================================
--- refpolicy/policy/modules/services/ssh.te	(revision 2614)
+++ refpolicy/policy/modules/services/ssh.te	(working copy)
@@ -109,6 +109,10 @@
 ')
 
 optional_policy(`
+	ipsec_match_default_spd(sshd_t)
+')
+
+optional_policy(`
 	rpm_use_script_fds(sshd_t)
 ')
 
Index: refpolicy/policy/modules/services/apache.te
===================================================================
--- refpolicy/policy/modules/services/apache.te	(revision 2614)
+++ refpolicy/policy/modules/services/apache.te	(working copy)
@@ -370,6 +370,14 @@
 	corenet_tcp_connect_all_ports(httpd_t)
 ')
 
+tunable_policy(`httpd_can_network_connect_db',`
+	# allow httpd to connect to mysql/posgresql
+	corenet_tcp_connect_postgresql_port(httpd_t)
+	corenet_tcp_connect_mysqld_port(httpd_t)
+	corenet_sendrecv_postgresql_client_packets(httpd_t)
+	corenet_sendrecv_mysqld_client_packets(httpd_t)
+')
+
 tunable_policy(`httpd_can_network_relay',`
 	# allow httpd to work as a relay
 	corenet_tcp_connect_gopher_port(httpd_t)
@@ -455,8 +463,7 @@
 	mysql_rw_db_sockets(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		corenet_tcp_connect_mysqld_port(httpd_t)
-		corenet_sendrecv_mysqld_client_packets(httpd_t)
+		corenet_tcp_recvfrom_labeled(httpd_t,mysqld_t)
 	')
 ')
 
@@ -477,7 +484,7 @@
 	postgresql_stream_connect(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		postgresql_tcp_connect(httpd_t)
+		corenet_tcp_recvfrom_labeled(httpd_t,postgresql_t)
 	')
 ')
 
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2614)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -834,6 +834,7 @@
 	optional_policy(`
 		tunable_policy(`allow_user_mysql_connect',`
 			mysql_stream_connect($1_t)
+			corenet_tcp_recvfrom_labeled($1_t,mysqld_t)
 		')
 	')
 
@@ -850,7 +851,7 @@
 	optional_policy(`
 		tunable_policy(`allow_user_postgresql_connect',`
 			postgresql_stream_connect($1_t)
-			postgresql_tcp_connect($1_t)
+			corenet_tcp_recvfrom_labeled($1_t,postgresql_t)
 		')
 	')
 
@@ -872,6 +873,13 @@
 	')
 
 	optional_policy(`
+		gen_require(`
+			type sshd_t;
+		')
+		corenet_tcp_recvfrom_labeled($1_t,sshd_t)
+	')
+
+	optional_policy(`
 		usernetctl_run($1_t,$1_r,{ $1_devpts_t $1_tty_device_t })
 	')
 ')

Re: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Christopher J. PeBenito]

On Tue, 2008-02-19 at 16:09 +0900, Kohei KaiGai wrote:
> >>> Merged [1], but I made some changes.  I created corenetwork interfaces
> >>> to use instead of the patterns, so the current MLS-only netlabel case
> >>> can be handled too.  I also updated the domain module to use the
> >>> interfaces.
> >>>
> >>> The thing that makes me a little nervous, which I didn't realize at
> >>> first, is if you use non-labeled networking, the peer policy will still
> >>> be needed, since the corenet connect/sendrecv calls are abstracted into
> >>> the interface.  Consider the non-labeled case for apache.  The
> >>> httpd_can_network_connect_db tunable won't work for postgresql, if the
> >>> postgresql module isn't in the apache server's policy.  Whats worse is,
> >>> to make it work, you need to bring in the entire postgresql policy, even
> >>> though you only need one type, and only need the recvfrom rules.
> >>>
> >>> [1] http://oss.tresys.com/projects/refpolicy/changeset/2531
> 
> Chris, what is the current status of my patch submitted previously?
> 
> You pointed out that undeprecating postgresql_tcp_connect() to allow
> permissions for labeled and traditional networks can make unneeded
> dependency.
> 
> The attached patch reverts postgresql_tcp_connect() and related part,
> and puts corenet_tcp_recvfrom_labeled() and ipsec_match_default_spd()
> within optional_policy block, if necessary.
> It enables any userdomain to communicate PostgreSQL/MySQL/SSHd via
> labeled networking, at first.
> However, I believe we can apply this method for other domains also.

The use of types outside their modules is not acceptable, for example:

+               corenet_tcp_recvfrom_labeled(httpd_t,postgresql_t)

-- 
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: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Kohei KaiGai]

Christopher J. PeBenito wrote:
> On Tue, 2008-02-19 at 16:09 +0900, Kohei KaiGai wrote:
>>>>> Merged [1], but I made some changes.  I created corenetwork interfaces
>>>>> to use instead of the patterns, so the current MLS-only netlabel case
>>>>> can be handled too.  I also updated the domain module to use the
>>>>> interfaces.
>>>>>
>>>>> The thing that makes me a little nervous, which I didn't realize at
>>>>> first, is if you use non-labeled networking, the peer policy will still
>>>>> be needed, since the corenet connect/sendrecv calls are abstracted into
>>>>> the interface.  Consider the non-labeled case for apache.  The
>>>>> httpd_can_network_connect_db tunable won't work for postgresql, if the
>>>>> postgresql module isn't in the apache server's policy.  Whats worse is,
>>>>> to make it work, you need to bring in the entire postgresql policy, even
>>>>> though you only need one type, and only need the recvfrom rules.
>>>>>
>>>>> [1] http://oss.tresys.com/projects/refpolicy/changeset/2531
>> Chris, what is the current status of my patch submitted previously?
>>
>> You pointed out that undeprecating postgresql_tcp_connect() to allow
>> permissions for labeled and traditional networks can make unneeded
>> dependency.
>>
>> The attached patch reverts postgresql_tcp_connect() and related part,
>> and puts corenet_tcp_recvfrom_labeled() and ipsec_match_default_spd()
>> within optional_policy block, if necessary.
>> It enables any userdomain to communicate PostgreSQL/MySQL/SSHd via
>> labeled networking, at first.
>> However, I believe we can apply this method for other domains also.
> 
> The use of types outside their modules is not acceptable, for example:
> 
> +               corenet_tcp_recvfrom_labeled(httpd_t,postgresql_t)

Is it acceptable one, if we provide an interface to allow a domain
to communicate postgresql_t via labeled networking, separated from
existing permissions for local ports and nodes?

For example:
-- at postgresql.if
interface(`postgresql_labeled_connect',`
	gen_require(`
		type postgresql_t;
	')
	corenet_tcp_recvfrom_labeled($1,postgresql_t)
')

and
-- at apache.te
postgresql_labeled_connect(httpd_t)

I think this approach enables to keep independency between modules
in unlabeled networking cases too.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Paul Moore]

On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
> Is it acceptable one, if we provide an interface to allow a domain
> to communicate postgresql_t via labeled networking, separated from
> existing permissions for local ports and nodes?
>
> For example:
> -- at postgresql.if
> interface(`postgresql_labeled_connect',`
> 	gen_require(`
> 		type postgresql_t;
> 	')
> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
> ')
>
> and
> -- at apache.te
> postgresql_labeled_connect(httpd_t)
>
> I think this approach enables to keep independency between modules
> in unlabeled networking cases too.

For what it is worth, it looks like a good idea to me.

-- 
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: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Kohei KaiGai]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

Paul Moore wrote:
> On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
>> Is it acceptable one, if we provide an interface to allow a domain
>> to communicate postgresql_t via labeled networking, separated from
>> existing permissions for local ports and nodes?
>>
>> For example:
>> -- at postgresql.if
>> interface(`postgresql_labeled_connect',`
>> 	gen_require(`
>> 		type postgresql_t;
>> 	')
>> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
>> ')
>>
>> and
>> -- at apache.te
>> postgresql_labeled_connect(httpd_t)
>>
>> I think this approach enables to keep independency between modules
>> in unlabeled networking cases too.
> 
> For what it is worth, it looks like a good idea to me.

At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).

This patch adds the following interfaces:
- postgresql_labeled_communicate(domain)
- mysql_labeled_communicate(domain)
- ssh_labeled_communicate(domain)

Chris, is it suitable for refpolicy framework?

Thanks
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-labeled_communicate.patch --]
[-- Type: text/x-patch, Size: 6043 bytes --]

Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if	(revision 2614)
+++ refpolicy/policy/modules/services/postgresql.if	(working copy)
@@ -79,7 +79,7 @@
 
 ########################################
 ## <summary>
-##	Allow the specified domain to connect to postgresql with a tcp socket.
+##	Allow the specified domain to connect to postgresql with a tcp socket.  (Deprecated)
 ## </summary>
 ## <param name="domain">
 ##	<summary>
@@ -88,14 +88,7 @@
 ## </param>
 #
 interface(`postgresql_tcp_connect',`
-	gen_require(`
-		type postgresql_t;
-	')
-
-	corenet_tcp_recvfrom_labeled($1,postgresql_t)
-	corenet_tcp_sendrecv_postgresql_port($1)
-	corenet_tcp_connect_postgresql_port($1)
-	corenet_sendrecv_postgresql_client_packets($1)
+	refpolicywarn(`$0($*) has been deprecated.')
 ')
 
 ########################################
@@ -120,3 +113,20 @@
         # Some versions of postgresql put the sock file in /tmp
 	allow $1 postgresql_tmp_t:sock_file write;
 ')
+
+########################################
+## <summary>
+##	Allow the specified domain to communicate with postgresql via labeled network.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`postgresql_labeled_communicate',`
+	gen_require(`
+		type postgresql_t;
+	')
+	corenet_tcp_recvfrom_labeled($1,postgresql_t)
+')
Index: refpolicy/policy/modules/services/ssh.te
===================================================================
--- refpolicy/policy/modules/services/ssh.te	(revision 2614)
+++ refpolicy/policy/modules/services/ssh.te	(working copy)
@@ -109,6 +109,10 @@
 ')
 
 optional_policy(`
+	ipsec_match_default_spd(sshd_t)
+')
+
+optional_policy(`
 	rpm_use_script_fds(sshd_t)
 ')
 
Index: refpolicy/policy/modules/services/mysql.if
===================================================================
--- refpolicy/policy/modules/services/mysql.if	(revision 2614)
+++ refpolicy/policy/modules/services/mysql.if	(working copy)
@@ -39,6 +39,23 @@
 
 ########################################
 ## <summary>
+##	Allow the specified domain to communicate with MySQL via labeled network.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`mysql_labeled_communicate',`
+	gen_require(`
+		type mysqld_t;
+	')
+	corenet_tcp_recvfrom_labeled($1,mysqld_t)
+')
+
+########################################
+## <summary>
 ##	Read MySQL configuration files.
 ## </summary>
 ## <param name="domain">
Index: refpolicy/policy/modules/services/apache.te
===================================================================
--- refpolicy/policy/modules/services/apache.te	(revision 2614)
+++ refpolicy/policy/modules/services/apache.te	(working copy)
@@ -370,6 +370,14 @@
 	corenet_tcp_connect_all_ports(httpd_t)
 ')
 
+tunable_policy(`httpd_can_network_connect_db',`
+	# allow httpd to connect to mysql/posgresql
+	corenet_tcp_connect_postgresql_port(httpd_t)
+	corenet_tcp_connect_mysqld_port(httpd_t)
+	corenet_sendrecv_postgresql_client_packets(httpd_t)
+	corenet_sendrecv_mysqld_client_packets(httpd_t)
+')
+
 tunable_policy(`httpd_can_network_relay',`
 	# allow httpd to work as a relay
 	corenet_tcp_connect_gopher_port(httpd_t)
@@ -455,8 +463,7 @@
 	mysql_rw_db_sockets(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		corenet_tcp_connect_mysqld_port(httpd_t)
-		corenet_sendrecv_mysqld_client_packets(httpd_t)
+		mysql_labeled_communicate(httpd_t)
 	')
 ')
 
@@ -477,7 +484,7 @@
 	postgresql_stream_connect(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		postgresql_tcp_connect(httpd_t)
+		postgresql_labeled_communicate(httpd_t)
 	')
 ')
 
Index: refpolicy/policy/modules/services/ssh.if
===================================================================
--- refpolicy/policy/modules/services/ssh.if	(revision 2614)
+++ refpolicy/policy/modules/services/ssh.if	(working copy)
@@ -640,6 +640,23 @@
 
 ########################################
 ## <summary>
+##	Allow the specified domain to communicate with SSH daemons via labeled network.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`ssh_labeled_communicate',`
+	gen_require(`
+		type sshd_t;
+	')
+	corenet_tcp_recvfrom_labeled($1,sshd_t)
+')
+
+########################################
+## <summary>
 ##	Execute the ssh daemon sshd domain.
 ## </summary>
 ## <param name="domain">
Index: refpolicy/policy/modules/services/apache.if
===================================================================
--- refpolicy/policy/modules/services/apache.if	(revision 2614)
+++ refpolicy/policy/modules/services/apache.if	(working copy)
@@ -226,6 +226,18 @@
 	')
 
 	optional_policy(`
+		tunable_policy(`httpd_enable_cgi && httpd_can_network_connect_db',`
+			mysql_labeled_communicate(httpd_$1_script_t)
+		')
+	')
+
+	optional_policy(`
+		tunable_policy(`httpd_enable_cgi && httpd_can_network_connect_db',`
+			postgresql_labeled_communicate(httpd_$1_script_t)
+		')
+	')
+
+	optional_policy(`
 		nscd_socket_use(httpd_$1_script_t)
 	')
 ')
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2614)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -834,6 +834,7 @@
 	optional_policy(`
 		tunable_policy(`allow_user_mysql_connect',`
 			mysql_stream_connect($1_t)
+			mysql_labeled_communicate($1_t)
 		')
 	')
 
@@ -850,7 +851,7 @@
 	optional_policy(`
 		tunable_policy(`allow_user_postgresql_connect',`
 			postgresql_stream_connect($1_t)
-			postgresql_tcp_connect($1_t)
+			postgresql_labeled_communicate($1_t)
 		')
 	')
 
@@ -872,6 +873,10 @@
 	')
 
 	optional_policy(`
+		ssh_labeled_communicate($1_t)
+	')
+
+	optional_policy(`
 		usernetctl_run($1_t,$1_r,{ $1_devpts_t $1_tty_device_t })
 	')
 ')

Re: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Paul Moore]

On Wednesday 20 February 2008 12:11:56 am Kohei KaiGai wrote:
> Paul Moore wrote:
> > On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
> >> Is it acceptable one, if we provide an interface to allow a domain
> >> to communicate postgresql_t via labeled networking, separated from
> >> existing permissions for local ports and nodes?
> >>
> >> For example:
> >> -- at postgresql.if
> >> interface(`postgresql_labeled_connect',`
> >> 	gen_require(`
> >> 		type postgresql_t;
> >> 	')
> >> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
> >> ')
> >>
> >> and
> >> -- at apache.te
> >> postgresql_labeled_connect(httpd_t)
> >>
> >> I think this approach enables to keep independency between modules
> >> in unlabeled networking cases too.
> >
> > For what it is worth, it looks like a good idea to me.
>
> At first, I implemented this idea for three services
> (PostgreSQL/MySQL/SSHd).
>
> This patch adds the following interfaces:
> - postgresql_labeled_communicate(domain)
> - mysql_labeled_communicate(domain)
> - ssh_labeled_communicate(domain)

If this approach is approved by everyone else, I think we would want to add 
similar interfaces to all of the network facing daemons in the policy.  I 
know it's a lot of work but it's the right thing to do.

> Chris, is it suitable for refpolicy framework?

-- 
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: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Christopher J. PeBenito]

On Wed, 2008-02-20 at 14:11 +0900, Kohei KaiGai wrote:
> Paul Moore wrote:
> > On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
> >> Is it acceptable one, if we provide an interface to allow a domain
> >> to communicate postgresql_t via labeled networking, separated from
> >> existing permissions for local ports and nodes?
> >>
> >> For example:
> >> -- at postgresql.if
> >> interface(`postgresql_labeled_connect',`
> >> 	gen_require(`
> >> 		type postgresql_t;
> >> 	')
> >> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
> >> ')
> >>
> >> and
> >> -- at apache.te
> >> postgresql_labeled_connect(httpd_t)
> >>
> >> I think this approach enables to keep independency between modules
> >> in unlabeled networking cases too.
> > 
> > For what it is worth, it looks like a good idea to me.
> 
> At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).
> 
> This patch adds the following interfaces:
> - postgresql_labeled_communicate(domain)
> - mysql_labeled_communicate(domain)
> - ssh_labeled_communicate(domain)
> 
> Chris, is it suitable for refpolicy framework?

The only issue I have with it would just be the interface naming;
probably something like mysql_tcp_recvfrom() would be better.

-- 
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: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Christopher J. PeBenito]

On Wed, 2008-02-20 at 09:18 -0500, Paul Moore wrote:
> On Wednesday 20 February 2008 12:11:56 am Kohei KaiGai wrote:
> > Paul Moore wrote:
> > > On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
[...]
> > >> For example:
> > >> -- at postgresql.if
> > >> interface(`postgresql_labeled_connect',`
> > >> 	gen_require(`
> > >> 		type postgresql_t;
> > >> 	')
> > >> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
> > >> ')
> > >>
> > >> and
> > >> -- at apache.te
> > >> postgresql_labeled_connect(httpd_t)
> > >>
[...]
> > This patch adds the following interfaces:
> > - postgresql_labeled_communicate(domain)
> > - mysql_labeled_communicate(domain)
> > - ssh_labeled_communicate(domain)
> 
> If this approach is approved by everyone else, I think we would want to add 
> similar interfaces to all of the network facing daemons in the policy.  I 
> know it's a lot of work but it's the right thing to do.

I agree.

-- 
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: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Kohei KaiGai]

Christopher J. PeBenito wrote:
> On Wed, 2008-02-20 at 14:11 +0900, Kohei KaiGai wrote:
>> Paul Moore wrote:
>>> On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
>>>> Is it acceptable one, if we provide an interface to allow a domain
>>>> to communicate postgresql_t via labeled networking, separated from
>>>> existing permissions for local ports and nodes?
>>>>
>>>> For example:
>>>> -- at postgresql.if
>>>> interface(`postgresql_labeled_connect',`
>>>> 	gen_require(`
>>>> 		type postgresql_t;
>>>> 	')
>>>> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
>>>> ')
>>>>
>>>> and
>>>> -- at apache.te
>>>> postgresql_labeled_connect(httpd_t)
>>>>
>>>> I think this approach enables to keep independency between modules
>>>> in unlabeled networking cases too.
>>> For what it is worth, it looks like a good idea to me.
>> At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).
>>
>> This patch adds the following interfaces:
>> - postgresql_labeled_communicate(domain)
>> - mysql_labeled_communicate(domain)
>> - ssh_labeled_communicate(domain)
>>
>> Chris, is it suitable for refpolicy framework?
> 
> The only issue I have with it would just be the interface naming;
> probably something like mysql_tcp_recvfrom() would be better.

I think the name of "xxxx_tcp_recvfrom()" is not obvious whether it means
permissions related to labeled networking, or not.

What do you think the following ideas?
 - something_labeled_recvfrom(domain)
      or
 - something_labeled_tcp_recvfrom(domain)

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[KaiGai Kohei]

Kohei KaiGai wrote:
> Christopher J. PeBenito wrote:
>> On Wed, 2008-02-20 at 14:11 +0900, Kohei KaiGai wrote:
>>> Paul Moore wrote:
>>>> On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
>>>>> Is it acceptable one, if we provide an interface to allow a domain
>>>>> to communicate postgresql_t via labeled networking, separated from
>>>>> existing permissions for local ports and nodes?
>>>>>
>>>>> For example:
>>>>> -- at postgresql.if
>>>>> interface(`postgresql_labeled_connect',`
>>>>> 	gen_require(`
>>>>> 		type postgresql_t;
>>>>> 	')
>>>>> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
>>>>> ')
>>>>>
>>>>> and
>>>>> -- at apache.te
>>>>> postgresql_labeled_connect(httpd_t)
>>>>>
>>>>> I think this approach enables to keep independency between modules
>>>>> in unlabeled networking cases too.
>>>> For what it is worth, it looks like a good idea to me.
>>> At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).
>>>
>>> This patch adds the following interfaces:
>>> - postgresql_labeled_communicate(domain)
>>> - mysql_labeled_communicate(domain)
>>> - ssh_labeled_communicate(domain)
>>>
>>> Chris, is it suitable for refpolicy framework?
>> The only issue I have with it would just be the interface naming;
>> probably something like mysql_tcp_recvfrom() would be better.
> 
> I think the name of "xxxx_tcp_recvfrom()" is not obvious whether it means
> permissions related to labeled networking, or not.
> 
> What do you think the following ideas?
>  - something_labeled_recvfrom(domain)
>       or
>  - something_labeled_tcp_recvfrom(domain)
> 
> Thanks,

Oops, I found out this topic has not been progressed for a long time.

An interface of corenet_*_recvfrom_labeled(dom1, dom2) is
provided in the latest policy, but nobody uses it except
for a few cases like:
 - communication between unconfined domain and any other domain.
 - communication between httpd_t and postgresql_t.

In the previous discussion, you were hesitant to add permissions
which allows to communicate between widespread domains, so we
made a decision to put per-domain interfaces as above.

At first, could you fix its naming scheme?
I think somethind_labeled_tcp_recvfrom(domain) is more obvious
to show its meanings.

And, I'm worried about massive enumeration of these interfaces
at userdom_basic_networking_template.
Currently, it allows widespread permissions toward any nodes,
port and interfaces.
I don't think "daemon_labeled_tcp_recvfrom($1_t)" here makes
security degrading. Is it reasonable to allow to communicate
between userdomains and daemon attribute?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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

[PATCH] Communication between domains under labeled networks

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

Hi,

The attached patch allows user domains to communicate with daemon
domain, and some other domains (Apache and CGI script) to communicate
with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.

This approach enables to cover most of relationship needed.
All we have to do is to describe the rest of relationship like
ones between CGI script and RDBMS, daemons and name server,
anything and samba server, ....

At least, we cannot get labeled networks available unless adding
policies to communicate between proper domains.
I think it is necessary to make a decision to describe the policies.

Thanks,

KaiGai Kohei wrote:
> Kohei KaiGai wrote:
>> Christopher J. PeBenito wrote:
>>> On Wed, 2008-02-20 at 14:11 +0900, Kohei KaiGai wrote:
>>>> Paul Moore wrote:
>>>>> On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
>>>>>> Is it acceptable one, if we provide an interface to allow a domain
>>>>>> to communicate postgresql_t via labeled networking, separated from
>>>>>> existing permissions for local ports and nodes?
>>>>>>
>>>>>> For example:
>>>>>> -- at postgresql.if
>>>>>> interface(`postgresql_labeled_connect',`
>>>>>> 	gen_require(`
>>>>>> 		type postgresql_t;
>>>>>> 	')
>>>>>> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
>>>>>> ')
>>>>>>
>>>>>> and
>>>>>> -- at apache.te
>>>>>> postgresql_labeled_connect(httpd_t)
>>>>>>
>>>>>> I think this approach enables to keep independency between modules
>>>>>> in unlabeled networking cases too.
>>>>> For what it is worth, it looks like a good idea to me.
>>>> At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).
>>>>
>>>> This patch adds the following interfaces:
>>>> - postgresql_labeled_communicate(domain)
>>>> - mysql_labeled_communicate(domain)
>>>> - ssh_labeled_communicate(domain)
>>>>
>>>> Chris, is it suitable for refpolicy framework?
>>> The only issue I have with it would just be the interface naming;
>>> probably something like mysql_tcp_recvfrom() would be better.
>> I think the name of "xxxx_tcp_recvfrom()" is not obvious whether it means
>> permissions related to labeled networking, or not.
>>
>> What do you think the following ideas?
>>  - something_labeled_recvfrom(domain)
>>       or
>>  - something_labeled_tcp_recvfrom(domain)
>>
>> Thanks,
> 
> Oops, I found out this topic has not been progressed for a long time.
> 
> An interface of corenet_*_recvfrom_labeled(dom1, dom2) is
> provided in the latest policy, but nobody uses it except
> for a few cases like:
>  - communication between unconfined domain and any other domain.
>  - communication between httpd_t and postgresql_t.
> 
> In the previous discussion, you were hesitant to add permissions
> which allows to communicate between widespread domains, so we
> made a decision to put per-domain interfaces as above.
> 
> At first, could you fix its naming scheme?
> I think somethind_labeled_tcp_recvfrom(domain) is more obvious
> to show its meanings.
> 
> And, I'm worried about massive enumeration of these interfaces
> at userdom_basic_networking_template.
> Currently, it allows widespread permissions toward any nodes,
> port and interfaces.
> I don't think "daemon_labeled_tcp_recvfrom($1_t)" here makes
> security degrading. Is it reasonable to allow to communicate
> between userdomains and daemon attribute?
> 
> Thanks,


-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-labeled_communication.2.patch --]
[-- Type: text/x-patch, Size: 3875 bytes --]

Index: refpolicy/policy/modules/services/mysql.if
===================================================================
--- refpolicy/policy/modules/services/mysql.if	(revision 2733)
+++ refpolicy/policy/modules/services/mysql.if	(working copy)
@@ -20,6 +20,27 @@
 
 ########################################
 ## <summary>
+##	Allow the specified domain to connect to postgresql with a tcp socket.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`mysql_tcp_connect',`
+	gen_require(`
+		type mysqld_t;
+	')
+
+	corenet_tcp_recvfrom_labeled($1,mysqld_t)
+	corenet_tcp_sendrecv_mysqld_port($1)
+	corenet_tcp_connect_mysqld_port($1)
+	corenet_sendrecv_mysqld_client_packets($1)
+')
+
+########################################
+## <summary>
 ##	Connect to MySQL using a unix domain stream socket.
 ## </summary>
 ## <param name="domain">
Index: refpolicy/policy/modules/services/apache.te
===================================================================
--- refpolicy/policy/modules/services/apache.te	(revision 2733)
+++ refpolicy/policy/modules/services/apache.te	(working copy)
@@ -455,8 +455,7 @@
 	mysql_rw_db_sockets(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		corenet_tcp_connect_mysqld_port(httpd_t)
-		corenet_sendrecv_mysqld_client_packets(httpd_t)
+		mysql_tcp_connect(httpd_t)
 	')
 ')
 
Index: refpolicy/policy/modules/services/apache.if
===================================================================
--- refpolicy/policy/modules/services/apache.if	(revision 2733)
+++ refpolicy/policy/modules/services/apache.if	(working copy)
@@ -189,10 +189,8 @@
 		corenet_udp_sendrecv_all_nodes(httpd_$1_script_t)
 		corenet_tcp_sendrecv_all_ports(httpd_$1_script_t)
 		corenet_udp_sendrecv_all_ports(httpd_$1_script_t)
-		corenet_tcp_connect_postgresql_port(httpd_$1_script_t)
-		corenet_tcp_connect_mysqld_port(httpd_$1_script_t)
-		corenet_sendrecv_postgresql_client_packets(httpd_$1_script_t)
-		corenet_sendrecv_mysqld_client_packets(httpd_$1_script_t)
+		postgresql_tcp_connect(httpd_$1_script_t)
+		mysql_tcp_connect(httpd_$1_script_t)
 
 		sysnet_read_config(httpd_$1_script_t)
 	')
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2733)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -549,7 +549,14 @@
 	corenet_tcp_connect_all_ports($1_t)
 	corenet_sendrecv_all_client_packets($1_t)
 
+	corenet_all_recvfrom_labeled($1_t, $1_t)
+
 	optional_policy(`
+		daemon_labeled_tcp_recvfrom($1_t)
+		daemon_labeled_udp_recvfrom($1_t)
+	')
+
+	optional_policy(`
 		ipsec_match_default_spd($1_t)
 	')
 ')
Index: refpolicy/policy/modules/system/init.if
===================================================================
--- refpolicy/policy/modules/system/init.if	(revision 2733)
+++ refpolicy/policy/modules/system/init.if	(working copy)
@@ -1273,3 +1273,37 @@
 	files_search_pids($1)
 	allow $1 initrc_var_run_t:file manage_file_perms;
 ')
+
+########################################
+## <summary>
+##      Allow the specified domain to connect to daemon with a tcp socket
+## </summary>
+## <param name="domain">
+##      <summary>
+##      Domain allowed access.
+##      </summary>
+## </param>
+#
+interface(`daemon_labeled_tcp_recvfrom',`
+	gen_require(`
+		attribute daemon;
+	')
+	corenet_tcp_recvfrom_labeled($1,daemon)
+')
+
+########################################
+## <summary>
+##      Allow the specified domain to connect to daemon with a udp socket
+## </summary>
+## <param name="domain">
+##      <summary>
+##      Domain allowed access.
+##      </summary>
+## </param>
+#
+interface(`daemon_labeled_udp_recvfrom',`
+	gen_require(`
+		attribute daemon;
+	')
+	corenet_udp_recvfrom_labeled($1,daemon)
+')

Re: [PATCH] Labeled IPsec for PostgreSQL/MySQL/SSHd (Re: [PATCH] IPsec SPD default security context)

[Christopher J. PeBenito]

On Tue, 2008-06-24 at 18:10 +0900, KaiGai Kohei wrote:
> Kohei KaiGai wrote:
> > Christopher J. PeBenito wrote:
> >> On Wed, 2008-02-20 at 14:11 +0900, Kohei KaiGai wrote:
> >>> Paul Moore wrote:
> >>>> On Tuesday 19 February 2008 7:59:22 pm Kohei KaiGai wrote:
> >>>>> Is it acceptable one, if we provide an interface to allow a domain
> >>>>> to communicate postgresql_t via labeled networking, separated from
> >>>>> existing permissions for local ports and nodes?
> >>>>>
> >>>>> For example:
> >>>>> -- at postgresql.if
> >>>>> interface(`postgresql_labeled_connect',`
> >>>>> 	gen_require(`
> >>>>> 		type postgresql_t;
> >>>>> 	')
> >>>>> 	corenet_tcp_recvfrom_labeled($1,postgresql_t)
> >>>>> ')
> >>>>>
> >>>>> and
> >>>>> -- at apache.te
> >>>>> postgresql_labeled_connect(httpd_t)
> >>>>>
> >>>>> I think this approach enables to keep independency between modules
> >>>>> in unlabeled networking cases too.
> >>>> For what it is worth, it looks like a good idea to me.
> >>> At first, I implemented this idea for three services (PostgreSQL/MySQL/SSHd).
> >>>
> >>> This patch adds the following interfaces:
> >>> - postgresql_labeled_communicate(domain)
> >>> - mysql_labeled_communicate(domain)
> >>> - ssh_labeled_communicate(domain)
> >>>
> >>> Chris, is it suitable for refpolicy framework?
> >> The only issue I have with it would just be the interface naming;
> >> probably something like mysql_tcp_recvfrom() would be better.
> > 
> > I think the name of "xxxx_tcp_recvfrom()" is not obvious whether it means
> > permissions related to labeled networking, or not.
> > 
> > What do you think the following ideas?
> >  - something_labeled_recvfrom(domain)
> >       or
> >  - something_labeled_tcp_recvfrom(domain)
> > 
> > Thanks,
> 
> Oops, I found out this topic has not been progressed for a long time.
> 
> An interface of corenet_*_recvfrom_labeled(dom1, dom2) is
> provided in the latest policy, but nobody uses it except
> for a few cases like:
>  - communication between unconfined domain and any other domain.
>  - communication between httpd_t and postgresql_t.
> 
> In the previous discussion, you were hesitant to add permissions
> which allows to communicate between widespread domains, so we
> made a decision to put per-domain interfaces as above.
> 
> At first, could you fix its naming scheme?
> I think somethind_labeled_tcp_recvfrom(domain) is more obvious
> to show its meanings.

Thats fine.  Its consistent with refpolicy naming.  e.g.
apache_tcp_recvfrom() would be fine.

> And, I'm worried about massive enumeration of these interfaces
> at userdom_basic_networking_template.
> Currently, it allows widespread permissions toward any nodes,
> port and interfaces.
> I don't think "daemon_labeled_tcp_recvfrom($1_t)" here makes
> security degrading. Is it reasonable to allow to communicate
> between userdomains and daemon attribute?

Yes, thats fine.

-- 
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: [PATCH] Communication between domains under labeled networks

[Christopher J. PeBenito]

On Wed, 2008-06-25 at 14:59 +0900, KaiGai Kohei wrote:
> Hi,
> 
> The attached patch allows user domains to communicate with daemon
> domain, and some other domains (Apache and CGI script) to communicate
> with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.
> 
> This approach enables to cover most of relationship needed.
> All we have to do is to describe the rest of relationship like
> ones between CGI script and RDBMS, daemons and name server,
> anything and samba server, ....
> 
> At least, we cannot get labeled networks available unless adding
> policies to communicate between proper domains.
> I think it is necessary to make a decision to describe the policies.

> 
> 
> 
> 
> 
> differences
> between files
> attachment
> (refpolicy-labeled_communication.2.patch)


> Index: refpolicy/policy/modules/services/apache.if
> ===================================================================
> --- refpolicy/policy/modules/services/apache.if (revision 2733)
> +++ refpolicy/policy/modules/services/apache.if (working copy)
> @@ -189,10 +189,8 @@
>                 corenet_udp_sendrecv_all_nodes(httpd_$1_script_t)
>                 corenet_tcp_sendrecv_all_ports(httpd_$1_script_t)
>                 corenet_udp_sendrecv_all_ports(httpd_$1_script_t)
> -               corenet_tcp_connect_postgresql_port(httpd_$1_script_t)
> -               corenet_tcp_connect_mysqld_port(httpd_$1_script_t)
> -               corenet_sendrecv_postgresql_client_packets(httpd_
> $1_script_t)
> -               corenet_sendrecv_mysqld_client_packets(httpd_
> $1_script_t)
> +               postgresql_tcp_connect(httpd_$1_script_t)
> +               mysql_tcp_connect(httpd_$1_script_t)
>  
>                 sysnet_read_config(httpd_$1_script_t)
>         ')

In this case, we want to break out the two databases into individual
optionals, e.g.

optional_policy(`
   tunable_policy(`.... && ....',`
      mysql_tcp_connect()
   ')
')

In fact we may want to just duplicate the whole tunable since the other
perms don't make much sense if you cant connect to mysql or postgresql.

> Index: refpolicy/policy/modules/system/init.if
> ===================================================================
> --- refpolicy/policy/modules/system/init.if     (revision 2733)
> +++ refpolicy/policy/modules/system/init.if     (working copy)
> @@ -1273,3 +1273,37 @@
>         files_search_pids($1)
>         allow $1 initrc_var_run_t:file manage_file_perms;
>  ')
[...]
> +interface(`daemon_labeled_tcp_recvfrom',`
> +       gen_require(`
> +               attribute daemon;
> +       ')
> +       corenet_tcp_recvfrom_labeled($1,daemon)
> +')
> +
[...]
> +interface(`daemon_labeled_udp_recvfrom',`
> +       gen_require(`
> +               attribute daemon;
> +       ')
> +       corenet_udp_recvfrom_labeled($1,daemon)
> +')
> 

Both interfaces need naming fixes.  init_tcp_recvfrom_all_daemons() and
init_udp_recvfrom_all_daemons().

-- 
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: [PATCH] Communication between domains under labeled networks

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 3579 bytes --]

Christopher J. PeBenito wrote:
> On Wed, 2008-06-25 at 14:59 +0900, KaiGai Kohei wrote:
>> Hi,
>>
>> The attached patch allows user domains to communicate with daemon
>> domain, and some other domains (Apache and CGI script) to communicate
>> with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.
>>
>> This approach enables to cover most of relationship needed.
>> All we have to do is to describe the rest of relationship like
>> ones between CGI script and RDBMS, daemons and name server,
>> anything and samba server, ....
>>
>> At least, we cannot get labeled networks available unless adding
>> policies to communicate between proper domains.
>> I think it is necessary to make a decision to describe the policies.
> 
>>
>>
>>
>>
>> differences
>> between files
>> attachment
>> (refpolicy-labeled_communication.2.patch)

The attached patch is a revised version.
Please review it again.

And I also noticed that ipsec_match_default_spd() should be invoked with
server's domain as postgresql_t doing.
(e.g: communication between staff_t and sshd_t)
I think it also should be allowed for whole of daemon attribute.
What is your opinion? The version.3 patch also contains this fix.


>> Index: refpolicy/policy/modules/services/apache.if
>> ===================================================================
>> --- refpolicy/policy/modules/services/apache.if (revision 2733)
>> +++ refpolicy/policy/modules/services/apache.if (working copy)
>> @@ -189,10 +189,8 @@
>>                 corenet_udp_sendrecv_all_nodes(httpd_$1_script_t)
>>                 corenet_tcp_sendrecv_all_ports(httpd_$1_script_t)
>>                 corenet_udp_sendrecv_all_ports(httpd_$1_script_t)
>> -               corenet_tcp_connect_postgresql_port(httpd_$1_script_t)
>> -               corenet_tcp_connect_mysqld_port(httpd_$1_script_t)
>> -               corenet_sendrecv_postgresql_client_packets(httpd_
>> $1_script_t)
>> -               corenet_sendrecv_mysqld_client_packets(httpd_
>> $1_script_t)
>> +               postgresql_tcp_connect(httpd_$1_script_t)
>> +               mysql_tcp_connect(httpd_$1_script_t)
>>  
>>                 sysnet_read_config(httpd_$1_script_t)
>>         ')
> 
> In this case, we want to break out the two databases into individual
> optionals, e.g.
> 
> optional_policy(`
>    tunable_policy(`.... && ....',`
>       mysql_tcp_connect()
>    ')
> ')

OK, these are separated from the tunable block.


> In fact we may want to just duplicate the whole tunable since the other
> perms don't make much sense if you cant connect to mysql or postgresql.
> 
>> Index: refpolicy/policy/modules/system/init.if
>> ===================================================================
>> --- refpolicy/policy/modules/system/init.if     (revision 2733)
>> +++ refpolicy/policy/modules/system/init.if     (working copy)
>> @@ -1273,3 +1273,37 @@
>>         files_search_pids($1)
>>         allow $1 initrc_var_run_t:file manage_file_perms;
>>  ')
> [...]
>> +interface(`daemon_labeled_tcp_recvfrom',`
>> +       gen_require(`
>> +               attribute daemon;
>> +       ')
>> +       corenet_tcp_recvfrom_labeled($1,daemon)
>> +')
>> +
> [...]
>> +interface(`daemon_labeled_udp_recvfrom',`
>> +       gen_require(`
>> +               attribute daemon;
>> +       ')
>> +       corenet_udp_recvfrom_labeled($1,daemon)
>> +')
>>
> 
> Both interfaces need naming fixes.  init_tcp_recvfrom_all_daemons() and
> init_udp_recvfrom_all_daemons().

OK, these are renamed.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-labeled_communication.3.patch --]
[-- Type: text/x-patch, Size: 5055 bytes --]

Index: refpolicy/policy/modules/services/mysql.if
===================================================================
--- refpolicy/policy/modules/services/mysql.if	(revision 2762)
+++ refpolicy/policy/modules/services/mysql.if	(working copy)
@@ -20,6 +20,27 @@
 
 ########################################
 ## <summary>
+##	Allow the specified domain to connect to postgresql with a tcp socket.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`mysql_tcp_connect',`
+	gen_require(`
+		type mysqld_t;
+	')
+
+	corenet_tcp_recvfrom_labeled($1,mysqld_t)
+	corenet_tcp_sendrecv_mysqld_port($1)
+	corenet_tcp_connect_mysqld_port($1)
+	corenet_sendrecv_mysqld_client_packets($1)
+')
+
+########################################
+## <summary>
 ##	Connect to MySQL using a unix domain stream socket.
 ## </summary>
 ## <param name="domain">
Index: refpolicy/policy/modules/services/apache.te
===================================================================
--- refpolicy/policy/modules/services/apache.te	(revision 2762)
+++ refpolicy/policy/modules/services/apache.te	(working copy)
@@ -459,8 +459,7 @@
 	mysql_rw_db_sockets(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
-		corenet_tcp_connect_mysqld_port(httpd_t)
-		corenet_sendrecv_mysqld_client_packets(httpd_t)
+		mysql_tcp_connect(httpd_t)
 	')
 ')
 
Index: refpolicy/policy/modules/services/apache.if
===================================================================
--- refpolicy/policy/modules/services/apache.if	(revision 2762)
+++ refpolicy/policy/modules/services/apache.if	(working copy)
@@ -189,14 +189,22 @@
 		corenet_udp_sendrecv_all_nodes(httpd_$1_script_t)
 		corenet_tcp_sendrecv_all_ports(httpd_$1_script_t)
 		corenet_udp_sendrecv_all_ports(httpd_$1_script_t)
-		corenet_tcp_connect_postgresql_port(httpd_$1_script_t)
-		corenet_tcp_connect_mysqld_port(httpd_$1_script_t)
-		corenet_sendrecv_postgresql_client_packets(httpd_$1_script_t)
-		corenet_sendrecv_mysqld_client_packets(httpd_$1_script_t)
 
 		sysnet_read_config(httpd_$1_script_t)
 	')
 
+	optional_policy(`
+		tunable_policy(`httpd_enable_cgi && httpd_can_network_connect_db',`
+			mysql_tcp_connect(httpd_$1_script_t)
+		')
+	')
+
+	optional_policy(`
+		tunable_policy(`httpd_enable_cgi && httpd_can_network_connect_db',`
+			postgresql_tcp_connect(httpd_$1_script_t)
+		')
+	')
+
 	tunable_policy(`httpd_enable_cgi && httpd_can_network_connect',`
 		allow httpd_$1_script_t self:tcp_socket create_stream_socket_perms;
 		allow httpd_$1_script_t self:udp_socket create_socket_perms;
Index: refpolicy/policy/modules/services/postgresql.te
===================================================================
--- refpolicy/policy/modules/services/postgresql.te	(revision 2762)
+++ refpolicy/policy/modules/services/postgresql.te	(working copy)
@@ -245,10 +245,6 @@
 ')
 
 optional_policy(`
-	ipsec_match_default_spd(postgresql_t)
-')
-
-optional_policy(`
 	kerberos_use(postgresql_t)
 ')
 
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2762)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -549,7 +549,14 @@
 	corenet_tcp_connect_all_ports($1_t)
 	corenet_sendrecv_all_client_packets($1_t)
 
+	corenet_all_recvfrom_labeled($1_t, $1_t)
+
 	optional_policy(`
+		init_tcp_recvfrom_all_daemons($1_t)
+		init_udp_recvfrom_all_daemons($1_t)
+	')
+
+	optional_policy(`
 		ipsec_match_default_spd($1_t)
 	')
 ')
Index: refpolicy/policy/modules/system/init.te
===================================================================
--- refpolicy/policy/modules/system/init.te	(revision 2762)
+++ refpolicy/policy/modules/system/init.te	(working copy)
@@ -609,6 +609,8 @@
 optional_policy(`
 	ipsec_read_config(initrc_t)
 	ipsec_manage_pid(initrc_t)
+
+	ipsec_match_default_spd(daemon)
 ')
 
 optional_policy(`
Index: refpolicy/policy/modules/system/init.if
===================================================================
--- refpolicy/policy/modules/system/init.if	(revision 2762)
+++ refpolicy/policy/modules/system/init.if	(working copy)
@@ -1283,3 +1283,37 @@
 	files_search_pids($1)
 	allow $1 initrc_var_run_t:file manage_file_perms;
 ')
+
+########################################
+## <summary>
+##	Allow the specified domain to connect to daemon with a tcp socket
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`init_tcp_recvfrom_all_daemons',`
+	gen_require(`
+		attribute daemon;
+	')
+	corenet_tcp_recvfrom_labeled($1,daemon)
+')
+
+########################################
+## <summary>
+##	Allow the specified domain to connect to daemon with a udp socket
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`init_udp_recvfrom_all_daemons',`
+	gen_require(`
+		attribute daemon;
+	')
+	corenet_udp_recvfrom_labeled($1,daemon)
+')

Re: [PATCH] Communication between domains under labeled networks

[Chris PeBenito]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

On Tue, 2008-07-22 at 19:49 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Wed, 2008-06-25 at 14:59 +0900, KaiGai Kohei wrote:
> >> Hi,
> >>
> >> The attached patch allows user domains to communicate with daemon
> >> domain, and some other domains (Apache and CGI script) to communicate
> >> with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.
> >>
> >> This approach enables to cover most of relationship needed.
> >> All we have to do is to describe the rest of relationship like
> >> ones between CGI script and RDBMS, daemons and name server,
> >> anything and samba server, ....
> >>
> >> At least, we cannot get labeled networks available unless adding
> >> policies to communicate between proper domains.
> >> I think it is necessary to make a decision to describe the policies.

> The attached patch is a revised version.
> Please review it again.
> 
> And I also noticed that ipsec_match_default_spd() should be invoked with
> server's domain as postgresql_t doing.
> (e.g: communication between staff_t and sshd_t)
> I think it also should be allowed for whole of daemon attribute.
> What is your opinion? The version.3 patch also contains this fix.

I merged everything except for the default spd part.  I don't know if
its been suggested before, but I'm considering putting that match rule
into corenet_*_recvfrom_unlabeled().

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Communication between domains under labeled networks

[KaiGai Kohei]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

Chris PeBenito wrote:
> On Tue, 2008-07-22 at 19:49 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Wed, 2008-06-25 at 14:59 +0900, KaiGai Kohei wrote:
>>>> Hi,
>>>>
>>>> The attached patch allows user domains to communicate with daemon
>>>> domain, and some other domains (Apache and CGI script) to communicate
>>>> with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.
>>>>
>>>> This approach enables to cover most of relationship needed.
>>>> All we have to do is to describe the rest of relationship like
>>>> ones between CGI script and RDBMS, daemons and name server,
>>>> anything and samba server, ....
>>>>
>>>> At least, we cannot get labeled networks available unless adding
>>>> policies to communicate between proper domains.
>>>> I think it is necessary to make a decision to describe the policies.
> 
>> The attached patch is a revised version.
>> Please review it again.
>>
>> And I also noticed that ipsec_match_default_spd() should be invoked with
>> server's domain as postgresql_t doing.
>> (e.g: communication between staff_t and sshd_t)
>> I think it also should be allowed for whole of daemon attribute.
>> What is your opinion? The version.3 patch also contains this fix.
> 
> I merged everything except for the default spd part.  I don't know if
> its been suggested before, but I'm considering putting that match rule
> into corenet_*_recvfrom_unlabeled().

I'm sorry for neglecting this topic.

Can I understand your suggestion was like the patch I attached with
this message? If so, I don't oppose to anything, but we need to put
a short description why ipsec_match_default_spd() is deployed on
corenet_*_recvfrom_unlabeled() to avoid future confusion.
                   ^^^^^^^^^
Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-widespread-ipsec_match_default_spd.patch --]
[-- Type: text/x-patch, Size: 1050 bytes --]

Index: refpolicy/policy/modules/kernel/corenetwork.if.in
===================================================================
--- refpolicy/policy/modules/kernel/corenetwork.if.in	(revision 2781)
+++ refpolicy/policy/modules/kernel/corenetwork.if.in	(working copy)
@@ -1759,6 +1759,10 @@
 	# but for right now we need to keep this in place so as not to break
 	# older systems
 	kernel_sendrecv_unlabeled_association($1)
+
+	optional_policy(`
+		ipsec_match_default_spd($1)
+	')
 ')
 
 ########################################
@@ -1870,6 +1874,10 @@
 	# but for right now we need to keep this in place so as not to break
 	# older systems
 	kernel_sendrecv_unlabeled_association($1)
+
+	optional_policy(`
+		ipsec_match_default_spd($1)
+	')
 ')
 
 ########################################
@@ -1981,6 +1989,10 @@
 	# but for right now we need to keep this in place so as not to break
 	# older systems
 	kernel_sendrecv_unlabeled_association($1)
+
+	optional_policy(`
+		ipsec_match_default_spd($1)
+	')
 ')
 
 ########################################

[refpolicy] [PATCH] Communication between domains under labeled networks

[Christopher J. PeBenito]

On Fri, 2008-08-15 at 17:48 +0900, KaiGai Kohei wrote:
> Chris PeBenito wrote:
> > On Tue, 2008-07-22 at 19:49 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> >>> On Wed, 2008-06-25 at 14:59 +0900, KaiGai Kohei wrote:
> >>>> Hi,
> >>>>
> >>>> The attached patch allows user domains to communicate with daemon
> >>>> domain, and some other domains (Apache and CGI script) to communicate
> >>>> with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.
> >>>>
> >>>> This approach enables to cover most of relationship needed.
> >>>> All we have to do is to describe the rest of relationship like
> >>>> ones between CGI script and RDBMS, daemons and name server,
> >>>> anything and samba server, ....
> >>>>
> >>>> At least, we cannot get labeled networks available unless adding
> >>>> policies to communicate between proper domains.
> >>>> I think it is necessary to make a decision to describe the policies.
> > 
> >> The attached patch is a revised version.
> >> Please review it again.
> >>
> >> And I also noticed that ipsec_match_default_spd() should be invoked with
> >> server's domain as postgresql_t doing.
> >> (e.g: communication between staff_t and sshd_t)
> >> I think it also should be allowed for whole of daemon attribute.
> >> What is your opinion? The version.3 patch also contains this fix.
> > 
> > I merged everything except for the default spd part.  I don't know if
> > its been suggested before, but I'm considering putting that match rule
> > into corenet_*_recvfrom_unlabeled().
> 
> I'm sorry for neglecting this topic.
> 
> Can I understand your suggestion was like the patch I attached with
> this message? If so, I don't oppose to anything, but we need to put
> a short description why ipsec_match_default_spd() is deployed on
> corenet_*_recvfrom_unlabeled() to avoid future confusion.
>                    ^^^^^^^^^

Yes, the patch is what I had in mind.  I'm considering it for handling
the common case, non-labeled ipsec, which is why I suggested it for the
unlabeled network recvfrom.

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