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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
