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 2015525 - SCTP peel-off with SELinux and containers in OCP
Summary: SCTP peel-off with SELinux and containers in OCP
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: kernel
Version: 8.5
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Ondrej Mosnacek
QA Contact: Milos Malik
Jan Fiala
URL:
Whiteboard:
Depends On:
Blocks: 2048251 2054111 2054112
TreeView+ depends on / blocked
 
Reported: 2021-10-19 12:41 UTC by zeikman
Modified: 2023-01-20 10:33 UTC (History)
28 users (show)

Fixed In Version: kernel-4.18.0-372.1.1.el8
Doc Type: Bug Fix
Doc Text:
Cause: Use of sctp_peeloff(3) on a SEQPACKET SCTP socket to peel off an association initiated from "us" into a new socket. (As opposed to peeling off an association initiated by a remote peer, which works correctly.) Consequence: The SELinux label of the association (and thus also the peeled-off socket) is not initialized properly - it ends up with the unlabeled_t SELinux type and subsequent operations on the socket are denied as a result. Fix: The SCTP and SELinux kernel code has been modified to properly initialize labels on all associations. Result: SCTP associations initiated from "us" inherit the parent socket's label and this label is then passed onto the peeled-off socket.
Clone Of:
: 2054111 2054112 (view as bug list)
Environment:
Last Closed: 2022-05-10 15:02:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/rhel/src/kernel rhel-8 merge_requests 2215 0 None None None 2022-02-13 19:36:27 UTC
Red Hat Issue Tracker RHELPLAN-100363 0 None None None 2021-10-20 13:26:22 UTC
Red Hat Knowledge Base (Solution) 6976152 0 None None None 2022-09-19 01:43:16 UTC
Red Hat Product Errata RHSA-2022:1988 0 None None None 2022-05-10 15:03:35 UTC

Description zeikman 2021-10-19 12:41:24 UTC 
Sctp peeloff issue 

For the sctp_peeloff issue, it happens because the sctp socket created by the the peel off API has not been correctly labeled, thus, the unlabeled_t is used for that socket.
Then afterwards, any further operation from a container such as getopt, read, write will fail, as there is no policy allow container_t to access the sctp socket which is labeled as unlabeled_t.

So we are wondering whether there is any problem in sctp peeloff API, i.e., that the SELinux type has not been correctly passed from parent process to the sctp socket.
Especially, there is no such peeloff permissions in SELinux procfs, so does that mean the peeloff operation is not supported by SELinux?

If when invoking the peeloff API, the newly created sctp socket could be labelled correctly, then the later operation would be a success.

Please check whether it is feasible for the kernel team to fix this peeloff API to support SELinux correctly.
Comment 3 Ondrej Mosnacek 2021-10-20 13:25:35 UTC 
SCTP peeloff is being tested (to some extent) in selinux-testsuite [1], so it is at least expected to work. I received a reproducer from the email from Nokia and I was able to reproduce the issue locally (both on RHEL-8 and upstream kernels). I'm currently trying to identify the root cause.

Since it looks like a kernel/SELinux issue, I'm switching the component and assigning to myself.

[1] https://github.com/SELinuxProject/selinux-testsuite/blob/master/tests/sctp/
Comment 6 Ondrej Mosnacek 2021-10-21 14:32:00 UTC 
I believe I already figured out the cause. The reproducer is different from the existing tests in the testsuite in that it performs peeloff both on the server and client side, while the testsuite only tests it on the server side. It turns out that the original patch that added SCTP SELinux support was missing an additional hook call and as a result the client-side peeloff wouldn't work correctly (the label wouldn't be passed on the peeloff socket and it would show up as unlabeled).

I have identified a possible fix. The next step is to send it upstream for review and to extend the testsuite with client-side SCTP peeloff tests.
Comment 7 Ondrej Mosnacek 2021-10-21 15:58:49 UTC 
Fix and testsuite update posted upstream:
https://lore.kernel.org/selinux/20211021153846.745289-1-omosnace@redhat.com/T/
https://lore.kernel.org/selinux/20211021144543.740762-1-omosnace@redhat.com/T/
Comment 9 Ondrej Mosnacek 2021-10-25 08:45:02 UTC 
(In reply to Arkady Kanevsky from comment #8)
> I assume the same issue exists in RHEL 8.4. 
> Can the proposed fix be backported to 8.4?

Yes, the issue has existed since the initial SCTP support was introduced in SELinux. Once a fix is merged upstream, I'll start the process to get it backported up to RHEL-8.4 (it needs to get into 8.6 first and then via z-stream to 8.5 and 8.4).

After review from SCTP developers it was discovered that my patch is incorrect and the issue needs to be fixed in a different way. Xin Long has already posted a different fix [1] which should be correct. That fix is a bit larger but not complicated and it shouldn't be a problem to backport it to 8.4, too.
Comment 10 Yuval Kashtan 2021-10-25 12:24:30 UTC 
can you add a link to that fix please?
Comment 11 Ondrej Mosnacek 2021-10-25 12:38:24 UTC 
Right, sorry, I forgot to add that link...

[1] https://lore.kernel.org/selinux/cover.1634884487.git.lucien.xin@gmail.com/T/
Comment 21 Ondrej Mosnacek 2022-02-12 18:10:27 UTC 
I have just posted v3 of the patches upstream:
https://lore.kernel.org/selinux/20220212175922.665442-1-omosnace@redhat.com/T/
Comment 22 Ondrej Mosnacek 2022-02-12 18:35:01 UTC 
For reference: the following commits will need to be backported from upstream in addition to the patches above:
21c00a186fac6e035eef5e6751f1e2d2609f969c
c081d53f97a1a90a38e4296dd3d6fda5e38dca2c
e215dab1c49070cd75620afd801f777207a5b65c

They apply cleanly on the 8.6 kernel (likely also 8.5). For 8.4 some manual conflict resolution will be needed.
Comment 59 errata-xmlrpc 2022-05-10 15:02:54 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 (Important: kernel security, 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/RHSA-2022:1988
Note You need to log in before you can comment on or make changes to this bug.