loft-sh
Support devcontainers on Linux hosts using SELinux
What happened?
Unable to access mounted workspace directory due to SELinux permissions
What did you expect to happen instead?
Use workspace directory as expected
How can we reproduce the bug?
- Log on a linux distribution using SELinux
- Use DevPod to create and start new devcontainer
- SSH into the contiainer
- touch /workspaces/
/test
My devcontainer.json: none (cloned a fresh git repo)
Local Environment:
- DevPod Version: 0.5.20
- Operating System: linux (Fedora 41)
- ARCH of the OS: AMD64
DevPod Provider:
- Local/remote provider: docker
Anything else we need to know?
I use Podman and its Docker compatibility mode.
There are three workarounds for this:
- Set SELinux as permissive (I've not tried this)
- Append
:Zin .devcontainer.json as described in https://github.com/loft-sh/devpod/issues/970#issuecomment-2297652537, but this is not viable if the devcontainer is used by others - When using Podman: Add label=false to
[container]in $HOME/.config/containers/containers.conf
I think :Z or :z (private or shared SELinux context) or label=false should be set by DevPod.
- Have you tested with
--security-opt=label=disableor--security-opt=label=nestedor a more restrictive label= value?- https://docs.podman.io/en/latest/markdown/podman-build.1.html#security-opt-option https://docs.podman.io/en/v4.6.1/markdown/options/security-opt.html#security-opt-option
- That's how fedora-toolbox:latest (toolbox) and distrobox start containers:
distrobox-create [--nvidia] [--unshare-all] [--help]https://github.com/89luca89/distrobox/blob/c05b6a43769bfa56d572a457f1420e0e2589fe3b/distrobox-create#L661distrobox-enter [--aditional-flags] [--name] [--/-e <bash -l>]distrobox-enter# justMY_VAR=value distrobox-enter --additional-flags "--preserve-fds" --name test -- bash -lhttps://github.com/89luca89/distrobox/blob/main/distrobox-enter
- https://github.com/search?q=repo%3Acontainers%2Ftoolbox%20security-opt&type=code
True, that might be a possibility. But the security-opts must be added as runargs, right? And as far as I know, the runargs are set in the devcontainer-file. However, if I do this, I don't know if it would affect other repository collaborators negatively.
Also, the label can be added to the $HOME/.config/containers/containers.conf-file, but then it affects all containers for that user
What are the alternatives to adding something like runArgsSelinux to the devcontainers spec ?
-
call a script that conditionally includes $runargsSelinux in $runArgs
- this would probably work
- disadvantages:
- there's then a shell with elevated privileges instead of an execve(., *(runargsWithSelinux))
On Fri, Oct 4, 2024, 4:59 AM Håkon Botnmark Jahre @.***> wrote:
True, that might be a possibility. But the security-opts must be added as runargs, right? And as far as I know, the runargs are set in the devcontainer-file. However, if I do this, I don't know if it would affect other repository collaborators negatively.
Also, the label can be added to the $HOME/.config/containers/containers.conf-file, but then it affects all containers for that user
— Reply to this email directly, view it on GitHub https://github.com/loft-sh/devpod/issues/1283#issuecomment-2393200795, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMNSZQIQ72AAQBL7P7UD3ZZZKFPAVCNFSM6AAAAABO5D7LZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJTGIYDANZZGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks @haakobja for reporting the issue and providing a good summary of the problem. I'm not too sure if we should change devpod though to accommodate this, other than document the use case in the docs. I'm unsure of how devpod would detect dynamically that SELinux is running in the local environment to know to edit the .devcontainer.json. Currently we do not mutate this file and expect it to be configured by the developer. Devpod does support using alternative devcontainer.json via --devcontainer-path and --devcontainer-source though. I can see a workaround involving the creation of a .devcontainer.selinux.json and simply pointing devpod to this file for users with SELinux. Do you think that would be appropriate?
@bkneis I think your suggestion would suffice for me at the moment. Thank you.
An alternative may be to add it to the Docker provider, just to make the security label configurable. I never meant for DevPod to detect SELinux automatically.
Devcontainers.json was specified by ms for windows, which doesn't have selinux; so it may be reasonable to request extra attrs for selinux in the devcontainers spec.
Do other tools have solutions for this?
On Mon, Oct 7, 2024, 4:30 AM Håkon Botnmark Jahre @.***> wrote:
@bkneis https://github.com/bkneis I think your suggestion would suffice for me at the moment. Thank you.
An alternative may be to add it to the Docker provider, just to make the security label configurable. I never meant for DevPod to detect SELinux automatically.
— Reply to this email directly, view it on GitHub https://github.com/loft-sh/devpod/issues/1283#issuecomment-2396261390, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMNS2RNRPMIEFFC33KAMDZ2JBBVAVCNFSM6AAAAABO5D7LZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJWGI3DCMZZGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
@westurner @haakobja Looking at the spec I can actually see it already supports the attribute securityOpt which devpod then passes onto the docker run - https://github.com/loft-sh/devpod/blob/main/pkg/driver/docker/docker.go#L283
You should be able to add any of the security options you need there :)
I guess that's what you get for looking at the spec; devcontainers.json JSON Reference: https://containers.dev/implementors/json_reference/
remoteUser 🏷️ string: Overrides the user that devcontainer.json supporting services tools / runs as in the container (along with sub-processes like terminals, tasks, or debugging). Does not change the user the container as a whole runs as which can be set using containerUser. Defaults to the user the container as a whole is running as (often root). You may learn more in the remoteUser section below.
capAdd 🏷️ array: Defaults to []. Cross-orchestrator way to add capabilities typically disabled for a container. Most often used to add the ptrace capability required to debug languages like C++, Go, and Rust. For example:
"capAdd": ["SYS_PTRACE"]securityOpt 🏷️ array: Defaults to []. Cross-orchestrator way to set container security options. For example:
"securityOpt": [ "seccomp=unconfined" ]
For jupyter-docker-stacks the other day I had:
--security-opt label=disable --userns=keep-id:uid=1000,gid=100
Shouldn't it be possible to omit the securityOpt label=disable and instead use :z/:Z to relabel volumes (that cross an (selinux) context boundary) and --userns to remap uid and gid of the [rootless] user that owns the mounted volume to the necessary uid and gid within the container?
The podman run docs (man podman-run) have an example of
--userns=keep-id:uid=,gid=:
https://docs.podman.io/en/latest/markdown/podman-run.1.html
Though is it better to run --userns=auto:size=2 for root and an app user?
(I've fixed the email markdown formatting, which gh now mangles unfortunately).
How should -userns=keep-id:uid=1000,gid=100 be specified to get e.g. the jupyter/scipy-notebook docker stack working with Fedora 40 (and other RH linux distros like RHEL, SUSE, Rocky, Alma)?
I think :Z or :z (private or shared SELinux context) or label=false should be set by DevPod.
I agree with @haakobja in suggesting that :Z or :z should be set automatically by DevPod if SELinux is active and the user configured DevPod as such (so it could be a new config option added to DevPod).
Other developer tools and IDEs are already doing the same, see for example Jetbrains products (e.g. IntelliJ IDEA or PyCharm): https://www.jetbrains.com/help/idea/docker-containers.html#bind_mounts_selinux
This would be especially important in devcontainers (and DevPod) as some of the mounts are not under the control of the user, for example devcontainer features can add mounts themselves.
