Allow basic sandboxing of containers #1413
Conversation
distrobox-create now supports following options: `--unshare-home`: Unshares host home directory `--unshare-root`: Unshares host root directory
distrobox-create now supports a following option: `--unprivileged`: Runs container without --privileged switch, and without disabling labels and apparmor confinement.
dbus mounted into a container provides an access to the root partition.
|
Hi @xdom I'll take a deeper look at this ASAP this is a big change and I'd like to do further testing |
There was a problem hiding this comment.
First of all: great job! :D I am reviewing this right now, because I was literally bolting this on top of distrobox via bwrap/bubblewrap for my development containers. Nice to see this PR instead. I am 100% using it ^^
I had some minor nitpicks about grammar, which I marked in the review, and have a few open questions. Don't worry about the amount of comments, I marked basically the same thing in all places for your convenience ^^
Could you explain what the benefit of having an unshared root is? I struggle to see them right now.
After reading this blog entry, the unprivileged mode seems pretty desirable as well. Do you know if it implies any major drawbacks?
If @89luca89 wants a thorough discussion about the unprivileged mode and unshared root feature, could we merge the unshared home feature separately? It's pretty practicable and not as big of a change :D
| unshare_ipc=1 | ||
| unshare_home=1 |
There was a problem hiding this comment.
These appear to be alphabetically sorted. I'd exchange these to follow the pattern :D
| unshare_ipc=1 | |
| unshare_home=1 | |
| unshare_home=1 | |
| unshare_ipc=1 |
| --unprivileged: do not drop security measures when creating a container | ||
| --unshare-devsys: do not share host devices and sysfs dirs from host | ||
| --unshare-groups: do not forward user's additional groups into the container | ||
| --unshare-home: do not mount host home directory into the container |
There was a problem hiding this comment.
Nice description! I think grammatically, there is a small mistake.
I'm going to mark the other spots for convenience, so you could just click "accept suggestion".
| --unshare-home: do not mount host home directory into the container | |
| --unshare-home: do not mount host's home directory into the container |
| --unshare-ipc: do not share ipc namespace with host | ||
| --unshare-netns: do not share the net namespace with host | ||
| --unshare-process: do not share process namespace with host | ||
| --unshare-process: do not share process namespace with host | ||
| --unshare-root: do not mount host root directory into the container |
There was a problem hiding this comment.
Same as the --unshare-home flag ^^
| --unshare-root: do not mount host root directory into the container | |
| --unshare-root: do not mount host's root directory into the container |
| elif ! [ "${unshare_home:-0}" -eq 0 ]; then | ||
| # Workdir is unshared, we just enter $HOME of the container. | ||
| workdir="${container_home}" |
| { | ||
| mount -t devpts devpts -o noexec,nosuid,newinstance,ptmxmode=0666,mode=0620,gid=tty /dev/pts/ | ||
| mount --bind /dev/pts/ptmx /dev/ptmx | ||
| } || printf "Warning: Cannot mount devpts\n" |
There was a problem hiding this comment.
Nice to have a warning there. Is there a particular reason, why you did not prepend it with "distrobox: ..." or why you don't print to stderr? Not sure how distrobox normally handles warnings.
| '--unshare-devsys[do not share host devices and sysfs dirs from host]' \ | ||
| '--unshare-groups[do not forward user''s additional groups into the container]' \ |
| '--unshare-devsys[do not share host devices and sysfs dirs from host]' \ | ||
| '--unshare-groups[do not forward user''s additional groups into the container]' \ | ||
| '--unshare-home[do not mount host home directory into the container]' \ |
There was a problem hiding this comment.
see other comment
| '--unshare-home[do not mount host home directory into the container]' \ | |
| '--unshare-home[do not mount host''s home directory into the container]' \ |
| '--unshare-ipc[do not share ipc namespace with host]' \ | ||
| '--unshare-netns[do not share the net namespace with host]' \ | ||
| '--unshare-process[do not share process namespace with host]' \ | ||
| '--unshare-root[do not mount host root directory into the container]' \ |
There was a problem hiding this comment.
See other comment
| '--unshare-root[do not mount host root directory into the container]' \ | |
| '--unshare-root[do not mount host''s root directory into the container]' \ |
| --unshare-devsys: do not share host devices and sysfs dirs from host | ||
| --unshare-groups: do not forward user\[aq]s additional groups into the container | ||
| --unshare-home: do not mount host home directory into the container |
There was a problem hiding this comment.
Same as above
| --unshare-home: do not mount host home directory into the container | |
| --unshare-home: do not mount host's home directory into the container |
| --unshare-ipc: do not share ipc namespace with host | ||
| --unshare-netns: do not share the net namespace with host | ||
| --unshare-process: do not share process namespace with host | ||
| --unshare-root: do not mount host root directory into the container |
There was a problem hiding this comment.
Same as above
| --unshare-root: do not mount host root directory into the container | |
| --unshare-root: do not mount host's root directory into the container |
|
Have been running your PR today and the unshared root and home features work great! :D Running in unprivileged mode, is not working for me. However, I run openSUSE Aeon which enables SELinux and is in pre-release. Therefore, this is likely an issue with my system and not with your code. These are the steps to reproduce it, just in case you want to take a closer look at it. $ distrobox create --unprivileged --home "$(mktemp -d)" unpriv
$ distrobox enter unprivIt fails with a permission denied, which I suspect could be because of SELinux policies. + mount --rbind -o ro /run/host/usr/share/zoneinfo/Europe/Berlin /etc/localtime
mount: /etc/localtime: permission denied.
dmesg(1) may have more information after failed mount system call.
+ printf 'Warning: failed to bind mount %s to %s\n' /run/host/usr/share/zoneinfo/Europe/Berlin /etc/localtime
Warning: failed to bind mount /run/host/usr/share/zoneinfo/Europe/Berlin to /etc/localtime
+ return 1
+ '[' 1 -ne 0 ']'
+ printf 'Error: An error occurred\n'
Error: An error occurred
DEBU[0000] Called logs.PersistentPostRunE(podman --log-level debug logs unpriv)
DEBU[0000] Shutting down engines The full log is available here: unpriv_log.txt |
|
I'd like to reflect on the implication of this (and #28 ) What are the use cases for this? The main use case of using This invalidates all the usecases of distrobox
So my question is: Isn't using podman directly a better alternative? I feel like all of this PR (and #28 in general) are going in the opposite direction of what the projects aims to do. Sandboxing is not a target for distrobox, it may add some unsharing bits for useful purposes (say, initful containers) but it's not aiming to replace podman/docker/flatpak |
|
Thanks for the response @89luca89. For me the use case is primarily having a separate home for my development distrobox, because the tools I use: (Elixir's mix, Rust's cargo, OCaml's opam etc.) litter my home directory. Therefore, I keep my main home clean and remove the complete distrobox when I decide it's time for some clean-up. That said, I agree, an unshared root and unprivileged mode might go to far for distrobox's scope and you'd be better of using Podman or bubblewrap directly. This way it's not implied that distrobox is a sandboxing tool. |
That's why then, if a program uses But all the unprivileged thing, unsharing host, and completely unsharing home, feels backwards with what distrobox aims to do, and is useful for. If one doesn't want an integration with the host system, why are they using distrobox in the first place? |
There was a time when this wasn't much of a concern, but because of widespread cybersecurity threats sandboxing needs to be a target for ALL desktop environments. Moving forward, running apps and environments in a sandbox is hard requirement for me. For example, I don't want most apps (e.g. LibreOffice, Gimp, Firefox, vlc) to have general access to all my mounted network shares, or all my dotfiles (especially ~/.ssh folder where my private keys are stored). Same thing for building software, the build environment should not have access to my whole user profile or all my network mounts. If distrobox doesn't have the ability to run apps and environments in a safe way (i.e. sandboxed), then unfortunately I may not be able to use it. |
Even on the host system I want to run apps in a sandbox. Whether it is a native host app or a distrobox app I want to define the amount of integration and what is visible to the app and hidden from the app. |
and that's where flatpak exist
and that's where regular docker/podman exist
Distrobox target is to have multiple mutable environments, for compatibility or development purposes. The point of distrobox is integration, compatibility and ease of use, if you take away this, what is the advantage of running bare podman/docker? |
|
I guess we can close the PR as not planned then ^^ |
|
Closing as not planned |
Lets the users decide to unshare host home and root directories, and to create unprivileged containers without dropping security measures. Default behaviour of commands stays as-is. Partially related to issue #28.