On Tue, 2007-11-20 at 18:14 +0900, KaiGai Kohei wrote:
> >>>>> 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.
Right, you'd need both, my mistake.
> > # 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?
Its a support macro. See support/file_patterns.spt for file access
patterns.
> 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.
Each of the daemons would need it.
> >> 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.
Good question. I'm not sure.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
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.
