Re: [PATCH] IPsec SPD default security context

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

>>>>> 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?
> 
> Yes.  It seems like a lot, but if you think about it, there are already
> the base networking rules in the policy.  This actually gives more of an
> opportunity to abstract the rules, so you get something like
> 
> interface postgresql_tcp_connect()
> 	corenet_tcp_sendrecv_postgresql_port($1)
> 	corenet_tcp_connect_postgresql_port($1)
> 	corenet_sendrecv_postgresql_client_packets($1)
> 	# labeled ipsec and (future) TE netlabel
> 	allow $1 postgresql_t:{ association tcp_socket } recvfrom;

Is it necessary to add "allow postgresql_t $1 : association recvfrom" ?
(It's unclear for me, whether tcp_socket should be also, or not.)

$1 domain can receive replies from postgresql_t, but postgresql_t cannot
receive messages from $1 domain.

> 	# compat labeled ipsec rule
> 	allow $1 self:association sendto;
> 
> and then even the labeled networking part could be put into a policy
> pattern.

What does it means policy pattern?
It's a bit unclear for me whether you intend to make a new template
interface like the one defined at kernel/corenetwork.if.m4, or make
a new interface for each daemon domains.

>> 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;
> 
> I'm hesitant to add permissions like this as any domain that networks
> can have labeled networking.  At best it seems like a stopgap measure
> until interfaces like the example above are in place.

OK, I understood it.

Is it same for the unconfined_domain_type? They can receive messages from
any domain, but the peer domain without unconfined_domain_type cannot receive
messages from unconfined_domain_type.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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