Re: [PATCH] IPsec SPD default security context (Re: security context for SPD entries of labeled IPsec)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2007-12-13 at 08:58 -0600, Xavier Toth wrote:
> 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 };

I generally have a problem with across-the-board rules like this
upstream.  Neglecting that, the sendto/recvfrom part doesn't make much
sense since sendto should be on self and recvfrom should be on the peer
domain.

> On Dec 13, 2007 8:14 AM, Christopher J. PeBenito <cpebenito@xxxxxxxxxx> 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
> >
> >
-- 
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.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux