Podman versions prior to 1.7.0 ignore file permissions for non-root users running in a privileged container. This flaw allows a low privileged user to access (in read/write mode) any other file in the container, even if owned by the container root user. This means any user inside the privileged container has effectively the same privileges as the root user in the container.
Attack Complexity set to High (AC:H) in CVSSv3 because to use this flaw an attacker already needs access to a privileged container as a low-privileged user. If the container is used to run a service (e.g. a database) the service has first to be compromised. Once root, an attacker potentially has the same permissions of the user that launched the container, due to the fact that the container has to be privileged.
This flaw seems very similar to CVE-2018-10856, however this requires a privileged container.
This issue was fixed as part of https://github.com/containers/podman/commit/dcf3c742b1ac4d641d66810113f3d17441a412f4, however this commit contains many changes.
The issue could be reproduced in podman versions down to, at least, v1.0.2-dev.
I suspect we will need different patches for Podman 1.6 and 1.0, given the substantial differences in the codebase between these two releases. I will try and get both patches written after lunch.
Created attachment 1749548 [details] Proposed patch for Podman v1.6 (RHEL 2.0 stream) Initial patch for Podman 1.6 attached. I have not yet verified that it applies cleanly against Podman 1.0; I suspect additional changes will be required.
Jindrich - can you do a scratch-build of Podman 1.6.4 (2.0 stream from 8.3 should work well) with the patch I provided, for testing?
Efforts to patch Podman 1.0 are not going well - the code there is sufficiently old that it's using a completely different method for `podman exec` that does not support the fine-tuning of capabilities we can do on newer versions. I will consult with my team, but it may be that the best way forward is to completely disable capability handling when the exec session is not run as root.
I agree, noone should be using this, so removing any capability handling seems to be the safest course of action. Most users are using podman 1.6.* or newer.
Problem: I cannot, without an extensive rewrite, remove capabilities. With my current patch, a Podman 1.0 exec session (non-root user in a privileged container) looks like this: CapInh: 0000003fffffffff CapPrm: 0000003fffffffff CapEff: 0000003fffffffff CapBnd: 0000003fffffffff CapAmb: 0000003fffffffff The correct behavior, which exists on master and 1.6 after my above patch: CapInh: 0000003fffffffff CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff CapAmb: 0000000000000000 Given this, it looks like I'm going to need to make some extensive changes to 1.0's exec code, to send the Process block to the OCI runtime so we can tweak capabilities. I am somewhat concerned I'm going to introduce other regressions in the process, but I see no other way forward. This may take most of today and tomorrow to get right.
Created attachment 1750688 [details] Proposed patch for Podman v1.0 (RHEL 1.0 stream) Attached is a proposed patch for Podman 1.0. I have verified that it resolves the CVE, but it involves an uncomfortably large change to exec functionality. I need to do further testing to verify that we did not regress in other ways.
After further testing, I'm satisfied with the 1.0 patch - it seems to match pre-patch behavior for all significant cases.
Running a `sleep` process in a container with different configurations. Vulnerable version (without --privileged, user 0 in the container): CapInh: 00000000a80425fb CapPrm: 00000000a80425fb CapEff: 00000000a80425fb CapBnd: 00000000a80425fb CapAmb: 00000000a80425fb Vulnerable version (without --privileged, user X in the container): CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 00000000a80425fb CapAmb: 0000000000000000 Vulnerable version (with --privileged, user 0 in the container): CapInh: 0000003fffffffff CapPrm: 0000003fffffffff CapEff: 0000003fffffffff CapBnd: 0000003fffffffff CapAmb: 0000003fffffffff Vulnerable version (with --privileged, user X in the container): CapInh: 0000003fffffffff CapPrm: 0000003fffffffff CapEff: 0000003fffffffff CapBnd: 0000003fffffffff CapAmb: 0000003fffffffff When podman is vulnerable to this flaw, running a process with --privileged, even if from a non-root user, keeps all the Capabilities (same as user 0 inside the container), including CAP_DAC_OVERRIDE. By keeping that capability, the processes inside the container running as a non-root user are still able to access files owned by other users, because they actually bypass the discretionary access control.
Statement: OpenShift Container Platform 3.11 (OCP) has previously packaged podman, but instead now relies on the version from rhel-extras. The older version previously packaged is marked as wontfix. This issue did not affect the versions of podman provided in the Container Tools module, stream rhel8, as shipped in Red Hat Enterprise Linux 8 as the issue was already fixed in those versions.
Upstream fixes: https://github.com/containers/podman/commit/2c7b579fe7328dc6db48bdaf60d0ddd9136b1e24 https://github.com/containers/podman/commit/c8bd4746151e6ae37d49c4688f2f64e03db429fc
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 / container-tools:rhel8 Via RHSA-2020:3053 https://access.redhat.com/errata/RHSA-2020:3053
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-20188
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extras Via RHSA-2021:0681 https://access.redhat.com/errata/RHSA-2021:0681
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:0705 https://access.redhat.com/errata/RHSA-2021:0705
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:0706 https://access.redhat.com/errata/RHSA-2021:0706
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2021:0710 https://access.redhat.com/errata/RHSA-2021:0710