Rootless Podman with Ephemeral User

[woodsb02]

I love the idea of rootless podman, running as quadlets, as I want to protect against container escape gaining root.

That said, I also want to protect against container escape having access to my user account/files. I also don’t want to rely on a specific user in my organisation (e.g. user “alice”) to run the containers (what if Alice quits the company?). This leads you to create a dedicated user for running containers (e.g. a “containers” or “oci” user).

Then again, I also want to protect against container escape having access to my other containers. This leads you to create a dedicate user for every container/pod (e.g. separate “wordpress” and “postgres” users).

This is similar to the issues faced when running traditional system services, and systemd solved these with DynamicUser.
http://0pointer.net/blog/dynamic-users-with-systemd.html

This post suggests the systemd DynamicUser feature is too restrictive for running containers.
#12424

I think having a similar feature for podman would be great - enabling ephemeral users for rootless containers, that are configured by users with administrative/sudo privileges.

Is anyone working on this, or has it been considered in the past?

[DavyLandman]

I think this is what userns=auto is for.

It gives your process a random uid/gid that outside the namespace has no rights, as it doesn't exist. And the next time it's run, it might get a different uid/gid.

[woodsb02]

Correct me if I'm wrong, but the --userns option is about the mapping of UIDs/GIDs inside the container to those outside the container (on the host).

What I am referring to, is which user the podman container runtime is running as on the host (if you run the top command on the host) - I'd like this to be an ephemeral user.

[DavyLandman]

You can indeed map the inside uids to outside legal uid, like for example with keepid. But if you put it to auto, you get an inside uid mapped to an outside non-existing (and non overlapping with other containers) UID. So if you were to escape the container, you would have no rights. As long as you also don't escape the namespace I guess.

[woodsb02]

Yes, that makes sense, however the podman command is still having to run on the host as a specific host user. Historically that used to be root, but for increased security rootless podman became popular.

What I am proposing is a feature similar to systemd DynamicUser, where a host user is dynamically allocated the instant the podman container/pod is started, and released again when it terminates.

This article is a really good read if you're not familiar with DynamicUser:

http://0pointer.net/blog/dynamic-users-with-systemd.html

[baude]

I dont see my way through this. To create an ephemeral user, do you need root level privileges? That kind of defeats the purpose. The next obvious step might be to run libkrun or kata containers where you would be sandboxing?

[woodsb02]

I imagine you would need root to setup the quadlet (systemd service), and systemd obviously has root privileges itself. So this is for users that themselves have admin privileges, that want to run containers with minimal host privileges (not tied to a specific user).

When the quadlet services is started, systemd would first dynamically allocate a user on the host to execute the container runtime. When the quadlet service stops, systemd would release the host user again after the container terminates. The user would be automatically allocated from the UID range 61184–65519, by looking for a so far unused UID.

This is the same as how systemd services with DynamicUser=yes work today - this is a good read:
http://0pointer.net/blog/dynamic-users-with-systemd.html

[Luap99]

I would say external user management is not in scope for podman. The reason DynamicUser=yes does not work is because they lock that user down, it has no systemd user session, it has not subuid/subgids assigned and so on.
It is useful as it sandboxes a few things but that sandbox itself will not really allow podman to work properly.

For podman specially we need to store images with the subuid/subgids on disk so you cannot really chnage thoose later as the files are on disk, so dynamic uid/gid assignment would break any persistent storage.

If your goal is to just have some tooling to create a user per container you like to run as service then I do not think that is something we would want in podman directly and rather external tooling/scripts.

[woodsb02]

A couple of counter arguments - for the purposes of the conversation / idea generation.

External user management is already in scope for systemd (through DynamicUser), and quadlets are simply systemd services. I am thinking of a new systemd feature called EphemeralUser=yes that doesn't lock down the environment as much as DynamicUser, runs a systemd user session, configures subuids/subgids - for the purposes of podman.

The issue of persistent storage file ownership is already solved with DynamicUser (since services also need this). How it works is well described here, in the section called "Persistent Data":
https://0pointer.net/blog/dynamic-users-with-systemd.html

I don't want to create a user per container - I don't want to have to manage this - I just want rootless containers as an administrative user, that don't rely on a user configured on the host.

This is a discussion - because I'm hoping it sparks an idea for someone, that could gradually work towards adding the necessary features. I imagine this would require code to be added in both systemd and podman.