On Thu, 2017-04-06 at 16:53 +0100, Richard Haines wrote:
On Tue, 2017-04-04 at 18:43 -0400, Paul Wouters wrote:
On 04/04/2017 05:14 PM, Paul Moore wrote:
On Tue, Apr 4, 2017 at 1:43 PM, Stephen Smalley <sds@tycho.nsa.go v> wrote:
On Tue, 2017-04-04 at 17:09 +0000, Grzegorz Kuczyński wrote:
[root@CnetOS7 ~]# ip xfrm state src 10.5.5.18 dst 10.5.5.10 proto esp spi 0xedbce21c reqid 16389 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha1) 0x4f8cdee1b453dacf606fcf630d9c5b328b952404 96 enc cbc(aes) 0x442da48e8178c4971275b9d889747536 src 10.5.5.10 dst 10.5.5.18 proto esp spi 0x921bce56 reqid 16389 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha1) 0x7050af8d2c7c151db1ded71d5a4468eaafdc8a29 96 enc cbc(aes) 0x8686ccf1127bb881fa382fe17f790d69 src 10.5.5.10 dst 10.5.5.18 proto esp spi 0xe6ca8cc5 reqid 16389 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha1) 0x3aef0708d244ede7793e328b1937d0b70d425fb7 96 enc cbc(aes) 0xa4cc55f6a88307b8f354fc3e8d576276 src 10.5.5.18 dst 10.5.5.10 proto esp spi 0x5acea75b reqid 16389 mode tunnel replay-window 32 flag af-unspec auth-trunc hmac(sha1) 0x731268575b53cfbd9cac20e988cfc5557d381036 96 enc cbc(aes) 0x1defeab6aa6ac729f3082f6b70053918
Hmm...no security contexts? That would explain why you are getting unlabeled_t. But I guess the question is why is pluto creating SAs without any security contexts. Seems like a bug there, but I am not sure.
What is the configuration? Was labeled-ipsec=yes and policy-label= set? If dealing with RHEL6 or older, it also needs to have secctx-attr- type=10 If not, no security context is set.
https://lists.fedoraproject.org/archives/list/selinux@lists.fedor ap roject.org/thread/AXJWXBVF4ZCSPKQ42MWX5LRTD5PGRS7O
Note the references in the documentation to loopback should be removed. It was broken and removed.
Was IKEv1 used? IKEv2 does not support security labels so set ikev2=never
Log files should indicate if any security label was negotiated.
Is this system using MLS?
Paul
Out of idle curiosity I thought I would test this. I set up two machines and finally got this to work. I did have the same problem as yourself: allow unlabeled_t ipsec_spd_t:association polmatch;
However I did the following to fix this (on both machines running Fedora 25 targeted policy):
iptables -I INPUT 1 -p esp -j ACCEPT
Added the following module:
module local 1.0;
require { type unconfined_t; type ipsec_spd_t; type ipsec_t; class association setcontext; }
#============= ipsec_t ============== allow ipsec_t ipsec_spd_t:association setcontext;
# Required because I just run as a basic user. Not sure what you need allow ipsec_t unconfined_t:association setcontext;
Hmm...that's a policy bug then. pluto and racoon should be allowed setcontext.
One side ipsec.conf file contents:
version 2.0
config setup plutorestartoncrash=false protostack=netkey plutodebug="all" # Note: works with either 10 or 32001, however must # be same on both machines. secctx-attr-type=32001
conn labeled_test auto=start rekey=no authby=secret type=transport left=192.168.1.77 right=192.168.1.64 ike=3des-sha1 phase2=esp phase2alg=aes-sha1 labeled-ipsec=yes policy-label=system_u:object_r:ipsec_spd_t:s0 leftprotoport=tcp rightprotoport=tcp
I could see the correct peer context using getpeercon(3) on my test client/server: Server Peer Context: unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023 Client Peer Context: unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023
Hope you get yours to work now (or you may have it working already ??)
Richard
selinux@lists.fedoraproject.org
-
Stephen Smalley