[Improvement] Prevent docker's root to modify host stuff

[dlesaffre]

Describe the bug

1. distrobox-init creates following sudo entry in /etc/sudoers.d/sudoers:

david ALL = (root) NOPASSWD:ALL

2. distrobox-init sets up mounts for /proc, /net, and /dev, shared with the host

This combination makes it possible to alter the iptables rules without the need to provide a password. And probably a lot of other security sensitive settings.

To Reproduce
Steps to reproduce the behavior

Run your container, change the iptables rules:

$ distrobox-enter mycontainer

david@mycontainer:~$ sudo iptables -P INPUT ACCEPT
david@mycontainer:~$

There is no prompt for a password.
The iptables on the host system are affected.
On the host, my user is required to provide a password when using sudo.

Expected behavior
A clear and concise description of what you expected to happen.

I expected to be prompted for a password when using the sudo command, as configured on the host.

Desktop (please complete the following information):

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Additional context
container:

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.4 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

[89luca89]

Hello @dlesaffre
are you using docker or podman for this?

If you're using docker this is expected as the docker daemon runs as root, while podman is rootless.

I'm interested in having a solution for this, but as of now it is not possible to have the same prompt between outside and inside the container, as it is not possible to simply copy the user password from host to guest.

Also for now seems like Docker cannot do user namespace remapping without renouncing also to host network, pid and ipc so we cannot do an unprivileged one like on podman

EDIT:
thinking of it it is possible to limit the damage mounting /proc /sys and /dev and possibly /run/host read-only (which is effectively the same as rootless podman as it does not have privileged to write there)

[89luca89]

@dlesaffre I've implemented a fix for this de-privileging the docker container, can you check if it respects what you expect? (that it cannot do stuff on the host that is)

EDIT: to be clear, this fix involves distrobox-create so to test you'll need to recreate your container

[dlesaffre]

The code change in #202 still allows to change iptables rules on the host, without asking for a sudo password.

[89luca89]

Yea I tested it does not, it's probably not possible with docker to limit this stuff without losing integration with the host (network and such)
For now I'll just put a disclaimer in the docs about this, and suggest to use rootless podman if more security is needed, until rootless docker works properly

[89luca89]

In future I also plan to support rootful podman so probably this disclaimer has to be made anyway, a root inside a rootful container, is root also on the main system

Regarding adding a sudo password, the problem here is not that it's not possible (it could just be a question during create, defaulting to passwordless to not break backward compatibilty) but the problem is passing the argument to the entrypoint, either via ENV or via flag, it would be easily read when doing a docker inspect which is pratically the same level of security of haing a rootless sudo inside the container

[89luca89]

As stated above I've added a warning to the main page about this behavior on docker.
Cannot do much until we have a working rootless docker, podman remains the go-to if security is a concern

Closing this and will open a new one for rootless docker and (if we manage) rootless containerd in general