> -----Original Message----- > From: owner-selinux@xxxxxxxxxxxxx > [mailto:owner-selinux@xxxxxxxxxxxxx]On Behalf Of KaiGai Kohei > Sent: Tuesday, November 06, 2007 4:00 AM > To: cpebenito@xxxxxxxxxx > Cc: selinux@xxxxxxxxxxxxx > Subject: Re: security context for SPD entries of labeled IPsec > > > 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. Joshua Brindle has an article including labeled-ipsec at: http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ > > 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 }; > > > > 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. > > > > 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. > -- 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.
