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 1769469 - Selinux won't allow SCTP inter pod communication
Summary: Selinux won't allow SCTP inter pod communication
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: container-selinux
Version: 8.1
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 8.2
Assignee: Jindrich Novy
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
: 1769474 (view as bug list)
Depends On:
Blocks: 1717461 1734579 1769474 1771572 1774382 1779790 1779794
TreeView+ depends on / blocked
 
Reported: 2019-11-06 17:02 UTC by Federico Paolinelli
Modified: 2022-05-06 00:58 UTC (History)
29 users (show)

Fixed In Version: container-selinux-2.123.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1774382 1779790 1779794 (view as bug list)
Environment:
Last Closed: 2020-04-28 15:48:34 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-29886 0 None None None 2022-05-06 00:58:07 UTC
Red Hat Product Errata RHSA-2020:1650 0 None None None 2020-04-28 15:51:03 UTC

Description Federico Paolinelli 2019-11-06 17:02:45 UTC
Description of problem:

Selinux won't allow scpt communication in containers.


How reproducible:
Always

Steps to Reproduce:

I have two container running inside an ocp cluster trying to communicate via sctp.
On client side I execute:

[root@sctpclient-8598b85d98-rgst7 /]# sctp_test -H localhost -P 30100 -h 10.129.0.33 -p 30100 -s
remote:addr=10.129.0.33, port=rwp, family=2
local:addr=::, port=rwp, family=10
seed = 1573058364

Starting tests...
	socket(SOCK_SEQPACKET, IPPROTO_SCTP)  ->  sk=3
	bind(sk=3, [a:::,p:rwp])  --  attempt 1/10


		***bind: can not bind to :::rwp: Permission denied ****

On server side:

[root@sctpserver-86c9c56484-pwjw9 /]# sctp_test -H localhost -P 30100 -l
local:addr=::, port=rwp, family=10
seed = 1573058322

Starting tests...
	socket(SOCK_SEQPACKET, IPPROTO_SCTP)  ->  sk=3
	bind(sk=3, [a:::,p:rwp])  --  attempt 1/10


		***bind: can not bind to :::rwp: Permission denied ****

Actual results:

Output of audit2why on the host:

type=AVC msg=audit(1573057500.176:79): avc:  denied  { node_bind } for  pid=54942 comm="sctp_test" src=30100 scontext=system_u:system_r:container_t:s0:c623,c666 tcontext=system_u:object_r:node_t:s0 tclass=sctp_socket permissive=1
type=AVC msg=audit(1573057500.177:80): avc:  denied  { listen } for  pid=54942 comm="sctp_test" lport=30100 scontext=system_u:system_r:container_t:s0:c623,c666 tcontext=system_u:system_r:container_t:s0:c623,c666 tclass=sctp_socket permissive=1
type=AVC msg=audit(1573057500.177:80): avc:  denied  { module_request } for  pid=54942 comm="sctp_test" kmod="crypto-hmac(sha1)" scontext=system_u:system_r:container_t:s0:c623,c666 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=1
type=AVC msg=audit(1573058322.702:90): avc:  denied  { name_bind } for  pid=119508 comm="sctp_test" src=30100 scontext=system_u:system_r:container_t:s0:c623,c666 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=sctp_socket permissive=0
type=AVC msg=audit(1573058364.617:91): avc:  denied  { name_bind } for  pid=122764 comm="sctp_test" src=30100 scontext=system_u:system_r:container_t:s0:c146,c880 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=sctp_socket permissive=0
type=AVC msg=audit(1573058373.960:92): avc:  denied  { name_bind } for  pid=123560 comm="sctp_test" src=30100 scontext=system_u:system_r:container_t:s0:c623,c666 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=sctp_socket permissive=0

Once adding a custom policy generated via audit2allow, I still have an error on client side:

[root@sctpclient-8598b85d98-rgst7 /]# sctp_test -H localhost -P 30100 -h 10.129.0.33 -p 30100 -s
remote:addr=10.129.0.33, port=rwp, family=2
local:addr=::, port=rwp, family=10
seed = 1573058557

Starting tests...
	socket(SOCK_SEQPACKET, IPPROTO_SCTP)  ->  sk=3
	bind(sk=3, [a:::,p:rwp])  --  attempt 1/10
Client: Sending packets.(1/10)
	sendmsg(sk=3, assoc=0)    1 bytes.
	  SNDRCV(stream=0 flags=0x1 ppid=1943840389

		*** sendmsg: Permission denied ***

Resulted by the subsequent filter on the host:

type=AVC msg=audit(1573058557.794:95): avc:  denied  { name_connect } for  pid=137935 comm="sctp_test" dest=30100 scontext=system_u:system_r:container_t:s0:c146,c880 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=sctp_socket permissive=0


After re-generating the custom policy adding this last one, the client and the server are able to communicate.


Expected results:

Works with no need to add custom selinux policy

Additional info:

Comment 1 Lukas Vrabec 2019-11-06 19:44:46 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.

Comment 2 Lukas Vrabec 2019-11-11 09:42:57 UTC
*** Bug 1769474 has been marked as a duplicate of this bug. ***

Comment 3 Lukas Vrabec 2019-11-11 09:44:06 UTC
PR created: https://github.com/containers/container-selinux/pull/80

Comment 4 Casey Callendrello 2019-11-11 12:53:02 UTC
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.

Comment 5 Perry Myers 2019-11-11 13:23:25 UTC
(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?

Comment 6 Casey Callendrello 2019-11-11 13:54:50 UTC
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?

Comment 7 Dan Winship 2019-11-11 14:04:21 UTC
> 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.

Comment 8 Federico Paolinelli 2019-11-11 15:00:17 UTC
(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.

Comment 9 Perry Myers 2019-11-11 15:10:54 UTC
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?

Comment 10 Federico Paolinelli 2019-11-11 15:17:14 UTC
(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.

Comment 11 Eric Paris 2019-11-11 15:46:26 UTC
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...

Comment 12 Eric Paris 2019-11-11 15:48:06 UTC
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.

Comment 13 Federico Paolinelli 2019-11-11 15:49:26 UTC
(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!

Comment 14 Neil Horman 2019-11-12 16:02:42 UTC
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.

Comment 15 Dan Winship 2019-11-12 16:21:56 UTC
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.

Comment 16 Neil Horman 2019-11-12 16:32:27 UTC
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.

Comment 18 Daniel Walsh 2019-11-14 03:49:47 UTC
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

Comment 19 Daniel Walsh 2019-11-14 03:50:49 UTC
Fixed in container-selinux-2.121.0

Comment 36 Daniel Walsh 2019-11-22 17:55:53 UTC
We need to build v1.121.0

I just created a release for it.

Comment 37 Daniel Walsh 2019-11-22 20:02:10 UTC
Micah, that patch you have is beyond 1.121.0 I believe.

Lukas we need to fix this.

Comment 38 Federico Paolinelli 2019-11-25 10:53:58 UTC
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.

Comment 39 Lukas Vrabec 2019-11-25 16:21:01 UTC
(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?

Comment 40 Jindrich Novy 2019-11-25 16:42:53 UTC
There's container-selinux-2.122.0-1.el8 in container-tools-rhel8-8.2.0 now.

Comment 41 Jindrich Novy 2019-11-25 16:44:33 UTC
Could you please check whether it works fine now Micah?

Comment 42 Micah Abbott 2019-11-25 17:01:34 UTC
(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`?

Comment 43 Jindrich Novy 2019-11-25 17:19:15 UTC
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

Comment 44 Micah Abbott 2019-11-25 18:46:04 UTC
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
...

Comment 45 Micah Abbott 2019-11-25 18:49:22 UTC
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)
```

Comment 46 Daniel Walsh 2019-11-26 12:32:15 UTC
2.123 was updated in master to fix this problem.

Comment 47 Micah Abbott 2019-11-26 16:28:53 UTC
Version container-selinux-2.123.0-1.el8 allows RHCOS to successfully build.  We will make changes to have it included and tested.

Comment 58 errata-xmlrpc 2020-04-28 15:48:34 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://access.redhat.com/errata/RHSA-2020:1650


Note You need to log in before you can comment on or make changes to this bug.