Bug 1102641

Summary: BUG: It is not possible to communicate between local program and local ipv6 address when at least one 'netlabelctl unlbl' rule is added
Product: Red Hat Enterprise Linux 7 Reporter: Jaroslav Aster <jaster>
Component: kernelAssignee: Paul Moore <pmoore>
Status: CLOSED ERRATA QA Contact: Jaroslav Aster <jaster>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: jstancek, ksrot
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-3.10.0-167.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 12:14:46 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 Jaroslav Aster 2014-05-29 11:21:18 UTC
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.

Comment 1 Jaroslav Aster 2014-05-29 11:24:42 UTC
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

Comment 4 Paul Moore 2014-08-13 20:46:50 UTC
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.

Comment 5 Paul Moore 2014-08-13 21:13:32 UTC
Another data point, this also fails on Rawhide with kernel 3.17.0-0.rc0.git4.2.fc22.x86_64.

Comment 6 Paul Moore 2014-09-03 15:20:49 UTC
It is possible this is related to the issue identified in BZ #1130082.

Comment 7 Paul Moore 2014-09-03 18:10:07 UTC
Upstream patch posting:

 * http://marc.info/?l=selinux&m=140976736216990&w=2

Comment 9 Paul Moore 2014-09-04 14:47:13 UTC
I can confirm that kernel-3.10.0-150.el7.x86_64 with the above patch applied fixes the problem described above.

Comment 11 Jaroslav Aster 2014-09-04 15:40:15 UTC
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.

Comment 12 Jarod Wilson 2014-09-04 16:58:26 UTC
Fixing component. Can't commit kernel patches against netlabel_tools bugs.

Comment 14 Jarod Wilson 2014-09-22 17:54:52 UTC
Patch(es) available on kernel-3.10.0-167.el7

Comment 19 errata-xmlrpc 2015-03-05 12:14:46 UTC
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

Comment 20 Jan Stancek 2015-11-05 09:48:09 UTC
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

Comment 21 Paul Moore 2015-11-05 15:01:11 UTC
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?

Comment 22 Jan Stancek 2015-11-05 15:07:00 UTC
(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.