On Sat, Aug 10, 2024 at 12:58 PM Simon McVittie <s...@debian.org> wrote:
> Control: reassign -1 autopkgtest > Control: retitle -1 autopkgtest-virt-podman: document how to give systemd > CAP_SYS_ADMIN > Control: severity -1 wishlist > Control: forwarded -1 > https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/396 > Control: tags -1 + help > > On Sat, 10 Aug 2024 at 11:24:51 -0400, Reinhard Tartler wrote: > > I personally find that wording a bit too strong. How about something like > > this: > > > ... > > > However, this also introduces an additional > > > attack surface in the > > > kernel if malicious code tried to escape the container sandbox. > > Are you thinking here of malicious code in a systemd service inside the > container trying to escape from systemd's sandboxing to be privileged > within the podman container, or are you thinking about malicious code > inside the podman container (possibly as unconfined root) escaping > from the podman container to harm the host system? > I'm mostly thinking of maintainer scripts (e.g., postinst scripts) from dependencies that are being pulled in, for instance via the option --add-apt-source. I don't find it is unreasonable to expect podman to provide a sandbox that protects against (potentially) harmful packages in maintainer script code in such a situation. > In the autopkgtest use-case, I think in general we trust (or distrust!) > everything inside the podman container equally: they're all coming from > the same apt source(s), and can execute arbitrary code as container root > via their maintainer scripts. The only reason that systemd's sandboxing > of system services matters to us is that one of the things we ideally > want to test is that the maintainer of the package under test didn't > configure overly-strict systemd sandboxing that breaks their service's > intended functionality. > If you trust all maintainer scripts and other code as much as you trust systemd in the container, then running the whole container with CAP_SYS_ADMIN should be fine. > > > (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.) > > > > I'd love to see such a shortcut, but it is not obvious to my how to name > it. > > Your suggestion seems too strong to me, because there are typically still > > other > > security features in play, such as seccomp, selinux or apparmor. > > Yes, hence my question about how dangerous it is to allow CAP_SYS_ADMIN. > > One way to phrase it is: are the other security mechanisms that podman > uses (seccomp and LSMs) meant to be sufficiently strong that, if container > root can escape to the host (even with CAP_SYS_ADMIN), that would justify > a CVE in either podman or the kernel? If yes, then denying CAP_SYS_ADMIN > is just hardening, rather than being security-critical in its own right. > Ok, if you phrase the question that way, then I'd say "just hardening". I don't see an obvious way how to escape the container with CAP_SYS_ADMIN, AFAIUI you'd need to exploit at least some other podman or kernel bug, which I would fully expect to be documented with a CVE and addressed with a stable release and/or security update for stable releases. > Re-reading through https://github.com/systemd/systemd/issues/29860 > clarifies > > that systemd has a number of additional security hardening features, > such as > > DynamicUsers, but also things like PrivateDevices=`, `ProtectHome=`, > > `ProtectSystem=`, `MountFlags=`, `PrivateTmp=`, `ReadWriteDirectories=`, > > `ReadOnlyDirectories=`, `InaccessibleDirectories=`, and `MountFlags=`. > > Yes. Some of these are orthogonal to CAP_SYS_ADMIN; some of them need > CAP_SYS_ADMIN to be effective, but are automatically disabled (with > a warning) in its absence; and some need CAP_SYS_ADMIN, and service > startup fails in its absence. It's the inconsistency between those > last two categories that initially led me to think that this could be > a systemd bug. > > > > 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). > > > > I tend to agree. > > Reassigning to autopkgtest(-virt-podman) for that. > I personally would be comfortable running containers > > that have systemd inside with CAP_SYS_ADMIN because that is closer to > > how systemd runs on a real system. Also, podman provides other additional > > security features, such as seccomp and apparmor/selinux. > > Thanks, that's a useful data point. > Awesome, thanks for reaching out! -- regards, Reinhard
