Which version of runc is actually used by podman 5.x?

matrey commented 3 months ago

Issue Description

Prisma Cloud is reporting a lot of vulnerabilities on my fresh podman 5.1.1 setup CVE-2024-21626 fixed in runc 1.1.12 CVE-2023-27561 fixed in runc 1.1.5 CVE-2023-28642 fixed in runc 1.1.5 CVE-2022-29162 fixed in runc 1.1.2 CVE-2023-25809 fixed in runc 1.1.5

Where on the other hand it seems fine with my ancient podman 3.0.1 on another VM

I'm not familiar with Go but it does seem that https://github.com/containers/podman/commit/91b8f208a2759c9b5cc5e82e885937350a73ecac made podman use runc v1.1.1-0.20240131200429-02120488a4c0 Which would lead more towards a false positive from Prisma Cloud (yes, it's v1.1.1, but with patches to fix the CVEs)

But on the other hand we have some version bumping like https://github.com/containers/podman/commit/90d6e92f2fa8c05a1ed6f08d1add054f69e8b6bc that seems to want to upgrade to runc v1.1.12, but this just seems to get "aliased" back to v1.1.1-0.20230904132852-a0466dd76f23 (sorry for the wording which is probably incorrect, I don't know Go)

podman info says:

  ociRuntime:
    name: runc
    package: cri-o-runc_100:1.1.12-1_amd64
    path: /usr/lib/cri-o-runc/sbin/runc
    version: |-
      runc version unknown
      spec: 1.0.2-dev
      go: go1.22.4
      libseccomp: 2.5.1

podman was setup on Debian 11 bullseye thanks to alvistack

echo 'deb http://download.opensuse.org/repositories/home:/alvistack/Debian_11/ /' | sudo tee /etc/apt/sources.list.d/home:alvistack.list
sudo apt install gpg --no-install-recommends 
curl -fsSL https://download.opensuse.org/repositories/home:alvistack/Debian_11/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_alvistack.gpg > /dev/null
sudo apt update
sudo apt install podman podman-netavark

Steps to reproduce the issue

-

Describe the results you received

-

Describe the results you expected

-

podman info output

Podman in a container

No

Privileged Or Rootless

None

Upstream Latest Release

Yes

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

mheon commented 3 months ago

Firstly, I will note that it doesn't really matter what runc we have vendored, because we do not use vendored runc code for creating containers. We mostly use it for internal cgroup management (e.g. creating pod cgroups). Vulnerabilities in runc thus generally don't affect podman so long as the runc binary itself is patched. Or you use crun.

However, you are correct that we should probably drop the runc alias, I don't think we need to keep that around.

matrey commented 3 months ago

OK I think I get it now.

podman depends on some code from libcontainer, which is how we get a dependency on opencontainers/runc.
- 3 files libpod/oci_conmon_linux.go pkg/api/handlers/compat/containers_stats_linux.go libpod/stats_linux.go
- using 3 things github.com/opencontainers/runc/libcontainer/configs github.com/opencontainers/runc/libcontainer/devices github.com/opencontainers/runc/libcontainer/cgroups
runc does get installed on the system under /usr/lib/cri-o-runc/sbin/runc which is not in PATH so that's why a runc --version did not work. This is what gets reported under ociRuntime / version of podman info. It's not related to the usage in point 1 above
runc (from package cri-o-runc) has been installed because package podman requires oci-runtime which is a virtual package that resolves to crun and cri-o-runc

$ sudo apt show podman
Package: podman
Version: 100:5.1.1-1
Priority: optional
Section: devel
Maintainer: Wong Hoi Sing Edison <hswong3i@pantarei-design.com>
Installed-Size: 88.2 MB
Depends: libc6 (>= 2.28), libseccomp2 (>= 2.5.0), catatonit, conmon, containernetworking-plugins, containers-common, iptables, oci-runtime, tzdata

$ sudo apt show oci-runtime
Package: oci-runtime
State: not a real package (virtual)

$ sudo apt-cache showpkg oci-runtime
Reverse Provides: 
crun 100:1.15-1 (= )
crun 100:1.14.4-1 (= )
crun 100:1.14.3-1 (= )
crun 100:1.14.2-1 (= )
cri-o-runc 100:1.1.12-1 (= )
cri-o-runc 100:1.1.11-1 (= )
cri-o-runc 100:1.1.10-1 (= )

matrey commented 3 months ago

One thing I'm still confused about. At the time of the pin, go.mod referenced github.com/opencontainers/runc v1.1.12. Why did the pin use "1.1.1" rather than "1.1.12"?

mheon commented 3 months ago

Go.mod pins to a specific commit rarely include an accurate version number - the most relevant bits are the date added and hash. If we were pinning to a version, not a commit, it would make sense.

Luap99 commented 3 months ago

We can update the replace to the lastest version on main but we cannot use any 1.1.X versions as they do not include features we want. The go vendor process is not smart enough to figure out we want this specific commit and reverts it to some 1.1.X version if you delete the replace.

In any case we are not vulnerable to the CVE's so this is not important

containers / podman