On Thu, 08 Aug 2024 at 09:35:55 -0400, Reinhard Tartler wrote:
> Simon McVittie <s...@debian.org> writes:
> > It is possible to run systemd + polkitd inside a podman container by
> > running it as "podman run ... --cap-add=CAP_SYS_ADMIN", but I am unsure
> > whether this undermines or defeats podman's security model.
>
> Security is not absolute. You achieve it by layering security
> measures.
I know that, but there's a distinction between security measures that
are known to be load-bearing (in the sense that if you disable them, a
container escape isn't CVE-worthy or surprising any more), and security
measures that are just intended to be hardening that protects you from
a certain subset of vulnerabilities (but if they mitigate a vulnerability,
it's still considered to be a valid vulnerability).
> 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.
> I personally think this is a call that the mmdebstrap needs to make
I'm sorry, what's the relevance of mmdebstrap here? The only mention of
mmdebstrap that I made in this bug report was as part of a convenient way
to build a podman Debian container image without needing to trust
Dockerhub.
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.
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.
> tend to recommend to have
> autopkgtest-build-podman invoke podman with CAP_SYS_ADMIN for maximum
> compatibility
autopkgtest-build-podman doesn't actually need this: it doesn't install
arbitrary packages from throughout the distribution, and isn't running
the full init system. This is podman in its role as a better schroot,
and isn't a problem in the scenario I was testing.
It's autopkgtest-**virt**-podman, which runs the test environment where
packages' automated test scripts get run, that benefits from having a
full init system (in practice systemd, or sometimes sysvinit), and
potentially having CAP_SYS_ADMIN. This is podman in its role as an
alternative to (rootless) lxc/lxd/Incus.
smcv
