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