On Fri, 2008-08-15 at 17:48 +0900, KaiGai Kohei wrote:
> Chris PeBenito wrote:
> > On Tue, 2008-07-22 at 19:49 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> >>> On Wed, 2008-06-25 at 14:59 +0900, KaiGai Kohei wrote:
> >>>> Hi,
> >>>>
> >>>> The attached patch allows user domains to communicate with daemon
> >>>> domain, and some other domains (Apache and CGI script) to communicate
> >>>> with RDBMS (PostgreSQL and MySQL) using xxxx_tcp_connect() interface.
> >>>>
> >>>> This approach enables to cover most of relationship needed.
> >>>> All we have to do is to describe the rest of relationship like
> >>>> ones between CGI script and RDBMS, daemons and name server,
> >>>> anything and samba server, ....
> >>>>
> >>>> At least, we cannot get labeled networks available unless adding
> >>>> policies to communicate between proper domains.
> >>>> I think it is necessary to make a decision to describe the policies.
> >
> >> The attached patch is a revised version.
> >> Please review it again.
> >>
> >> And I also noticed that ipsec_match_default_spd() should be invoked with
> >> server's domain as postgresql_t doing.
> >> (e.g: communication between staff_t and sshd_t)
> >> I think it also should be allowed for whole of daemon attribute.
> >> What is your opinion? The version.3 patch also contains this fix.
> >
> > I merged everything except for the default spd part. I don't know if
> > its been suggested before, but I'm considering putting that match rule
> > into corenet_*_recvfrom_unlabeled().
>
> I'm sorry for neglecting this topic.
>
> Can I understand your suggestion was like the patch I attached with
> this message? If so, I don't oppose to anything, but we need to put
> a short description why ipsec_match_default_spd() is deployed on
> corenet_*_recvfrom_unlabeled() to avoid future confusion.
> ^^^^^^^^^
Yes, the patch is what I had in mind. I'm considering it for handling
the common case, non-labeled ipsec, which is why I suggested it for the
unlabeled network recvfrom.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150