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

[Reinhard Tartler]

On Thu, Aug 8, 2024 at 10:42 AM Simon McVittie <smcv at debian.org> 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.
>
> Yes, that's what I had feared.
>
> [...]
>
> It's the step that is actually running tests that I'm asking about here
> (autopkgtest-**virt**-podman), not the step that builds a Debian container
> (mmdebstrap and autopkgtest-**build**-podman). I very much hope that we
> can assume that what we get from Debian's production apt repositories -
> and particularly core packages - is non-malicious, so the
> mmdebstrap | autopkgtest-build-podman step has a lot less need to be
> hardened against malicious or compromised container contents.
>

Well, even if we can rule out malice, it is still a useful safety mechanism
against
all kinds of accidents and surprises. But arguably, it may or may not be
relevant
here, I don't have a strong opinion either way.



> The step that actually runs tests can (depending on configuration)
> install packages from outside Debian, so it's that step where I'm
> particularly concerned about giving CAP_SYS_ADMIN (inside the container)
> to a potentially malicious or compromised container payload.
>
> >  - Evidently, we do have a maintainer script that invokes a process,
> >    policykit in this example, that does expect CAP_SYS_ADMIN
>
> It's systemd's implementation of the parameters used in policykit's
> systemd unit that expects CAP_SYS_ADMIN, rather than policykit itself;
> and if it matters, it's being launched on-demand when an automated test
> uses it (my original use-case was the tests for accountsservice), not
> actually from a maintainer script. I'm sure plenty of packages require
> CAP_SYS_ADMIN at postinst time, but policykit is not actually one of them.
>
> Again, this is during the step where we run a package's test suite,
> potentially involving a package that hasn't yet been approved for
> inclusion in Debian. I'm a lot less concerned about the earlier step
> where we build a base container for later testing, because that step is
> generally limited to using official Debian packages.
>

Okay, thanks for the clarification. I clearly missed that.

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.
https://www.redhat.com/sysadmin/podman-inside-container)

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.


-- 
regards,
    Reinhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20240808/d273ae1f/attachment-0001.htm>