Defense in Depth - SELinux

[apyrgio]

Parent issue: #221

If an attacker manages to escape the container, we want to restrict them as much as possible. One way to do so is by using SELinux, which is also mentioned in the CIS Docker advisories (official link, mirror).

There are several issues that make the adoption of an SELinux policy by Dangerzone a bit difficult though:

1. Generating an SELinux policy is notoriously difficult.
2. Enforcing an SELinux policy typically requires using Fedora/CentOS hosts, which is not the case for Docker Desktop on Windows/MacOS, which uses Alpine Linux (see https://gitlab.alpinelinux.org/alpine/aports/-/issues/8606)

Once we circumvent these issues, we should check if Dangerzone can take advantage of enforcing SELinux on the host.

[deeplow]

A user reported here having issues running dangerzone on a SELinux-enabled system.

[apyrgio]

This is an interesting project that we can have in mind for generating SELinux labels: https://github.com/containers/udica

[apyrgio]

As part of fixing #880, we apply the container_engine_t label to the outer container. This action is basically a no-op for most hosts, except those that use SELinux in enforcing mode.

Ultimately, if a Linux host does not use SELinux, there's no way for Dangerzone to "enable" it. This is an administrative action, and one that may break the workflow of lots of users. As for Windows and macOS, the same issue applies, plus the fact that we have even less control on the Linux VM.

Given that with gVisor, the inner container does not have the capability to open files (due to gVisor's strict seccomp filter), we believe that we have a similar protection as SELinux, in the rare case of container escapes. If we also consider that Dangerzone can utilize SELinux in enforcing mode, then we think it's safe to close this issue.

[EtiennePerot]

Given that with gVisor, the inner container does not have the capability to open files (due to gVisor's strict seccomp filter)

To be pedantic, this is actually not true in the configuration that Dangerzone uses, which uses DirectFS, which allows the openat(2) system call in the seccomp filters. However, these are restricted to a handful of file descriptors that correspond to explicit host mountpoints in the OCI config, of which the only one in the Dangerzone configuration is the container image rootfs. There are also other restrictions, such as requiring O_NOFOLLOW, forbidding directory FDs from being passed through in this manner, etc. More details in the DirectFS blog post. It's a tradeoff for (a lot more) I/O speed vs (a little less) security, and can be turned off with --directfs=false. Given that Dangerzone is not performance-sensitive, perhaps this is the right thing to do. Sent #898 to do just that.