SELinux in enforcing mode breaks nested gVisor container #880
Comments
Proper solutionThe workarounds we've mentioned above work, but each has their caveats:
Let's try to find an alternative. gVisor + SELinuxFirst of all, let's see what's the relationship between gVisor and SELinux. From the get go, we see that any attempt to set an SELinux flag at the gVisor level will fail ( if len(spec.Process.SelinuxLabel) != 0 {
return fmt.Errorf("SELinux is not supported: %s", spec.Process.SelinuxLabel)
}Futhermore, we see the following statement in google/gvisor#8957 (comment), where the original poster is bitten by a similar issue as ours:
So, it doesn't seem we have too much leeway here. Further explorationWe tried to see if we could label the outer container process with a more relaxed type label, that applies to The original Podman container is labeled with Note Our cue for trying this is a similar workaround we saw in gVisor's issue tracker: google/gvisor#8747 (comment) Is
This is spot-on the thing we're doing here, running gVisor's Future workWe could slim down the |
Set the `container_engine_t` SELinux on the **outer** Podman container, so that gVisor does not break on systems where SELinux is enforcing. This label is provided for container engines running within a container, which fits our `runsc` within `crun` situation. We have considered using the more permissive `label=disable` option, to disable SELinux labels altogether, but we want to take advantage of as many SELinux protections as we can, even for the **outer** container. Fixes #880
Mention two SELinux-related errors that we have seen in Fedora systems, explain how can the user verify that they trigger them, and provide a workaround. The first error that we mention will be triggered by every user running gVisor in a Fedora system, so it's good to have a solution for them. The second error was found during the development of Dangerzone, which uses a nested gVisor container within a rootless Podman container. This use case is niche, but it still may help people who are experimenting with gVisor within another container. Refs freedomofpress/dangerzone#880
Mention two SELinux-related errors that we have seen in Fedora systems, explain how can the user verify that they trigger them, and provide a workaround. The first error that we mention will be triggered by every user running gVisor in a Fedora system, so it's good to have a solution for them. The second error was found during the development of Dangerzone, which uses a nested gVisor container within a rootless Podman container. This use case is niche, but it still may help people who are experimenting with gVisor within another container. Refs freedomofpress/dangerzone#880
|
Wish I had seen this over the weekend. Glad it's figured out regardless. Yes, |
Mention two SELinux-related errors that we have seen in Fedora systems, explain how can the user verify that they trigger them, and provide a workaround. The first error that we mention will be triggered by every user running gVisor in a Fedora system, so it's good to have a solution for them. The second error was found during the development of Dangerzone, which uses a nested gVisor container within a rootless Podman container. This use case is niche, but it still may help people who are experimenting with gVisor within another container. Refs freedomofpress/dangerzone#880 FUTURE_COPYBARA_INTEGRATE_REVIEW=#10699 from apyrgio:master ebcb60f PiperOrigin-RevId: 657324569
Mention two SELinux-related errors that we have seen in Fedora systems, explain how can the user verify that they trigger them, and provide a workaround. The first error that we mention will be triggered by every user running gVisor in a Fedora system, so it's good to have a solution for them. The second error was found during the development of Dangerzone, which uses a nested gVisor container within a rootless Podman container. This use case is niche, but it still may help people who are experimenting with gVisor within another container. Refs freedomofpress/dangerzone#880 FUTURE_COPYBARA_INTEGRATE_REVIEW=#10699 from apyrgio:master ebcb60f PiperOrigin-RevId: 657324569
|
Thanks for taking a look Etienne, it's good to know it makes sense to you as well. |
Mention two SELinux-related errors that we have seen in Fedora systems, explain how can the user verify that they trigger them, and provide a workaround. The first error that we mention will be triggered by every user running gVisor in a Fedora system, so it's good to have a solution for them. The second error was found during the development of Dangerzone, which uses a nested gVisor container within a rootless Podman container. This use case is niche, but it still may help people who are experimenting with gVisor within another container. Refs freedomofpress/dangerzone#880 FUTURE_COPYBARA_INTEGRATE_REVIEW=#10699 from apyrgio:master ebcb60f PiperOrigin-RevId: 657324569
Set the `container_engine_t` SELinux on the **outer** Podman container, so that gVisor does not break on systems where SELinux is enforcing. This label is provided for container engines running within a container, which fits our `runsc` within `crun` situation. We have considered using the more permissive `label=disable` option, to disable SELinux labels altogether, but we want to take advantage of as many SELinux protections as we can, even for the **outer** container. Cherry-picked from e1e63d1 Fixes #880
We have stumbled into an SELinux issue that is present only on Fedora systems (not Qubes ones). In order to fix this issue, we need to label our Podman containers with the `container_engine_t` SELinux label. Since this patch strictly affects Fedora systems, and it's just a one-line change, we opt to do the following: * Chery-pick this fix from the main branch into a hotfix-0.7.0 branch. * Bump the patch level of the dangerzone-0.7.0 RPMs from 1 to 2, so that existing installations can be updated. In this commit, we include just the necessary RPMs to achieve the above. Refs freedomofpress/dangerzone#880
|
Final note on the release plan for this patch. Because it strictly affects Fedora systems, and the change is a one-liner, we don't plan to release a new Dangerzone version (e.g., 0.7.1). Instead, we've decided to do the following:
This way, the next time Fedora users perform a |
We have stumbled into an SELinux issue that is present only on Fedora systems (not Qubes ones). In order to fix this issue, we need to label our Podman containers with the `container_engine_t` SELinux label. Since this patch strictly affects Fedora systems, and it's just a one-line change, we opt to do the following: * Cherry-pick this fix from the main branch into a hotfix-0.7.0 branch. * Bump the patch level of the dangerzone-0.7.0 RPMs from 1 to 2, so that existing installations can be updated. In this commit, we include just the necessary RPMs to achieve the above. Refs freedomofpress/dangerzone#880
Update our `env.py` script to auto-detect the correct Dangerzone package name. This is useful when building an end-user environment, i.e., a container image where we copy the respective Dangerzone .deb/.rpm package and install it via a package manager. To achieve this, we replace the hardcoded patch level (`-1`) in the package name with a glob character (`*`). Then, we check in the respective build directory if there's exactly one match for this pattern. If yes, we return the full path. If not, we raise an exception. Note that this limitation was triggered when we were building RPM packages for the 0.7.0 hotfix release. Refs #880
Problem
While debugging a Dangerzone 0.7.0 bug report on a Fedora 40 system (#871), we found out that SELinux in enforcing mode breaks the inner gVisor container that runs within the outer Podman container.
Original error
Output from Podman container with gVisor debug logging enabled
SELinux denial taken from audit logs
Workarounds
We are currently aware of the following two workarounds:
sudo setenforce Permissive--security-opt label=disable(requires changes to Dangerzone code).The text was updated successfully, but these errors were encountered: