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