On Thu, 08 Aug 2024 at 09:35:55 -0400, Reinhard Tartler 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.
On Thu, 08 Aug 2024 at 11:12:07 -0400, Reinhard Tartler wrote: > 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. [2]https://www.redhat.com/sysadmin/ > podman-inside-container) Do you think this would be reasonably accurate wording to put in autopkgtest-virt-podman(1)? Note that full functionality of systemd(1) as an init system requires the container to have CAP_SYS_ADMIN, which might allow code that runs as root in the container to compromise processes outside the container that are running under the same uid as autopkgtest-virt-podman. If this is consistent with your security model, it can be enabled by passing the --cap-add=CAP_SYS_ADMIN option to podman_run(1): autopkgtest ... -- podman --init $IMAGE -- --cap-add=CAP_SYS_ADMIN Or is "might allow" too strong, or too weak? (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.) > 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. I initially reported this as a systemd bug, thinking that systemd's expected behaviour would be to turn off features that require CAP_SYS_ADMIN when it isn't available (as it already does for some but not all such features, as far as I can see), but Luca replied "this is an issue in podman". I don't know specifically what basis he had for that statement. Perhaps he was expecting that `podman run --systemd=true` (which is the default) would detect that we're running /sbin/init in the container, and automatically grant access to CAP_SYS_ADMIN? But I think that would be inappropriate as an automatic thing if giving access to CAP_SYS_ADMIN requires trusting the container payload. 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). smcv
