I ask because the thread seemed to end. Is there a discussion of a resolution off the list? Is there an issue with adding : allow domain ipsec_spd_t : association { polmatch sendto recvfrom };

On Dec 13, 2007 8:14 AM, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
>
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.