Re: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Ted X Toth <txtoth@gmail.com>]

KaiGai Kohei wrote:
>>> I also suggest two minor improvement toward these updates.
>>>
>>> 1. Is it considerable to add "allow $1 self : association { sendto };"
>>>    at ipsec_match_default_spd interface of ipsec.if?
>>>
>>>    I think it should be packed with polmatch permission to the default
>>>    SPD context, because any domain which want to communicate others using
>>>    SPD with default context always have to have 'sendto' permission to
>>>    itself.
>>>       
>> Perhaps.  Though I thought that dropping the sendto check was being
>> considered, since it really doesn't gain anything.
>>
>>     
>>> 2. Is it considerable to add "ipsec_match_default_spd($1_t)"
>>>    in the userdom_basic_networking_template of userdomain.if?
>>>
>>>    This interface allows a given userdomain widespread basic networking
>>>    permissions. But it is not enough yet, if the networking tunnel
>>>    is configured with labeled ipsec.
>>>    I think it can be contained in the basic networking permissions
>>>    to use ipsec SPD with default context.
>>>       
>> Sounds reasonable.
>>     
>
> The attached patch enables the above two features.
>
> Paul mentioned to drop the checks of association:{sendto} permission and
> integrate them with the upcaming flow control checks in the future kernel.
> However, a rule of "allow <domain> self : association {sendto}" will be
> necessary for the backward compatibility.
>
>   
>>>> I'll consider a patch that adds it to a postresql interface.  Perhaps
>>>> postgresql_tcp_connect should be un-deprecated.
>>>>         
>>> I think similar interfaces are necessary for any other daemon-domain which
>>> provides networking-services, even if they don't use getpeercon().
>>>       
>> The recvfrom is needed if the networking is labeled, regardless of
>> whether getpeercon() is used or not.
>>     
>
> Do you intend to describe the labeled networking rules for each combination
> between a server domain and a client domain?
>
> Is it a considerable idea that adding a new attribute to comunicate via
> labeled ipsec with default SPD, and attaching it both a server domain and
> a client domain?
>
> e.g)
>   attribute labeled_communicatable_domain;  # I want to get more shorl naming.
>   allow     labeled_communicatable_domain labeled_communicatable_domain : association {resvfrom sendto};
>
>   typeattribute postgresql_t, labeled_communicate_domain;
>   typeattribute user_t, labeled_communicate_domain;
>
> Thanks,
>   
It doesn't seem that the issue of allowing domain polmatch, sendto and
recvfrom to ipsec_spd_t: association has been resolved yet. I'm not sure
what the right answer is but I do know that ipsec is does not work with
the current policy.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.