Hi Matt,

On 02/03/2017 04:51 PM, Matt Rogers wrote:
This might not be related to your issue but I remember putting in a
fix for a labeled IPsec setup in last year (around 3.14?). You should
at least make sure that your build has it, it's the most recent
labeled IPsec related change.
I've installed libreswan-3.15-8.el7.x86_64 from the current CentOS repo. Given the numbering, I would guess I've got your fix? Thanks.

-jeff

commit 1543f3c66bce961a94d119d7b3c32ad965cf07d3
Author: Matt Rogers <[email protected]>
Date:   Wed Aug 19 15:59:12 2015 -0400

     Fix labeled ipsec SECCTX parsing

diff --git a/programs/pluto/ikev1_spdb_struct.c
b/programs/pluto/ikev1_spdb_struct.c
index da8c76c..b144331 100644
--- a/programs/pluto/ikev1_spdb_struct.c
+++ b/programs/pluto/ikev1_spdb_struct.c
@@ -84,7 +84,7 @@ static bool parse_secctx_attr(pb_stream *pbs, struct
state *st)

         zero(&uctx.sec_ctx_value);      /* abundance of caution */

-       if (in_raw(uctx.sec_ctx_value, uctx.ctx.ctx_len, pbs,
+       if (!in_raw(uctx.sec_ctx_value, uctx.ctx.ctx_len, pbs,
                         "Sec Ctx Textual Label"))
                 return FALSE;


On Fri, Feb 3, 2017 at 6:56 PM, Jeff Becker <[email protected]> wrote:
On 02/03/2017 09:31 AM, Paul Wouters wrote:
On Thu, 2 Feb 2017, Jeff Becker wrote:

Hi. Using libreswan, I was able to set up an unlabeled ipsec tunnel
between two CentOS 7.3 hosts.

However, if I add the following to my ipsec.conf...

         labeled-ipsec=yes

policy-label=unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0

restart ipsec on both sides, add the new tunnel and try to bring it up, I
get:

117 "dtsd-tunnel" #2: STATE_QUICK_I1: initiate
003 "dtsd-tunnel" #2: ERROR: netlink XFRM_MSG_UPDPOLICY response for flow
[email protected] included errno 22: Invalid argument
002 "dtsd-tunnel" #2: raw_eroute() in setup_half_ipsec_sa() failed to add
inbound

I chose the policy-label from the example in the latest SELinux notebook
(https://selinuxproject.org/page/Category:Notebook). Not sure if
that's the issue, or if it's something else. Please advise. Thanks.

Our test configuration uses:

     policy_label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023

I got the above (actually policy-label=system_u:object_r:ipsec_spd_t:s0) to
work by fixing an AVC denial. Now when I bring up the tunnel I see:

# ipsec auto --up dtsd-tunnel
002 "dtsd-tunnel" #1: initiating Main Mode
104 "dtsd-tunnel" #1: STATE_MAIN_I1: initiate
003 "dtsd-tunnel" #1: received Vendor ID payload [Dead Peer Detection]
003 "dtsd-tunnel" #1: received Vendor ID payload [FRAGMENTATION]
003 "dtsd-tunnel" #1: received Vendor ID payload [RFC 3947]
002 "dtsd-tunnel" #1: enabling possible NAT-traversal with method RFC 3947
(NAT-Traversal)
002 "dtsd-tunnel" #1: transition from state STATE_MAIN_I1 to state
STATE_MAIN_I2
106 "dtsd-tunnel" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "dtsd-tunnel" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal)
sender port 500: no NAT detected
002 "dtsd-tunnel" #1: transition from state STATE_MAIN_I2 to state
STATE_MAIN_I3
108 "dtsd-tunnel" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "dtsd-tunnel" #1: received Vendor ID payload [CAN-IKEv2]
002 "dtsd-tunnel" #1: Main mode peer ID is ID_IPV4_ADDR: '198.9.7.198'
002 "dtsd-tunnel" #1: transition from state STATE_MAIN_I3 to state
STATE_MAIN_I4
004 "dtsd-tunnel" #1: STATE_MAIN_I4: ISAKMP SA established {auth=RSA_SIG
cipher=aes_256 integ=sha group=MODP2048}
002 "dtsd-tunnel" #2: initiating Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
{using isakmp#1 msgid:3849768f proposal=defaults
pfsgroup=OAKLEY_GROUP_MODP2048}
117 "dtsd-tunnel" #2: STATE_QUICK_I1: initiate
002 "dtsd-tunnel" #2: transition from state STATE_QUICK_I1 to state
STATE_QUICK_I2
004 "dtsd-tunnel" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0xc01ab79f <0x4f6e6b26 xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=none DPD=passive}

I don't see anything above that indicates that labeled ipsec is being used,
but maybe that's OK. Anyhow, after setting this up, I can't seem to ping the
other side of the tunnel (I was able to ping in the case without labeled
ipsec). Any suggestions are appreciated. Thanks.

-jeff

I think we also needed to put the system in MLS mode for this to properly
work?

I'll ask some of the selinux people inside Red Hat if they know more.

Paul


_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan


_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to