Bug 1769469
Summary: | Selinux won't allow SCTP inter pod communication | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Federico Paolinelli <fpaoline> | |
Component: | container-selinux | Assignee: | Jindrich Novy <jnovy> | |
Status: | CLOSED ERRATA | QA Contact: | atomic-bugs <atomic-bugs> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 8.1 | CC: | ajia, augol, cdc, danw, ddarrah, dornelas, dwalsh, eparis, fsimonce, imcleod, jligon, jnovy, jwboyer, lsm5, lvrabec, miabbott, mmalik, nhorman, plautrba, pmyers, pthomas, rkhan, ssekidde, toneata, tsweeney, walters, weshen, william.caban, zpytela | |
Target Milestone: | rc | Keywords: | ZStream | |
Target Release: | 8.2 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | container-selinux-2.123.0-1.el8 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1774382 1779790 1779794 (view as bug list) | Environment: | ||
Last Closed: | 2020-04-28 15:48:34 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: | 1717461, 1734579, 1769474, 1771572, 1774382, 1779790, 1779794 |
Description
Federico Paolinelli
2019-11-06 17:02:45 UTC
Hi All, name_connect and name bind should be allowed in containers policy to allow connect an bind on all ports. corenet_sctp_bind_all_ports corenet_sctp_connect_all_unreserved_ports THanks, Lukas. *** Bug 1769474 has been marked as a duplicate of this bug. *** I'm not sure that we want to allow that without careful consideration. Given that the SCTP module hasn't seen a lot of use, there is some concern that it may harbor as-yet undiscovered security issues. Thus, we block it's use via selinux. If we're going to allow it (by containers, no less), then I'd like to see an assurance that it's been more carefully tested. I would prefer, instead, documentation for how to allow sctp as needed. It is my understanding that most (all?) users of SCTP do so with userspace stacks. (In reply to Casey Callendrello from comment #4) > I'm not sure that we want to allow that without careful consideration. > > Given that the SCTP module hasn't seen a lot of use, there is some concern > that it may harbor as-yet undiscovered security issues. Thus, we block it's > use via selinux. If we're going to allow it (by containers, no less), then > I'd like to see an assurance that it's been more carefully tested. > > I would prefer, instead, documentation for how to allow sctp as needed. It > is my understanding that most (all?) users of SCTP do so with userspace > stacks. I believe the plan is to leave SCTP blacklisted in default RHEL and RHCOS installs as well as to have the module installed only as part of kernel-modules-extras subpackage. That means that sctp.ko wouldn't be on a default RHEL install (unless you pulled in that package explicitly). In addition, blacklisting it means a system admin (root) would need to unblacklist it first before it could be loaded. An RHCOS or RHEL user who wants to use SCTP in OpenShift would first need to use a Machine Config Operator (MCO) to unblacklist the module as part of their node deployment configuration. Does that mitigate your concerns at least partially? Fair enough, that does seem reasonable. However, I do believe that package is already installed in RHCOS (for unrelated reasons), so we'd be relying exclusively on the module staying blacklisted. Is there any reasonable way to drop-in SELinux policies via MCO? > I believe the plan is to leave SCTP blacklisted in default RHEL and RHCOS > installs as well as to have the module installed only as part of > kernel-modules-extras subpackage. That is correct for RHEL. For RHCOS, it is shipped as part of the RHCOS image, but is still blacklisted (bug 1718049). > In addition, blacklisting it means a > system admin (root) would need to unblacklist it first before it could be > loaded. Our SELinux policy blocks containers from causing any kernel module to be autoloaded for any reason. So even if the admin unblacklists sctp.ko, containers *still* can't cause it to be loaded. The only way SCTP will be available to containers is if the admin explicitly modprobes the module (or if a non-containerized process causes it to be autoloaded by creating an SCTP socket). In the OCP / RHCOS case at least, if the admin manually loads sctp.ko (presumably via some as-yet-undocumented MCO hackery), that signals that they want SCTP to be available to containers, and so we don't need or want any SELinux rules blocking access to SCTP sockets at that point. But there may be use cases on RHEL in general where an admin wants non-containerized processes to be able to use SCTP, while still having containers be more locked-down. (In reply to Dan Winship from comment #7) > > I believe the plan is to leave SCTP blacklisted in default RHEL and RHCOS > > installs as well as to have the module installed only as part of > > kernel-modules-extras subpackage. > > That is correct for RHEL. For RHCOS, it is shipped as part of the RHCOS > image, but is still blacklisted (bug 1718049). > > > In addition, blacklisting it means a > > system admin (root) would need to unblacklist it first before it could be > > loaded. > > Our SELinux policy blocks containers from causing any kernel module to be > autoloaded for any reason. So even if the admin unblacklists sctp.ko, > containers *still* can't cause it to be loaded. The only way SCTP will be > available to containers is if the admin explicitly modprobes the module (or > if a non-containerized process causes it to be autoloaded by creating an > SCTP socket). Just to add a bit more, I think (from what I saw while testing) the modules will get autoloaded also if the module is unblacklisted AND the loading container is privileged. > > In the OCP / RHCOS case at least, if the admin manually loads sctp.ko > (presumably via some as-yet-undocumented MCO hackery), that signals that > they want SCTP to be available to containers, and so we don't need or want > any SELinux rules blocking access to SCTP sockets at that point. > Another approach to load the script via MCO would be to have it loaded at boot time. > But there may be use cases on RHEL in general where an admin wants > non-containerized processes to be able to use SCTP, while still having > containers be more locked-down. Suggestion from an off bz email thread would be to use an SELinux boolean to make the policy more restrictive by default. If someone unblacklists the module, they can also set the SELinux boolean at that same time. Does this approach make sense? (In reply to Perry Myers from comment #9) > Suggestion from an off bz email thread would be to use an SELinux boolean to > make the policy more restrictive by default. > If someone unblacklists the module, they can also set the SELinux boolean at > that same time. Does this approach make sense? Was about to reply on the email thread. The only doubt I have right now is wether we will be able to achieve that using MCO, since my understanding is flipping a selinux boolean requires an imperative approach (calling setsebool) as opposed to what we can do with MCO (changing the whole content of a file). But I am probably missing some piece here. I'm with Lukas: corenet_sctp_bind_all_ports corenet_sctp_connect_all_unreserved_ports Is Good. module_request - absolutely not I don't really mind if it is behind a boolean or not, we'll have to turn it on by default for RHCOS. I'll poke the MCO team to see if anyone knows if it's even possible to twiddle them... I guess one could always run a systemd script that twiddles a boolean on startup. So it is possible with the MCD, just not clealy. (In reply to Eric Paris from comment #12) > I guess one could always run a systemd script that twiddles a boolean on > startup. So it is possible with the MCD, just not clealy. Oh, you are right. Thanks! In regards to comment #4, I don't think its at all fair to assume that SCTP hasn't seen alot of use. SCTP has been an available kernel module since RHEL5, and several customers/partners make heavy use of it, including the in-kernel distributed lock manager. It reach isn't as far as TCP or UDP (those are largely ubiquitous), but it gets a fair amount of use. I think it would be reasonable to consider making it a first class citizen. The concern isn't that SCTP may have bugs that make it not work, it's that it may have bugs that make it insecure (eg, CVE-2019-8956, which, OK, didn't affect RHEL, but it's hardly the only SCTP-related CVE). The Network Services team says that the SCTP code has gotten a lot better in the last few years, and a bunch of bugs have been found as a result of fuzzing the code. So maybe some day we'll trust it more, but my understanding is that currently the people who actually hack on that code agree that it is best to not have it enabled on systems that aren't using it. I get that, but the suggestion in comment #4 was that SCTP doesn't see much use, and thats not the case. It sees extensive use in various environments, its just not as ubiquitous as TCP or UDP. In the current policy the only thing I see not allowed is allow container_t self:sctp_socket listen; This is fixed in the container-selinux PR 1589288995c882d9d05bef60fb7c799d2148060c Fixed in container-selinux-2.121.0 We need to build v1.121.0 I just created a release for it. Micah, that patch you have is beyond 1.121.0 I believe. Lukas we need to fix this. Just one question: I see in https://github.com/containers/container-selinux/commit/1589288995c882d9d05bef60fb7c799d2148060c that allow container_net_domain self:sctp_socket listen; was added, as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1769469#c18 In the logs I added, I see denials also for node_bind, name_bind, connect. Probably I am missing something but I just wanted to be sure that after this lands we will be able to use sctp from containers. (In reply to Daniel Walsh from comment #36) > We need to build v1.121.0 > > I just created a release for it. What exactly you mean? There's container-selinux-2.122.0-1.el8 in container-tools-rhel8-8.2.0 now. Could you please check whether it works fine now Micah? (In reply to Jindrich Novy from comment #41) > Could you please check whether it works fine now Micah? Would it be possible to tag that build with `rhaos-4.3-rhel-8-candidate`? The version in "Fixed In Version" is now built also for rhaos-4.3-rhel-8-candidate: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=24945267 Still seeing RHCOS build problems with 2.122: ``` container-selinux-2:2.122.0-1.el8.noarch (art-rhcos-4.3) ... Initializing rootfs Moving /usr to target Copying toplevel compat symlinks Recompiling policy Re-declaration of type container_ro_file_t Failed to create node Bad type declaration at /etc/selinux/targeted/tmp/modules/100/virt/cil:133 semodule: Failed! error: Finalizing rootfs: Executing bwrap(semodule): Child process killed by signal 1 ... FWIW, RHCOS is also pulling in: ``` selinux-policy-3.14.3-20.el8.noarch (rhel8-baseos) selinux-policy-targeted-3.14.3-20.el8.noarch (rhel8-baseos) ``` 2.123 was updated in master to fix this problem. Version container-selinux-2.123.0-1.el8 allows RHCOS to successfully build. We will make changes to have it included and tested. 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://access.redhat.com/errata/RHSA-2020:1650 |