<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"courier new",monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 8, 2024 at 10:42 AM Simon McVittie <<a href="mailto:smcv@debian.org">smcv@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-family:"courier new",monospace"></span>> For rootless podman the situation is less clear, but from a security<br>
> assessment POV, I would consider any process running as root in the container<br>
> [with CAP_SYS_ADMIN] to have the same privileges as the UID starting<br>
> the container.<br>
<br>
Yes, that's what I had feared.<br>
<br>
<span class="gmail_default" style="font-family:"courier new",monospace">[...]</span><br>
<br>
It's the step that is actually running tests that I'm asking about here<br>
(autopkgtest-**virt**-podman), not the step that builds a Debian container<br>
(mmdebstrap and autopkgtest-**build**-podman). I very much hope that we<br>
can assume that what we get from Debian's production apt repositories -<br>
and particularly core packages - is non-malicious, so the<br>
mmdebstrap | autopkgtest-build-podman step has a lot less need to be<br>
hardened against malicious or compromised container contents.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:"courier new",monospace">Well, even if we can rule out malice, it is still a useful safety mechanism against</div><div class="gmail_default" style="font-family:"courier new",monospace">all kinds of accidents and surprises. But arguably, it may or may not be relevant</div><div class="gmail_default" style="font-family:"courier new",monospace">here, I don't have a strong opinion either way.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The step that actually runs tests can (depending on configuration)<br>
install packages from outside Debian, so it's that step where I'm<br>
particularly concerned about giving CAP_SYS_ADMIN (inside the container)<br>
to a potentially malicious or compromised container payload.<br>
<br>
>  - Evidently, we do have a maintainer script that invokes a process,<br>
>    policykit in this example, that does expect CAP_SYS_ADMIN<br>
<br>
It's systemd's implementation of the parameters used in policykit's<br>
systemd unit that expects CAP_SYS_ADMIN, rather than policykit itself;<br>
and if it matters, it's being launched on-demand when an automated test<br>
uses it (my original use-case was the tests for accountsservice), not<br>
actually from a maintainer script. I'm sure plenty of packages require<br>
CAP_SYS_ADMIN at postinst time, but policykit is not actually one of them.<br>
<br>
Again, this is during the step where we run a package's test suite,<br>
potentially involving a package that hasn't yet been approved for<br>
inclusion in Debian. I'm a lot less concerned about the earlier step<br>
where we build a base container for later testing, because that step is<br>
generally limited to using official Debian packages.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:"courier new",monospace">Okay, thanks for the clarification. I clearly missed that.<br><br>In short, it seems to me if you are running a workload that requires CAP_SYS_ADMIN,</div><div class="gmail_default" style="font-family:"courier new",monospace">then it is appropriate to pass that argument to podman. It is clearly much better than</div><div class="gmail_default" style="font-family:"courier new",monospace">using --privileged (cf. <a href="https://www.redhat.com/sysadmin/podman-inside-container">https://www.redhat.com/sysadmin/podman-inside-container</a>)</div><div class="gmail_default" style="font-family:"courier new",monospace"><br></div><div class="gmail_default" style="font-family:"courier new",monospace">Since you assigned this bug to podman, may I ask what the ask is?</div><div class="gmail_default" style="font-family:"courier new",monospace">It's not clear how to improve the podman packaging in this context.</div><div class="gmail_default" style="font-family:"courier new",monospace"><br></div></div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">regards,<br>    Reinhard</div></div>