[DISC]: SELinux context and mounting volumes

[asreimer]

SELinux poses some interesting challenges when bind mounting in Docker. To date, we have relied on detecting SELinux and, if found, appending a "Z" to the mounting permissions like so.

When using the "Z" option, docker modifies the SELinux context for a file (you can see context with the -Z option for ls, e.g. ls -Z some_file). So, if a hypothetical user were to mount their /home/username directory into a container, we change the entire home directory's SELinux context, which has side effects for things like SSH. For example, we encountered an error: SELinux is preventing sshd from read access on the file authorized_keys. because the .ssh/authorized_keys context was changed from unconfined_u:object_r:ssh_home_t:s0 to system_u:object_r:container_file_t:s0:c283,c630.

Possible solutions are:

1. Depend on podman in Linux instead of Docker. It has a python SDK that we can use. Here's a nice workflow example.
   a. Does this solve the SELinux issue or only the UID/GID issue [DISC]: mounted storage running docker on Ubuntu no writing permissions #13?
2. Run containers as privileged
3. Run containers with --security-opt label=disable
   a. Create a docker_testing directory
   b. Run a container and mount the docker_testing directory in: For example, docker run -it --rm --security-opt label=disable -v /path_to/docker_test:/testing alpine sh
   c. Do with both with and without the --security-opt label=disable argument and see if you can access the contents of /testing within the container. With the label=disable, you should be able to access it and only the UID/GID of the user in the container will mismatch.
4. Investigate other solutions?

Feel free to edit this post to add more items to the list.

[asreimer]

After group discussion offline, option 3 seems best, but we need to investigate the security implications more fully.