run0 Allows execution on

[xavloose]

Describe the bug Executing run0 in a toolbox container will attempt to execute elevated task on host os.

I reported to systemd and a developer there informed me that the issue is toolbox since toolbox attaches the system dbus into the container. More information here:

https://github.com/systemd/systemd/issues/33455

I'm not satisfied with this answer from the systemd team but I'm just a user. I question the security implications of run0's strategy for securely elevating privileges but maybe this decision will spur competition.

Steps how to reproduce the behaviour Base Arch Linux install + toolbox and rootless podman containers

toolbox create toolbox enter

Here are common tools that aren't available in a base arch install

run0 pacman -S clang htop neovim

From inside container clang, htop and neovim can't be found as commands.

exit

On the host side htop, neovim and clang exist

I am an administrator that can execute run0 on the host and I believe this is a requirement. I do see this as a security vector.

Expected behaviour run0 executes with elevated privileges in the container

Actual behaviour run0 executes the command with elevated privileges on the host

Output of toolbox --version (v0.0.90+) e.g., toolbox version 0.0.90

Toolbx package info (rpm -q toolbox) toolbox 0.0.99.5-1

Output of podman version

Client:       Podman Engine
Version:      5.1.1
API Version:  5.1.1
Go Version:   go1.22.3
Git Commit:   bda6eb03dcbcf12a5b7ae004c1240e38dd056d24-dirty
Built:        Tue Jun  4 17:12:10 2024
OS/Arch:      linux/amd64

Podman package info (rpm -q podman) podman 5.1.1-1

Info about your OS Arch Linux - Fresh install as of yesterday. systemd v256

Additional context https://github.com/systemd/systemd/issues/33455

[0rzech]

If you think this is a security vulnerability, and IMHO it's fair to assume that in this case, then it's better to report it this way.

Also, it looks like this issue's title is incomplete for some reason. Perhaps it got cut somehow?

[xavloose]

I can't demonstrate an actual vulnerability with it. I was an administrator with proper rights to escalate privileges on the host operating system and that's what I did.

The systemd-run subproject has decided to implement a privilege elevation strategy on the system dbus. It should be assumed that this is going to become the privilige elevation strategy going forward.

Toolbox binds the system dbus to the container for a variety of reasons and I understand this.

I can utilize sudo in the container to achieve privilege escalation there. I'm just not a fan of that strategy. I think it is confusing to have a priviliege elevation strategy work one way in one context but not be compatible in a seemingly similar context.

I'm just gonna have to spend time doing some research on systemd, dbus, and containers in general to figure out how I want to utilize this projects in a secure manner.

[xavloose]

The cost of convenience, user needs to spend more time understanding their system.

[0rzech]

Does sudo run from inside toolbox container behave the same?

[xavloose]

No it doesn't sudo utilizes setuid where as run0 operates by communicating with systemd to invoke systemd-run through the system dbus. Since toolbox exposes the system dbus to the container the container can communicate with the host dbus which allows this quirk with run0.

[0rzech]

Thanks! Generally, I think that toolbox should not be able to elevate privileges outside its containers, but I'm not the project maintainer and I don't know all the implications of forbidding this quirk.