Bug 2015525

Summary:	SCTP peel-off with SELinux and containers in OCP
Product:	Red Hat Enterprise Linux 8	Reporter:	zeikman
Component:	kernel	Assignee:	Ondrej Mosnacek <omosnace>
kernel sub component:	SELinux	QA Contact:	Milos Malik <mmalik>
Status:	CLOSED ERRATA	Docs Contact:	Jan Fiala <jafiala>
Severity:	medium
Priority:	high	CC:	akanevsk, blitton, bpn, bzvonar, cgaynor, cmandras, dwalsh, ealcaniz, eglottma, hyoskim, jafiala, jbainbri, jshortt, kholtz, lvrabec, lxin, mleitner, mmalik, mzasepa, omosnace, phuet, pprahlad, ptalbert, scorcora, tsweeney, xzhou, yazheng, ykashtan
Version:	8.5	Keywords:	AutoVerified, Triaged, ZStream
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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.	Story Points:	---
Clone Of:
Clones:	2054111 2054112 (view as bug list)		Environment:
Last Closed:	2022-05-10 15:02:54 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:
Bug Depends On:
Bug Blocks:	2048251, 2054111, 2054112

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