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@xxxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
