Re: ipsec module and Libreswan on CentOS 7 denied

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

 



On Thu, 2017-04-06 at 20:28 +0200, Grzegorz Kuczyński wrote:
> Hello again :)
> This time it work, and this is what I does:
> 
> Add to ipsec.conf this options:
> secctx-attr-type=32001
> 
> This is my config:
> [root@CnetOS7 netserver]# cat /etc/ipsec.conf
> version 2
> 
> config setup
>     protostack=netkey
>     secctx-attr-type=32001
> 
> conn ipsec_selinux_tunnel
>     leftid=@west
>     left=10.5.5.18
>     leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...]
> W2n417C/4urYHQkCvuIQ==
>     rightid=@east
>     right=10.5.5.10
>     rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
>     authby=rsasig
>     auto=start
>     labeled_ipsec=yes
>     policy_label=system_u:object_r:ipsec_spd_t:s0
> 
> 
> In my own domain I coment unlabeled_t allow:
> netserver.te:
> ...
> allow netserver_t ipsec_t:association { polmatch };
> allow ipsec_t netserver_t:association { setcontext };
> allow ipsec_t ipsec_spd_t:association { setcontext };
> #allow unlabeled_t ipsec_spd_t:association { polmatch };
> 
> I start my server and client and I have some denied, so I add to my
> server domain:
> allow netserver_t netif_t:netif { ingress egress }
> allow netserver_t node_t:node { sendto recvfrom }
> 
> and client domain:
> allow netclient_t netif_t:netif { ingress egress }
> allow netclient_t node_t:node { sendto recvfrom }
> allow netclient_t netserver_t:peer { recv }
> allow netserver_t netclient_t:peer { recv }
> 
> Now work properly:
> [root@CnetOS7 netserver]# netserver -Z
> Listening...
> Connected with 10.5.5.10:44998
> Client SELinux conntext: unconfined_u:unconfined_r:netclient_t:s0-
> s0:c0.c1023
> 
> Retrive: quit
> [root@CnetOS7 netserver]# ip xfrm state
> src 10.5.5.10 dst 10.5.5.18
> 	proto esp spi 0x436be694 reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0x4c7d6ff6a191951fc69d9c3def070db3e0d59ae5 96
> 	enc cbc(aes) 0x3c624b14b79e6f2dd632d26d36d90ff7
> 	security context unconfined_u:unconfined_r:netserver_t:s0-
> s0:c0.c1023 
> src 10.5.5.18 dst 10.5.5.10
> 	proto esp spi 0x3ad8e7fa reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0x91a06a54d2fd1899229129489bd1d766b8f00990 96
> 	enc cbc(aes) 0x77a17777f44378970ffa25cdd2a8bd34
> 	security context unconfined_u:unconfined_r:netserver_t:s0-
> s0:c0.c1023 
> src 10.5.5.18 dst 10.5.5.10
> 	proto esp spi 0x814b2bb1 reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0x6b72091e994d5790690f8169889e2188b2cbc933 96
> 	enc cbc(aes) 0x5e9d4f9128c995edbf7e46aca6f92950
> 	security context unconfined_u:unconfined_r:netclient_t:s0-
> s0:c0.c1023 
> src 10.5.5.10 dst 10.5.5.18
> 	proto esp spi 0xfde27f2f reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0xdfa421e570976742d24028a00f391857beac5683 96
> 	enc cbc(aes) 0x9c72f2a72726154130f1c8922e0b173e
> 	security context unconfined_u:unconfined_r:netclient_t:s0-
> s0:c0.c1023 
> src 10.5.5.10 dst 10.5.5.18
> 	proto esp spi 0x9b25639b reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0x6adc49b7978217d1a5656b3462f916ef051e43b6 96
> 	enc cbc(aes) 0x4c248f4bc47199b3637b32226d9e7377
> src 10.5.5.18 dst 10.5.5.10
> 	proto esp spi 0xc17086fa reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0x726602fb3a003b0296bd3c59d0c0631ae8b69619 96
> 	enc cbc(aes) 0x167ce87116d07c4d3436c1631fb6efa4
> src 10.5.5.10 dst 10.5.5.18
> 	proto esp spi 0xc7ceed20 reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0x5debc146502f9d8322f79130a695a863a5191edd 96
> 	enc cbc(aes) 0xc66cf0910346412f78aaab9770c98a7d
> src 10.5.5.18 dst 10.5.5.10
> 	proto esp spi 0x6b36950c reqid 16389 mode tunnel
> 	replay-window 32 flag af-unspec
> 	auth-trunc hmac(sha1)
> 0xe138e77d26e05ffdbfdad7241f505645917a8574 96
> 	enc cbc(aes) 0x874ed487c96261c692672d48e02129f3
> 
> So the reason why this not work early is missing option in
> ipsec.conf?
> Or it is still bug?

Not a bug in pluto.  Possibly a bug in selinux policy that it lacked at
least the allow rule for ipsec_t ipsec_spd_t:association setcontext;,
but the other allow rules are necessarily local since you defined those
domains.
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux