SELinuxProject/selinux-kernel

RFE: Enabling SELinux peer labeling

JayJay-K opened this issue · 9 comments

JayJay-K commented

I'm struggling with peer labeling in SCTP
I saw content "https://www.kernel.org/doc/html/v4.18/security/SELinux-sctp.html#sctp-peer-labeling".
It says "1. If peer labeling is not enabled, then the peer context will always be SECINITSID_UNLABELED (unlabeled_t in Reference Policy)."

In my understanding 'peer labeling' can be enabled or disabled in linux system.
Can I ask how to enable 'peer labeling' in linux system?
It's hard to find a way to do in the internet.

pcmoore commented

I assume you figured this out?

JayJay-K commented

No, I still have problem.
Thank you for your comment.
Could you please check my question?

In detailed, I met a SELinux error in SCTP association (re-association).
with scontext=unlabeled_t, tcontext=unlabeled_t, type=sctp_socket, class=association.
I found the error occur in security/selinux/hooks.c:5385 selinux_sctp_assoc_request() function
I hope to know what is a right way to resolve this problem. candidates are;

  1. Just add SELinux allow policy. (allow unlabeled_t unlabeled_t:sctp_socket association)
  2. Enable 'peer labeling'. (assume that the error occur, because peer-labeling is disabled)
    What is a right way? If answer is number '2', how can I enable peer labeling?
    (It runs on the container environment, OCP)
WOnder93 commented

Oh, SCTP... That sounds like you're actually hitting a kernel bug that me and Xin Long tried to fix with [1] (or some variant of it). However, the patches needed some rework and I got sidetracked with other things, so the bug is not fixed yet... Good news is that I recently switched my attention back to this bug and am currently working on finalizing the proper fix.

[1] https://lore.kernel.org/selinux/cover.1635854268.git.lucien.xin@gmail.com/T/

pcmoore commented

Hi @JayJay-K, as @WOnder93 mentioned above there are definitely some issues around SELinux and SCTP at the moment, but @WOnder93 is working on it and I'm sure we'll get it resolved soon(ish) :)

However, if you're asking more generally about configuring network labeling there are a few places where you can find information. The SELinux Notebook has a section on the SELinux network access controls:

... and I've also written a number of blog posts over the years trying to help explain how labeled networking works, complete with some examples. You can find them at the link below, look for the "selinux" and "netlabel" tags:

I hope that helps!

JayJay-K commented

Thank you for your information.
Additionally, may I ask you some workaround for the problem before the problem is fixed?
I hope to know expert's opinion what is the best way to avoid it with current version. :-)

Now, I handle the problem in the container environment. (OCP with kubernetes)
And a 'host server' is not my area, so I can't add SELinux allow rule to the host server.
(e.g. "allow unlabeled_t unlabeled_t:sctp_socket association")

So, I'm searching for 'selinuxOptions' in the 'securityContext' to configure pods.
Can I add SELinux allow rule to pods with selinuxOptions? and how?
I'm checking following links, but it's hard to find exact way.

pcmoore commented

Hi @JayJay-K, unfortunately I don't have much experience running OCP and/or K8s so I'm not sure I can be of much help there, I'm sorry :/

WOnder93 commented

@JayJay-K One of our engineers created a configuration that applies a workaround for this exact issue (via a SELinux policy module) and he made it available on GitHub:
https://github.com/yuvalk/ocp-security/blob/master/sctp/selinux_custom.deployment.yaml

Use at your own risk :)

JayJay-K commented

Thank you @WOnder93. I hope to add one more question.
How can I be sure that my error occur because of the kernel bug you mentioned?

Actually, I'm not familiar with SCTP, so it was hard to understand exact meaning of link:
[1] https://lore.kernel.org/selinux/cover.1635854268.git.lucien.xin@gmail.com/T/

I met following error when SCTP socket do assoc again (re-assoc?) with different SID:
type=AVC msg=audit(1644235060.178:460343): avc: denied { association } for pid=174 comm="ksoftirqd/20" laddr=2001:db8:b03:215::27:9901 lport=36422 faddr=2001:db8:b05:3001:222:0:24:4 fport=36422 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=sctp_socket permissive=0

Could you please let me know a way that I'm sure my error occur because of the kernel bug, if you know?

WOnder93 commented

@JayJay-K Yeah, it's pretty complicated stuff... But I'd say you can quite safely assume that you are running into this bug. I don't see any other way you could get it (and you're also not the first one to hit it on OCP).

Actually you may find a bit of useful information about the bug in the relevant RH bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=2048251

I tried to TL;DR the bug in the Doc Text and there is a more detailed low-level explanation in comment 36. There is also a crude reproducer attached, but be aware that it has a race condition and sometimes fails on its own. It also hits another related bug (https://bugzilla.redhat.com/show_bug.cgi?id=2015525), which is fixed by the same set of kernel patches.

  • 👍1