security context for SPD entries of labeled IPsec

security context for SPD entries of labeled IPsec

[KaiGai Kohei]

We have to set up several SPD entries with a security context
to apply labeled IPsec, like as:

  spdadd 192.168.1.10 192.168.1.20 any
  -ctx 1 1 "system_u:object_r:unconfined_t:s0"
  -P in ipsec esp/transport//require;

What is the most appropriate context to be specified?
Or, is the security policy to be modified?

In the current reference policy, several domain have permissions
of association class for 'self' or 'unlabeled_t'.
However, it can cause a matter when 'unconfined_t' processes tries
to connect 'postgresql_t' process running on another host via labeled
IPsec, for instance.

We can add additional permissions to avoid the matter, as follows:
  allow postgresql_t unconfined_t : association { ... };

But IMO it makes a bit confusable to apply process's domain as
a type of SPD entries, like unconfined_t and so on.

I prefer the following description to separate subject and object.
  allow postgresql_t postgresql_spd_t : association { ... };
  allow unconfined_t postgresql_spd_t : association { ... };

Is there any reason why SPD entries have same type with domains?

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

[KaiGai Kohei]

KaiGai Kohei wrote:
> We have to set up several SPD entries with a security context
> to apply labeled IPsec, like as:
> 
>   spdadd 192.168.1.10 192.168.1.20 any
>   -ctx 1 1 "system_u:object_r:unconfined_t:s0"
>   -P in ipsec esp/transport//require;
> 
> What is the most appropriate context to be specified?
> Or, is the security policy to be modified?
> 
> In the current reference policy, several domain have permissions
> of association class for 'self' or 'unlabeled_t'.
> However, it can cause a matter when 'unconfined_t' processes tries
> to connect 'postgresql_t' process running on another host via labeled
> IPsec, for instance.
> 
> We can add additional permissions to avoid the matter, as follows:
>   allow postgresql_t unconfined_t : association { ... };
> 
> But IMO it makes a bit confusable to apply process's domain as
> a type of SPD entries, like unconfined_t and so on.
> 
> I prefer the following description to separate subject and object.
>   allow postgresql_t postgresql_spd_t : association { ... };
>   allow unconfined_t postgresql_spd_t : association { ... };

In policy/modules/system/ipsec.te, ipsec_spd_t is defined as a default
type for IPSEC SPD entries, as follows:

  # Default type for IPSEC SPD entries
  type ipsec_spd_t;
      :
  allow racoon_t ipsec_spd_t:association setcontext;
      :
  allow setkey_t ipsec_spd_t:association setcontext;
      :

However, setkey_t and racoon_t are the all which have any permission
on ipsec_spd_t.
Is it more preferable than applying a domain as a type of SPD entries?

Thanks,

> Is there any reason why SPD entries have same type with domains?
> 
> 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: security context for SPD entries of labeled IPsec

[Joy Latten]

Hi KaiGai,

On Tue, 2007-11-06 at 19:00 +0900, KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> > We have to set up several SPD entries with a security context
> > to apply labeled IPsec, like as:
> > 
> >   spdadd 192.168.1.10 192.168.1.20 any
> >   -ctx 1 1 "system_u:object_r:unconfined_t:s0"
> >   -P in ipsec esp/transport//require;
> > 
> > What is the most appropriate context to be specified?
> > Or, is the security policy to be modified?
> >

I think you should be able to use default spd security 
context, ipsec_spd_t.

> > In the current reference policy, several domain have permissions
> > of association class for 'self' or 'unlabeled_t'.
> > However, it can cause a matter when 'unconfined_t' processes tries
> > to connect 'postgresql_t' process running on another host via labeled
> > IPsec, for instance.
> > 
> > We can add additional permissions to avoid the matter, as follows:
> >   allow postgresql_t unconfined_t : association { ... };
> > 
> > But IMO it makes a bit confusable to apply process's domain as
> > a type of SPD entries, like unconfined_t and so on.
> > 
> > I prefer the following description to separate subject and object.
> >   allow postgresql_t postgresql_spd_t : association { ... };
> >   allow unconfined_t postgresql_spd_t : association { ... };
> 
> In policy/modules/system/ipsec.te, ipsec_spd_t is defined as a default
> type for IPSEC SPD entries, as follows:
> 
>   # Default type for IPSEC SPD entries
>   type ipsec_spd_t;
>       :
>   allow racoon_t ipsec_spd_t:association setcontext;
>       :
>   allow setkey_t ipsec_spd_t:association setcontext;
>       :
> 
> However, setkey_t and racoon_t are the all which have any permission
> on ipsec_spd_t.
> Is it more preferable than applying a domain as a type of SPD entries?
> 
This permission allows only racoon and setkey to actually set the
security context, ipsec_spd_t within SPD or SA entry. This controls 
who can add or delete SPD and SA entries. Thus no other application is
currently allowed to do this.

We decided to include a default context for SPD entries. Sysadmins can
add more, but additional policy is required for each context you set
in SPD. Below will explain why.

Labeled ipsec authorizes; who can create and delete SPD entries,
whether or not flow can use SPD entry; and if so
the SAs that can be generated by an SPD entry, and the SAs that
can send and receive on a particular flow. 

A better explanation is a quick step through process. 

- Each traffic stream you want secured will have an SPD entry created by
sysadm (setcontext). 

- An app such as telnet results in a packet being generated. The flow
(or you could say session's traffic stream) must be authorized to use
the SPD entry (POLMATCH). Last I recall, flow's security context was
that of socket. So far example, let's say flow's security context is
telnet_t. Thus is telnet (telnet_t) authorized to use ipsec
policy (ipsec_spd_t)  
 
- Once flow is authorized to use SPD entry, it looks for an SA. If 
none, creates one. I believe SA's security context is that of socket
which generated packet, thus it will be telnet_t.
Check is made that authorizes whether the SA can send on the
flow using the SPD entry (SENDTO). 


Thus networking apps need to be able to POLMATCH with ipsec policy and
resulting SAs need to be able to SENDTO on the flow. 

I don't have current selinux policy source and I don't remember the
names and details of files, etc... but I think everything in 
"domain" is authorized to POLMATCH to ipsec_spd_t and everything 
in "domain" is authorized to SENDTO and RECVFROM for ASSOCIATION.

So, if you or a sysadm want to create another security context 
for SPD entries, other than the default. You will also need selinux
policy to:
	- authorize racoon and setkey to set this new security context
	within an ipsec policy or association (SETCONTEXT).      

	- authorize who can POLMATCH with the new spd entry.

	- authorize who can SENDTO and RECVFROM on the flow. 
          ( I think there is an interface, ipsec_labeled, for an example
            of latter two authorizations.)

I am not sure what your requirements are... I don't have policy 
source so not sure if unconfined_t is in "domain" are perhaps needs
ipsec_labeled()... but I am thinking you should be able to use default
SPD security context... 

Sorry, if this email got really long, but once I started with an
explanation I could not stop. I don't even know if this helps,
so let me know how I can help.

regards,
Joy

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

Hello, Joy.

>> However, setkey_t and racoon_t are the all which have any permission
>> on ipsec_spd_t.
>> Is it more preferable than applying a domain as a type of SPD entries?
>>
> This permission allows only racoon and setkey to actually set the
> security context, ipsec_spd_t within SPD or SA entry. This controls 
> who can add or delete SPD and SA entries. Thus no other application is
> currently allowed to do this.
> 
> We decided to include a default context for SPD entries. Sysadmins can
> add more, but additional policy is required for each context you set
> in SPD. Below will explain why.
> 
> Labeled ipsec authorizes; who can create and delete SPD entries,
> whether or not flow can use SPD entry; and if so
> the SAs that can be generated by an SPD entry, and the SAs that
> can send and receive on a particular flow. 
> 
> A better explanation is a quick step through process. 
> 
> - Each traffic stream you want secured will have an SPD entry created by
> sysadm (setcontext). 
> 
> - An app such as telnet results in a packet being generated. The flow
> (or you could say session's traffic stream) must be authorized to use
> the SPD entry (POLMATCH). Last I recall, flow's security context was
> that of socket. So far example, let's say flow's security context is
> telnet_t. Thus is telnet (telnet_t) authorized to use ipsec
> policy (ipsec_spd_t)  
>  
> - Once flow is authorized to use SPD entry, it looks for an SA. If 
> none, creates one. I believe SA's security context is that of socket
> which generated packet, thus it will be telnet_t.
> Check is made that authorizes whether the SA can send on the
> flow using the SPD entry (SENDTO). 
> 
> 
> Thus networking apps need to be able to POLMATCH with ipsec policy and
> resulting SAs need to be able to SENDTO on the flow. 

For example, postgresql_t, httpd_t and any other server domain need
to have association:{ polmatch } to ipsec_spd_t, and association:{ sendto }
to themself.

However, how does association:{ recvfrom } permission?
It seems to me that server domains have to have this permisson to
the peer's domain (as I replied to Venkat).

> I don't have current selinux policy source and I don't remember the
> names and details of files, etc... but I think everything in 
> "domain" is authorized to POLMATCH to ipsec_spd_t and everything 
> in "domain" is authorized to SENDTO and RECVFROM for ASSOCIATION.

Unfortunatelly, it is not correct in the current security policy.

No domain has association:{ polmatch } permission to ipsec_spd_t.

[kaigai@saba serefpolicy-3.0.8]$ grep ipsec_spd_t -r *
policy/modules/system/ipsec.te:type ipsec_spd_t;
policy/modules/system/ipsec.te:allow racoon_t ipsec_spd_t:association setcontext;
policy/modules/system/ipsec.te:allow setkey_t ipsec_spd_t:association setcontext;

In addition, only a part of domains has association:{ sendto recvfrom }
permission to themself. Any domain also has association:{ sendto recvfrom }
permission to unlabeled_t.
(It is defined at kernel_sendrecv_unlabeled_association(domain) of kernel/domain.te)

If all domains should be able to send/recv via labeled ipsec connection,
I think we have to add several rules.

> So, if you or a sysadm want to create another security context 
> for SPD entries, other than the default. You will also need selinux
> policy to:
> 	- authorize racoon and setkey to set this new security context
> 	within an ipsec policy or association (SETCONTEXT).      
> 
> 	- authorize who can POLMATCH with the new spd entry.
> 
> 	- authorize who can SENDTO and RECVFROM on the flow. 
>           ( I think there is an interface, ipsec_labeled, for an example
>             of latter two authorizations.)
> 
> I am not sure what your requirements are... I don't have policy 
> source so not sure if unconfined_t is in "domain" are perhaps needs
> ipsec_labeled()... but I am thinking you should be able to use default
> SPD security context...

The "postgresql_spd_t" was a confusable example.
I didn'd intend to set up a SPD entry with different security context.
The purpose of the question is to lookup an appropriate way to configure
labeled ipsec, on the standard security policy.

> Sorry, if this email got really long, but once I started with an
> explanation I could not stop. I don't even know if this helps,
> so let me know how I can help.

Your explanation helps our undestanding so well.

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

[Venkat Yekkirala]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov 
> [mailto:owner-selinux@tycho.nsa.gov]On Behalf Of KaiGai Kohei
> Sent: Tuesday, November 06, 2007 4:00 AM
> To: cpebenito@tresys.com
> Cc: selinux@tycho.nsa.gov
> Subject: Re: security context for SPD entries of labeled IPsec
> 
> 
> KaiGai Kohei wrote:
> > We have to set up several SPD entries with a security context
> > to apply labeled IPsec, like as:
> > 
> >   spdadd 192.168.1.10 192.168.1.20 any
> >   -ctx 1 1 "system_u:object_r:unconfined_t:s0"
> >   -P in ipsec esp/transport//require;
> > 
> > What is the most appropriate context to be specified?

First of all, you don't have one SPD rule for each domain. You
would typically have one SPD rule labeled with ipsec_spd_t,
for example and have all the domains that need to use that
SPD rule to perform labeled IPsec communication to have
association.polmatch access to ipsec_spd_t. So, the policy defines
one context ipsec_spd_t that you can use for all your SPD rules,
unless you need to distinguish between different SPD rules based
on the label, in which case you can have more than one specified
for the same host pair and have different domains polmatch'ing
to the appropriate rules so the corresponding IPSec policy is
enforced.

Joshua Brindle has an article including labeled-ipsec at:
http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/

> > Or, is the security policy to be modified?
> > 
> > In the current reference policy, several domain have permissions
> > of association class for 'self' or 'unlabeled_t'.
> > However, it can cause a matter when 'unconfined_t' processes tries
> > to connect 'postgresql_t' process running on another host 
> via labeled
> > IPsec, for instance.

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 };

> > 
> > We can add additional permissions to avoid the matter, as follows:
> >   allow postgresql_t unconfined_t : association { ... };
> > 
> > But IMO it makes a bit confusable to apply process's domain as
> > a type of SPD entries, like unconfined_t and so on.

Definitely so, which is the reason there's ipsec_spd_t defined in the policy
to be used for all SPD rules that should perform labeled IPsec.

> > 
> > I prefer the following description to separate subject and object.
> >   allow postgresql_t postgresql_spd_t : association { ... };
> >   allow unconfined_t postgresql_spd_t : association { ... };
> 
> In policy/modules/system/ipsec.te, ipsec_spd_t is defined as a default
> type for IPSEC SPD entries, as follows:
> 
>   # Default type for IPSEC SPD entries
>   type ipsec_spd_t;
>       :
>   allow racoon_t ipsec_spd_t:association setcontext;
>       :
>   allow setkey_t ipsec_spd_t:association setcontext;
>       :
> 
> However, setkey_t and racoon_t are the all which have any permission
> on ipsec_spd_t.
> Is it more preferable than applying a domain as a type of SPD entries?

Yes. Hope the above helps.

> 
> Thanks,
> 
> > Is there any reason why SPD entries have same type with domains?
> > 
> > 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.
> 

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

>> KaiGai Kohei wrote:
>>> We have to set up several SPD entries with a security context
>>> to apply labeled IPsec, like as:
>>>
>>>   spdadd 192.168.1.10 192.168.1.20 any
>>>   -ctx 1 1 "system_u:object_r:unconfined_t:s0"
>>>   -P in ipsec esp/transport//require;
>>>
>>> What is the most appropriate context to be specified?
> 
> First of all, you don't have one SPD rule for each domain. You
> would typically have one SPD rule labeled with ipsec_spd_t,
> for example and have all the domains that need to use that
> SPD rule to perform labeled IPsec communication to have
> association.polmatch access to ipsec_spd_t. So, the policy defines
> one context ipsec_spd_t that you can use for all your SPD rules,
> unless you need to distinguish between different SPD rules based
> on the label, in which case you can have more than one specified
> for the same host pair and have different domains polmatch'ing
> to the appropriate rules so the corresponding IPSec policy is
> enforced.

Thanks, your explanation makes me clear to understand.
Because I tried to read an intention of the author from the security
policy, I got a confusion.

> Joshua Brindle has an article including labeled-ipsec at:
> http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/

I saw, it is a good summary.

>>> Or, is the security policy to be modified?
>>>
>>> In the current reference policy, several domain have permissions
>>> of association class for 'self' or 'unlabeled_t'.
>>> However, it can cause a matter when 'unconfined_t' processes tries
>>> to connect 'postgresql_t' process running on another host 
>> via labeled
>>> IPsec, for instance.
> 
> 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 };
2s. allow unconfined_t self : association { sendto };
2r. allow postgresql_t unconfined_t : association { recvfrom };

Is it correct?

The current security policy defines (2s) rule, but (1) and (2r) are not defined.

Chris, could you give us your opinion?
I think (1) should be added to "unconfined_domain_noaudit" in system/unconfined.if,
and an interface to provide (2r) should be added to somewhere.

>>> We can add additional permissions to avoid the matter, as follows:
>>>   allow postgresql_t unconfined_t : association { ... };
>>>
>>> But IMO it makes a bit confusable to apply process's domain as
>>> a type of SPD entries, like unconfined_t and so on.
> 
> Definitely so, which is the reason there's ipsec_spd_t defined in the policy
> to be used for all SPD rules that should perform labeled IPsec.

OK, I understood.

>>> I prefer the following description to separate subject and object.
>>>   allow postgresql_t postgresql_spd_t : association { ... };
>>>   allow unconfined_t postgresql_spd_t : association { ... };
>> In policy/modules/system/ipsec.te, ipsec_spd_t is defined as a default
>> type for IPSEC SPD entries, as follows:
>>
>>   # Default type for IPSEC SPD entries
>>   type ipsec_spd_t;
>>       :
>>   allow racoon_t ipsec_spd_t:association setcontext;
>>       :
>>   allow setkey_t ipsec_spd_t:association setcontext;
>>       :
>>
>> However, setkey_t and racoon_t are the all which have any permission
>> on ipsec_spd_t.
>> Is it more preferable than applying a domain as a type of SPD entries?
> 
> Yes. Hope the above helps.
> 
>> Thanks,
>>
>>> Is there any reason why SPD entries have same type with domains?
>>>
>>> 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.
>>
> 
> 


-- 
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: 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 };

If you ignore the typos in the above rule, it would be:
allow domain-that-should-receive-from-peer  peer-domain:association { recvfrom };

<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

[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)