Introduction

In the ever-evolving landscape of container technology, Podman’s latest version, v4.6.0, includes a feature that promises to be a game-changer for system administrators: Podmansh. A login shell that leverages Podman’s robust container management capabilities. Podmansh is set to redefine the way users interact with systems, while ensuring maximum security and control for administrators.

Why Podmansh?

Managing access to resources is a crucial task for system administrators. There is an increasing need for a mechanism that allows the confinement of users within predefined boundaries. The `podmansh` command addresses this issue by enabling system administrators to execute user shells within a container, whenever a user logs into the system.

How It Works

Administrators configure users on their system to use the `/usr/bin/podmansh` command rather than a normal shell command like `/bin/bash`. When a user logs into a system setup in this manner, the Podmansh command will exec the user’s session in a rootless  container named `podmansh`. The Podman container `podmansh` is automatically started by systemd when the user session starts, and continues running until all user sessions exit.

Containers that users log in are defined via Quadlet files. Administrators can control the visibility of the host system in the container via volumes – specified for them in a Quadlet file. Administrators can also limit the access, security privileges, as well as resource constraints of the logged in users via the Quadlet settings.

Administrators create Quadlet files in the /etc/containers/systemd/users directory. Systemd will then initialize it for all users upon login. For instance, an administrator can create a specific Quadlet named `Podmansh` and enable users to use the login shell /usr/bin/podmansh. These user login shells will automatically execute within the Podmansh container via Podman.

For more granular control, administrators can place Quadlet files in the /etc/containers/systemd/users/${USER_ID} directory for each user. Consequently, only the specified USER_ID will execute these Quadlet services when that user logs in.

Setup

      First, create a user login session using useradd while running as root, followed by creation of a Quadlet file in /etc/containers/systemd/users/${USER_ID}.

Example 1: Fully locked down container, no access to host OS.

# useradd -s /usr/bin/podmansh lockedu # grep lockedu /etc/passwd lockedu:x:4008:4008::/home/lockedu:/usr/bin/podmansh # USER_ID=$(id -u lockedu) # mkdir -p /etc/containers/systemd/users/${USER_ID} # cat > /etc/containers/systemd/users/${USER_ID}/podmansh.container << _EOF [Unit] Description=The Podmansh container After=local-fs.target [Container] Image=registry.fedoraproject.org/fedora ContainerName=podmansh RemapUsers=keep-id RunInit=yes DropCapability=all NoNewPrivileges=true Exec=sleep infinity [Install] RequiredBy=default.target _EOF

Notice a few fields in the Quadlet file under the [Container] section.

1. Image=registry.fedoraproject.org/fedora
   This option tells Podman to download the fedora image to run the container within.  Administrators can pick specific container images to launch users in, which could be different than the host system.
2. ContainerName=podmansh
   The container name must be `podmansh` as /usr/bin/podmansh always does a `podman exec` into the `podmansh` container.
3. RemapUsers=keep-id
   This option will map the user’s USER_ID as itself within the container. Without this field, the user would login as root of the user namespace.
4. RunInit=yes
   This tells podman to launch an init process within the container which will cleanup any zombie processes inside of the container
5. DropCapability=all

This option tells Podman to drop all capabilities inside of the container and prevents the container process from ever getting any capabilities on the system, even if it figured out a way to escape the container.

6. NoNewPrivileges=true
   This option goes a step further and prevents the container from ever getting any new privileges in addition to capabilities.
7. Exec=sleep infinity

The last field to look at is the Exec command. Most of the time we recommend that the user’s session just goes to sleep in a Podmansh container. This prevents the session from using resources on the system.  Since user sessions are execed into the container, they would be running the default /bin/sh inside of the container image.

If you really want to lock the user into the container, you could even add a flag like

Network=none. This option would remove all network access from the processes within the container. Meaning the container process can not reach other nodes via the network, from its point of view there is no network on the box. You could also set up the container to be ReadOnly=true, which would prevent the user from writing anywhere but on tmpfs directories in `/run` and `/tmp`.

Quadlet containers are removed from the system when the user’s session is exited, meaning anything that the user wrote to the container image will be removed when the user sessions terminate. 

The next example will allow a user to save content in his home directory.

Example 2: Alternatively, while running as root, create a Quadlet where the user is allowed to become root within the user namespace. They can also permanently read/write content from their home directory which is a volume mounted from the actual host’s users account, rather than being inside of the container.

# useradd -s /usr/bin/podmansh confinedu # grep confinedu /etc/passwd confinedu:x:4009:4009::/home/confinedu:/usr/bin/podmansh # USER_ID=$(id -u confinedu) # mkdir -p /etc/containers/systemd/users/${USER_ID} # cat > /etc/containers/systemd/users/${USER_ID}/podmansh.container << _EOF [Unit] Description=The Podmansh container After=local-fs.target [Container] Image=registry.fedoraproject.org/fedora ContainerName=podmansh RemapUsers=keep-id RunInit=yes Volume=%h/data:%h:Z Exec=sleep infinity [Service] ExecStartPre=/usr/bin/mkdir -p %h/data [Install] RequiredBy=default.target _EOF

Notice in this example the first four fields in the [Container] structure are the same as the previous example. And the Exec command is still `sleep infinity`. But we removed the security lockdowns of DropCapabilties and NoNewPrivileges. Without these restrictions the user session can become root within his user namespace and could do certain privileged activities like installing packages (even though they currently will not persist). Realize that this is a rootless container, which means the user processes are not really root (uid=0) on the host system. 

A couple of additional lines have been added to the Quadlet.

1.  Volume=%h/data:%h:Z
   This line tells Podman to volume mount the data directory in the users homedir into the container onto his homedir. The :Z tells SELinux systems to label the data directory to match the containers label. %h tells systemd to expand this field into the user’s homedir when calling Podman. Since the `data` directory is volume mounted into the container it will survive outside of the container for use the next time the users logs into the system.
2. [Service]
   ExecStartPre=/usr/bin/mkdir -p %h/data
   This section tells systemd to precreate the data directory in the user’s home directory on the host before launching the container.

Example 3: Alternatively, while running as root, create a Quadlet where the user is allowed to become root within the user namespace. They can also permanently read/write content from their home directory which is volume mounted from the actual host’s user’s account, rather than being inside of the container.

# useradd -s /usr/bin/podmansh volumeu # grep volumeu /etc/passwd volumeu:x:4010:4010::/home/volumeu:/usr/bin/podmansh # USER_ID=$(id -u volumeu) # mkdir -p /etc/containers/systemd/users/${USER_ID} # cat > /etc/containers/systemd/users/${USER_ID}/podmansh.container << _EOF [Unit] Description=The Podmansh container After=local-fs.target [Container] Image=registry.access.redhat.com/ubi9 ContainerName=podmansh RemapUsers=keep-id RunInit=yes Device=/dev/nvidia123Volume=/secret/data:/secret:ro Exec=sleep infinity [Install] RequiredBy=default.target _EOF

Notice in this last example that two fields were added to allow read-only access to a specific volume on the host, and an nVidia device was added to the container. The image was changed to ubi9 to highlight the fact that you can have multiple Podmansh Quadlets, one for each user, and these Quadlets can use different images. 

A couple of additional lines have been added to the Quadlet.

1. Device=/dev/nvidia123

The device line will add this device to the container to be used by the user session

2.  Volume=/secret/data:/secret:ro
   This line tells Podman to volume mount the /secret/data directory as /secret inside of the container as a read only mount. The idea here would be to allow apps within the container image to use the device to process data in the /secret directory.

This last example would allow administrators to expose different parts of the system to different users depending on their security level.

Security & Confidentiality

Users are confined to their container environment with all the security mechanisms in place, including SELinux. Any system information that becomes available within the container is strictly limited to volumes mounted into the container, ensuring a high level of security and isolation.

Seamless Operation

Once a user session starts, systemd automatically creates the associated container. As all connections to the user session are removed, systemd takes down the container. This means users can log into the system multiple times, with each session connecting to the same container, providing a seamless user experience.

Moreover, administrators have the power to expose specific host data from the host system to the user through volumes. This can be done without exposing the user to other parts of the system, maintaining the integrity and security of the overall system.

Wrapping Up

In conclusion, Podman v4.6’s new feature, Podmansh, is set to revolutionize how system administrators manage user access and control, all while maintaining an impressive level of security and confidentiality. It’s a groundbreaking step in the world of container technology, providing a new way for users to interact with systems.