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