On Thu, 2007-12-13 at 08:00 -0600, Ted X Toth wrote:
> 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.
Right, its not completely resolved at the moment. The only labeled
networking rules are the ones that KaiGai sent, so I wouldn't expect it
to work.
--
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.
