[pkg-go] Bug#1078205: systemd: can't start polkitd in a podman container without CAP_SYS_ADMIN

[Simon McVittie]

On Thu, 08 Aug 2024 at 09:35:55 -0400, Reinhard Tartler wrote:
> For rootless podman the situation is less clear, but from a security
> assessment POV, I would consider any process running as root in the container
> [with CAP_SYS_ADMIN] to have the same privileges as the UID starting
> the container.

On Thu, 08 Aug 2024 at 11:12:07 -0400, Reinhard Tartler wrote:
> In short, it seems to me if you are running a workload that requires
> CAP_SYS_ADMIN,
> then it is appropriate to pass that argument to podman. It is clearly much
> better than
> using --privileged (cf. [2]https://www.redhat.com/sysadmin/
> podman-inside-container)

Do you think this would be reasonably accurate wording to put in
autopkgtest-virt-podman(1)?

    Note that full functionality of systemd(1) as an init system requires
    the container to have CAP_SYS_ADMIN, which might allow code that
    runs as root in the container to compromise processes outside the
    container that are running under the same uid as
    autopkgtest-virt-podman. If this is consistent with your security
    model, it can be enabled by passing the --cap-add=CAP_SYS_ADMIN option
    to podman_run(1):

        autopkgtest ... -- podman --init $IMAGE -- --cap-add=CAP_SYS_ADMIN

Or is "might allow" too strong, or too weak?

(It might also be appropriate to add a shorthand form for that, to avoid
needing to use the "pass arbitrary options to podman-run" mechanism,
but that would need some more design to choose a suitable name for
that option. --trust-root-in-testbed, perhaps, if my understanding of
the impact of CAP_SYS_ADMIN is correct.)

> Since you assigned this bug to podman, may I ask what the ask is?
> It's not clear how to improve the podman packaging in this context.

I initially reported this as a systemd bug, thinking that systemd's
expected behaviour would be to turn off features that require
CAP_SYS_ADMIN when it isn't available (as it already does for some but
not all such features, as far as I can see), but Luca replied "this
is an issue in podman". I don't know specifically what basis he had
for that statement.

Perhaps he was expecting that `podman run --systemd=true` (which is the
default) would detect that we're running /sbin/init in the container,
and automatically grant access to CAP_SYS_ADMIN? But I think that would
be inappropriate as an automatic thing if giving access to CAP_SYS_ADMIN
requires trusting the container payload.

If nothing is going to be done about this in systemd, and nothing can be
done about it in podman, then it'll probably have to end up as a
documentation improvement in autopkgtest-virt-podman(1).

    smcv