Red Hat Bugzilla – Bug 1102641
BUG: It is not possible to communicate between local program and local ipv6 address when at least one 'netlabelctl unlbl' rule is added
Last modified: 2015-11-05 10:07:00 EST
Description of problem: It is not possible to communicate between local program and service listening on local ipv6 address (loopback, public ipv6 address) when at least one 'netlabelctl unlbl' rule is added. Version-Release number of selected component (if applicable): netlabel_tools-0.20-5.el7 kernel-3.10.0-123.el7 How reproducible: Create at least one 'netlabelctl unlbl' rule and try to connect to any service listening on local ipv6 address. Steps to Reproduce: 1. netlabelctl unlbl add default address:192.168.1.1 label::system_u:object_r:netlabel_peer_t:s0 2. telnet ::1 22 Actual results: # telnet ::1 22 Trying ::1... Expected results: # telnet ::1 22 Trying ::1... Connected to ::1. Escape character is '^]'. SSH-2.0-OpenSSH_6.4 Additional info: Communication is blocked only between local program and local ipv6. Other connections are not affected. local process - local ipv4 => pass local process - local ipv6 => fail local process - remote ipv4 => pass local process - remote ipv6 => pass There are no AVC messages in log. The same behaviour in permissive and enforcing mode of selinux.
Sorry, there is a mistake in first step. The correct command is: netlabelctl unlbl add default address:192.168.1.1 label:system_u:object_r:netlabel_peer_t:s0
This would appear to be related to stream based connections. Trying to recreate this problem now and while SSH fails, ping/ICMP does not. More information when I have more to share.
Another data point, this also fails on Rawhide with kernel 3.17.0-0.rc0.git4.2.fc22.x86_64.
It is possible this is related to the issue identified in BZ #1130082.
Upstream patch posting: * http://marc.info/?l=selinux&m=140976736216990&w=2
I can confirm that kernel-3.10.0-150.el7.x86_64 with the above patch applied fixes the problem described above.
Hi Paul, I can confirm it. # uname -r 3.10.0-150.el7.bz1102641.1.x86_64 # telnet ::1 22 Trying ::1... Connected to ::1. Escape character is '^]'. SSH-2.0-OpenSSH_6.4 ^] telnet> quit Connection closed. # netlabelctl unlbl add default address:192.168.1.1 label:system_u:object_r:netlabel_peer_t:s0 # telnet ::1 22 Trying ::1... Connected to ::1. Escape character is '^]'. SSH-2.0-OpenSSH_6.4 ^] telnet> quit Connection closed.
Fixing component. Can't commit kernel patches against netlabel_tools bugs.
Patch(es) available on kernel-3.10.0-167.el7
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, 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://rhn.redhat.com/errata/RHSA-2015-0290.html
This also appears to be reproducible with selinux-tesuite's inet_socket test [1]. Specifically, the ipsec part of the test can leave the system in state where it's not possible to ssh in over IPv6 and beaker test harness (beah) is unable to connect to local socket over IPv6: # cat /proc/2977/stack [<00000000005b6f22>] __schedule+0x412/0xa18 [<00000000005b49f2>] schedule_timeout+0x21a/0x298 [<00000000005164ea>] __inet_stream_connect+0x26a/0x3c8 [<000000000051669c>] inet_stream_connect+0x54/0x78 [<000000000048010a>] SyS_connect+0xe2/0xf8 [<00000000004810c2>] SyS_socketcall+0x15a/0x340 [<00000000005b8ea4>] sysc_tracego+0x14/0x1a [<ffffffffffffffff>] 0xffffffffffffffff [1] https://github.com/SELinuxProject/selinux-testsuite/tree/master/tests/inet_socket
Just so we're clear, you're simply stating another way to reproduce the bug and not necessarily stating that this issue is not fixed in kernel-3.10.0-167.el7?
(In reply to Paul Moore from comment #21) > Just so we're clear, you're simply stating another way to reproduce the bug > and not necessarily stating that this issue is not fixed in > kernel-3.10.0-167.el7? Correct, I could only trigger it by selinux-testsuite with kernels < 3.10.0-165. (Patch is present since -165.el7, not sure why Fixed-in says -167.el7). I couldn't reproduce it with -165.el7 and more recent kernels.