Bug 1931848
| Summary: | selinux-policy prevents ipsec/pluto to work over TCP | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Ondrej Moriš <omoris> | |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | |
| Severity: | medium | Docs Contact: | Khushbu Borole <kborole> | |
| Priority: | medium | |||
| Version: | 8.4 | CC: | jafiala, kborole, lvrabec, mjahoda, mmalik, plautrba, ssekidde, zpytela | |
| Target Milestone: | rc | Keywords: | Triaged | |
| Target Release: | 8.5 | Flags: | kborole:
needinfo-
kborole: needinfo- |
|
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-3.14.3-68.el8 | Doc Type: | Bug Fix | |
| Doc Text: |
.`selinux-policy` now supports IPsec-based VPNs using TCP encapsulation
Since RHEL 8.4, the `libreswan` packages have supported IPsec-based VPNs using TCP encapsulation, but the `selinux-policy` package did not reflect this update. As a consequence, when Libreswan was configured to use TCP, the `ipsec` service failed to bind to the given TCP port. With this update to the `selinux-policy` package, the `ipsec` service can bind and connect to the commonly used TCP port `4500`, and therefore you can use TCP encapsulation in IPsec-based VPNs.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1951471 (view as bug list) | Environment: | ||
| Last Closed: | 2021-11-09 19:42:58 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
|
Description
Ondrej Moriš
2021-02-23 11:55:17 UTC
Please re-test with the latest selinux-policy installed. I'm sorry. The latest selinux-policy only allows udp_socket: # sesearch -s ipsec_t -t ipsecnat_port_t -p name_bind -A allow ipsec_t ipsecnat_port_t:udp_socket name_bind; # Following SELinux denial appeared several times in enforcing mode:
----
type=PROCTITLE msg=audit(02/23/2021 14:52:35.112:1947) : proctitle=/usr/libexec/ipsec/pluto --leak-detective --config /etc/ipsec.conf --nofork
type=SOCKADDR msg=audit(02/23/2021 14:52:35.112:1947) : saddr={ saddr_fam=inet6 laddr=::1 lport=4500 }
type=SYSCALL msg=audit(02/23/2021 14:52:35.112:1947) : arch=x86_64 syscall=bind success=no exit=EACCES(Permission denied) a0=0x1b a1=0x7ffd0d3e72d4 a2=0x1c a3=0x7ffd0d3e71d0 items=0 ppid=1 pid=81461 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=pluto exe=/usr/libexec/ipsec/pluto subj=system_u:system_r:ipsec_t:s0 key=(null)
type=AVC msg=audit(02/23/2021 14:52:35.112:1947) : avc: denied { name_bind } for pid=81461 comm=pluto src=4500 scontext=system_u:system_r:ipsec_t:s0 tcontext=system_u:object_r:ipsecnat_port_t:s0 tclass=tcp_socket permissive=0
----
The only SELinux denial which appeared in permissive mode is:
----
type=PROCTITLE msg=audit(02/23/2021 14:55:08.761:1977) : proctitle=/usr/libexec/ipsec/pluto --leak-detective --config /etc/ipsec.conf --nofork
type=SOCKADDR msg=audit(02/23/2021 14:55:08.761:1977) : saddr={ saddr_fam=inet laddr=192.168.124.1 lport=4500 }
type=SYSCALL msg=audit(02/23/2021 14:55:08.761:1977) : arch=x86_64 syscall=bind success=yes exit=0 a0=0x16 a1=0x7ffc25ca0234 a2=0x10 a3=0x7ffc25ca0130 items=0 ppid=1 pid=82438 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=pluto exe=/usr/libexec/ipsec/pluto subj=system_u:system_r:ipsec_t:s0 key=(null)
type=AVC msg=audit(02/23/2021 14:55:08.761:1977) : avc: denied { name_bind } for pid=82438 comm=pluto src=4500 scontext=system_u:system_r:ipsec_t:s0 tcontext=system_u:object_r:ipsecnat_port_t:s0 tclass=tcp_socket permissive=1
----
I just found out that there is one more AVC:
----
time->Mon Mar 8 12:28:35 2021
type=PROCTITLE msg=audit(1615224515.200:779): proctitle=2F7573722F6C6962657865632F69707365632F706C75746F002D2D6C65616B2D646574656374697665002D2D636F6E666967002F6574632F69707365632E636F6E66002D2D6E6F666F726B
type=SOCKADDR msg=audit(1615224515.200:779): saddr=020011940A008B240000000000000000
type=SYSCALL msg=audit(1615224515.200:779): arch=c000003e syscall=42 success=yes exit=0 a0=19 a1=7ffc2ba53074 a2=10 a3=0 items=0 ppid=1 pid=17348 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pluto" exe="/usr/libexec/ipsec/pluto" subj=system_u:system_r:ipsec_t:s0 key=(null)
type=AVC msg=audit(1615224515.200:779): avc: denied { name_connect } for pid=17348 comm="pluto" dest=4500 scontext=system_u:system_r:ipsec_t:s0 tcontext=system_u:object_r:ipsecnat_port_t:s0 tclass=tcp_socket permissive=1
Therefore, the rule we need to add is actually as follows:
#============= ipsec_t ==============
allow ipsec_t ipsecnat_port_t:tcp_socket { name_bind name_connect };
IOW, not only name_bind for tcp_socket is needed but also name_connect permission.
Proposing "Known Issue" Doc Type. ESPinTCP feature will be present in RHEL-8.4 and this bug will prevent its usage. Therefore I think it would be good to document this known issue. The only workaround now is to use custom policy module with the following rule:
#============= ipsec_t ==============
allow ipsec_t ipsecnat_port_t:tcp_socket { name_bind name_connect };
Merged in rawhide:
commit e3778cb9326fe086398f7b703557b9f3ef41f270 (HEAD -> rawhide, upstream/rawhide)
Author: Zdenek Pytela <zpytela>
Date: Mon Apr 26 17:07:01 2021 +0200
Allow pluto IKEv2 / ESP over TCP
Libreswan and kernel have recently started to support transporting IKEv2
and ESP packets over a TCP connection, described in RFC 8229, for
traversing network middleboxes that may block IKE negotiation over UDP.
The option is not enabled in libreswan by default, but anyway needs to
be backed by SELinux policy in case the use was requested.
By default, the 4500/tcp port is used.
Resolves: rhbz#1931848
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4420 |