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