Re: security context for SPD entries of labeled IPsec

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

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.