RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Summary: BUG: It is not possible to communicate between local program and local ipv6 a...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Paul Moore
QA Contact: Jaroslav Aster
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-29 11:21 UTC by Jaroslav Aster
Modified: 2015-11-05 15:07 UTC (History)
2 users (show)

Fixed In Version: kernel-3.10.0-167.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 12:14:46 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0290 0 normal SHIPPED_LIVE Important: kernel security, bug fix, and enhancement update 2015-03-05 16:13:58 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.