Cache mounts (--mount type=cache,id=...) in Buildah and podman build do not properly validate that user-specified paths for the cache are within our cache directory, allowing a RUN instruction in a Containerfile to mount an arbitrary directory from the host (read/write) into the container as long as those files can be accessed by the user running Buildah. This codepath automatically performs an SELinux relabel on the directory in question to ensure the build has access to it, so SELinux does not stop this.

#1podman build ..." follows symlinks when reading .containerignore and .dockerignore We've received this potential security issue with Podman, and although not said, it's really in Buildah. I've asked one of our engineers (Aditya) to fix it upstream, but I think it might be wise to backport to Podman 4.1.1 as noted in the issue.

Please adivise next steps and setup any CVE's or BZ's as appropriate. more information in SNow -> https://redhat.service-now.com/surl.do?n=INC2395282

An incorrect handling of the supplementary groups in the Podman container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.

Reference:

https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/

podman incorrectly allows containers, when created, to populate volumes that already have existing data inside. A malicious container image may use this flaw to overwrite existing files in a volume, even if it is mounted in read-only mode. The attack is possible only the first time a volume is used.