On Thu, Aug 8, 2024 at 10:42 AM Simon McVittie <s...@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
