Bug 1883945
| Summary: | Cannot mount /proc/net in a container as it is a symlink to /proc/self/net and not assigned proc_t | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Robb Manes <rmanes> |
| Component: | container-selinux | Assignee: | Jindrich Novy <jnovy> |
| Status: | CLOSED ERRATA | QA Contact: | Edward Shen <weshen> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.2 | CC: | dornelas, dwalsh, jnovy, kanderso, ptalbert, sgarciam, tsweeney, ypu |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | container-selinux-2.148.0 or newer | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-02-16 14:21: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: | 1186913, 1823908 | ||
Just also pointing out that this fails as well identically, not just mounting /proc/self/net, I just included the symlinked version by accident in the initial bug report: # podman run --privileged --rm -ti -v /proc/net:/mnt/rootfs/proc/net nginx bash -c "ls /mnt/rootfs/proc/net &>/dev/null && echo Works" What exactly are you trying to do? Do you want to run a privileged container on the host network? podman run --privileged --net=host ... Should do that? >> What exactly are you trying to do? Do you want to run a privileged container on the host network?
We want to do what the bugzilla title says: mount /proc/net in a container. Not /proc nor / but /proc/net directly.
Why do you want to do this? >> Why do you want to do this?
Why not? Customers have their reasons and it just fails.
Is there a reason why /proc/net cannot be mounted not even with --privileged --net=host due to SELinux constrains as Robb explains? Is he wrong? Are we preventing such mount on purpose?
No we are failing to communicate. I am not against this, but I want to know what the customer is after. /proc/net is related to the network namespace that the container is running within. Mount the hosts /proc/net into the container makes little sense, and will probably not work the way that the customer thinks, at least as I understand it. Using --net=host which will use the /proc/net of the host, makes more sense and is not going to cause the kernel issues, I believe. This is what I am seeing when I do this: podman run --privileged -v /proc/net:/proc/net alpine echo hello Error: OCI runtime error: move mount to 'proc/net': Device or resource busy I have updated container-selinux to allow this, but I really would like to understand the goal. container-selinux-2.148.0-1 Customer is deploying an application from a 3rd party vendor which tries to mount /proc/net into a directory inside the pod to inspect the traffic and make cost estimation based on the data. It works in other environments (not OpenShift) but fails when using OpenShift and our RHCOS installation. I tend to not question customer needs more than the reasonable in order to help them. That's why I suggested to mount /proc and/or / and reach the content under /proc/net but as it's a 3rd party they can't change the way the application works. On the other hand, the fact that it's not related with the 3rd party application as a simple "podman run" also fails, we agreed to raise a bugzilla after Robb's troubleshooting at a low level. 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 (Moderate: container-tools:rhel8 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-2021:0531 |
Description of problem: When running a rootful container in podman or any container engine, it is quite possible to mount the host's /proc into the container, but not anything that is inside of /proc/net as it exists as a symlink to /proc/self/net and is made with unconfined_t as it's default. As an example: # podman run --privileged --rm -ti -v /proc/self/net:/mnt/rootfs/proc/net nginx bash -c "ls /mnt/rootfs/proc/net &>/dev/null && echo Works" Error: set propagation for `mnt/rootfs/proc/net`: Permission denied: OCI runtime permission denied error The audit log shows a mounton denial: time->Wed Sep 30 09:40:07 2020 type=AVC msg=audit(1601473207.260:1108): avc: denied { mounton } for pid=124478 comm="3" path="/var/lib/containers/storage/overlay/6a99a39e08844c64719eb6b409f2c3c1c45f7cc5934f563cf3adf6e043fee2ba/merged/mnt/rootfs/proc/net" dev="proc" ino=801978 scontext=unconfined_u:system_r:container_runtime_t:s0 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=dir permissive=0 Which is expected as the /proc/net directory is a symlink to /proc/self/net to account for the current process's network namespace: # ls -lZd /proc dr-xr-xr-x. 413 root root system_u:object_r:proc_t:s0 0 Sep 24 18:53 /proc # ls -lZd /proc/net lrwxrwxrwx. 1 root root system_u:object_r:proc_t:s0 8 Sep 24 18:53 /proc/net -> self/net # ls -lZd /proc/self/net dr-xr-xr-x. 65 root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0 Sep 30 10:04 /proc/self/net This commit (https://github.com/containers/container-selinux/commit/028ab0049681265664a3bbae7501bc5bddcd6cc0) in container-selinux allows for the addition of containers to mount /proc and no longer get mounton denials, but obviously as the /proc/net and /proc/self/net are made on-demand by the process of spawning a new process, they are assigned a default unconfined_t and therefore appear rejected. I understand the reason for this is that, since /proc/net is just a reflection of the host's init_net network namespace in /proc/self/net, it is made with unconfined_t at the time the new process spawns; because of this, however, we are forced to mount all of /proc and mounting in /proc/net or /proc/self/net isn't possible. Is it expected that in order to have access to /proc/net on the host, you will have to mount in all of /proc, or is there a way to allow /proc/self/net to have type proc_t and therefore get around having to provide access to the entirety of the host? Or is this risky to do/no way to do this on SELinux enabled systems? Also note this isn't denied outside of a container, just within it; doing `mount --bind` on /proc/net/self will work (but not in a container context). Version-Release number of selected component (if applicable): Any OpenShift version, any podman/crio build Tested with container-selinux-2.145.0-1.fc32.noarch How reproducible: Every time Steps to Reproduce: 1. Run podman command to mount /proc/net and observe error: # podman run --privileged --rm -ti -v /proc/self/net:/mnt/rootfs/proc/net nginx bash -c "ls /mnt/rootfs/proc/net &>/dev/null && echo Works" Error: set propagation for `mnt/rootfs/proc/net`: Permission denied: OCI runtime permission denied error 2. Use ausearch to find denial audit log: time->Wed Sep 30 09:40:07 2020 type=AVC msg=audit(1601473207.260:1108): avc: denied { mounton } for pid=124478 comm="3" path="/var/lib/containers/storage/overlay/6a99a39e08844c64719eb6b409f2c3c1c45f7cc5934f563cf3adf6e043fee2ba/merged/mnt/rootfs/proc/net" dev="proc" ino=801978 scontext=unconfined_u:system_r:container_runtime_t:s0 tcontext=unconfined_u:system_r:container_runtime_t:s0 tclass=dir permissive=0 Actual results: Mounting is denied with `mounton` as /proc/net/self is unconfined_t and container-selinux only accounts for proc_t within /proc. Expected results: Mounting (should?) allow /proc/net to be mounted into a contianer Additional info: For anyone experiencing this, current workaround is just to mount all of /proc into the container, that will work fine assuming SElinux is enforcing, the container is privileged, and if in OpenShift your SCC is properly configured.