ELI5 Request: User Privileges and Container/Host Safety

[kavishgr]

Hey there!

When it comes to keeping things secure with Podman, I get that if you're running a container, and if a process or something inside the container does gain access on the host, it can only be as powerful as the user who started the container. So, if you're just a regular user (not in the sudo/wheel group), it's pretty safe. Such as the following user toto:

core@coreos:~$ groups toto
toto : toto

But what if you run a container as a user that has sudo privileges. Such as the following user core:

core@coreos:~$ groups core
core : core adm wheel sudo systemd-journal docker

Even though I won't be starting the container with sudo(which basically translates to "run it as root"), but starting the container with a user such as core like below(not with sudo):

podman run test-image

And if a container breakout occurs, the process or user inside the container will inherit the privileges of the user who initiated the container, in this case, user: core. Is that considered safe or should we always use an unprivileged user such as toto?

Because sometimes we have no choice but to use the --privileged flag or allow certain capabilities for containers that requires it. I guess we should only allow these when we know what we're doing and we do trust what's running inside the container.

I know we've got SElinux too, but is that enough to handle these situations or should we always go with an unprivileged user?

[rhatdan]

If a rootless container breakout happens, the process will be running as the user and will have access to any data the user owns or has access to via his group. Most likely the process will no longer have access to additional groups the user had when running the container. This means if the user had wheel group, then the container process would no longer have the wheel group. Of course it can create a .bashrc file and cause the next login to do evil access via the wheel group. BTW SELinux would block all of this access, and is really the primary tool for protecting the host file system.