On Tue, 2017-04-04 at 14:03 +0100, Richard Haines wrote:
> On Mon, 2017-04-03 at 14:49 -0400, Stephen Smalley wrote:
> > On Sun, 2017-04-02 at 11:57 +0200, Grzegorz Kuczyński wrote:
> > > Hello
> > > I configured Labeled IPSec on CentOS 7 using Libreswan and I
> > > found
> > > such denied:
> > >
> > > type=AVC msg=audit(1491053758.389:1366): avc: denied { polmatch
> > > }
> > > for pid=0 comm="swapper/0"
> > > scontext=system_u:object_r:unlabeled_t:s0
> > > tcontext=system_u:object_r:ipsec_spd_t:s0 tclass=association
> > >
> > > My config file on both hosts is:
> > >
> > > # cat /etc/ipsec.conf
> > > version 2
> > >
> > > config setup
> > > protostack=netkey
> > >
> > > conn ipsec_selinux_tunnel
> > > ...
> > > labeled_ipsec=yes
> > > policy_label=system_u:object_r:ipsec_spd_t:s0
>
> I have not tested this for a few years, however last time I did, I
> put
> the process context in policy_label= as at that time the man page had
> not been updated with the example it now has !!. Worth a try ??
If so, that seems like a bug in pluto; the pluto configuration should
only need to specify the policy security context; the SA security
context should be automatically derived from the context of the sender
that triggered the SA establishment.
>
> > >
> > > It's looks like process swapper is missing labeled?
> > >
> > > I must add this rule to my own module:
> > > allow unlabeled_t ipsec_spd_t:association { polmatch };
> > >
> > > This is not a bug?
> >
> > The unlabeled context is from the flow, not the process, for this
> > check. The current process is irrelevant, since this is happening
> > on
> > network input processing of the received packet. I guess the
> > question
> > is how did we end up with an unlabeled flow. What does 'ip xfrm
> > state'
> > show as the security context for the association?
> >
> > FWIW, there is a sample configuration of labeled IPSEC over
> > loopback
> > (and tests for it) in the selinux-testsuite. That however is a
> > manual
> > configuration.
> >