- 综合排序
- 最热优先
- 最新优先
- 来自专栏容器计算
【runc】编译和安装runc
[root@VM-16-15-centos runc]# uname -a Linux VM-16-15-centos 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec =v1.0.0-417-g45c31f9 -X main.version=1.0.0+dev " -o runc 按照官网提示进行安装。 [root@VM-16-15-centos runc]# make install install -D -m0755 runc /usr/local/sbin/runc 然后想执行一下单元测试，但是报错了 [root@VM-16-15-centos runc]# make test docker build -t runc_dev:master . [root@VM-16-15-centos runc]# make test docker build -t runc_dev:master .
1.5K30编辑于 2021-12-08 - 来自专栏小孟开发笔记
从 docker 到 runC
该程序的安装路径为： /usr/bin/docker-containerd-shim RunC 详情请参考《RunC 简介》。 docker-containerd 和 docker-runc 之间的桥梁，docker-runc 能干的就交给 docker-runc 来做，docker-runc 做不了的就放到这里来做。 当这一切都完成后 docker-runc 进程退出，然后容器进程 bash 由 docker-runc 的父进程 docker-containerd-shim 接管。 事实上 docker-containerd-shim 的存在是非常有必要的，其目的有如下几点： 它允许容器运行时(即 runC)在启动容器之后退出，简单说就是不必为每个容器一直运行一个容器运行时(runC 总结 笔者先在前文《RunC 简介》和《Containerd 简介》中分别介绍了 runC 和 containerd 等 docker 的核心组件。
91060编辑于 2023-02-23 - 来自专栏Kubernetes
runC源码分析——namespace
runc/libcontainer/configs/config.go中定义了container对应的Namespaces。 of Group ID mappings for User Namespaces GidMappings []IDMap `json:"gid_mappings"` ... } runC 中namespace的源码主要在： runc/libcontainer/configs/namespaces_unix.go runC支持的namespce type包括($nsName) "net 在runc/libcontainer/configs/namespaces_syscall.go中，定义了linux clone时这些namespace对应的clone flags。 补充：runC中container的Spec是从bundle/config.json中解析得到的，见runC的create.go中的setupSpec(context)的调用。
1.9K80发布于 2018-04-13 - 来自专栏Kubernetes
runC源码分析——cgroup
runC项目中，与cgroups相关的代码，都在目录 runc/libcontainer/cgroups/下，下面是其源码目录结构分析： 我们关注的主要内容在apply_raw.go和各个cgroups stats.CpuStats.ThrottlingData.ThrottledTime = v } } return nil } 查看某个runC 启动的容器state.json文件，能看到该容器对应的cgroup和namespace 路径信息： $ cat /var/run/runc/$containerName/state.json | jq
1.7K71发布于 2018-04-13 - 来自专栏Kubernetes
runC源码分析——CreateRun Container
本文是对runC源码的核心部分——Create Command & Run Command 进行源码分析。 对应的code workflow如下所示： you should make sence these points： runC create command 和 run command的流程入口统一从/ runc/utils_linux.go#334 main.startContainer方法，通过create flag进行区分。
1.4K80发布于 2018-04-13 - 来自专栏运维开发王义杰
直接使用runc 部署Nginx
使用 runc`部署 Nginx 需要几个步骤。首先，确保你已经安装了 runc。接下来，请按照以下步骤操作： 1. 创建容器根文件系统（rootfs）： 下载并解压 Nginx 容器镜像。 你可以使用 runc spec 命令生成一个默认的配置文件模板： cd /opt/nginx/ runc spec 打开生成的 config.json 文件，并进行以下更改： 设置 root.path 启动容器： 使用 `runc` 命令启动 Nginx 容器： cd /opt/nginx sudo runc run nginx-container 这将在前台启动一个名为 `nginx-container 停止容器： runc kill nginx-container 5.删除容器： runc delete nginx-container 总结 runc 是一个轻量级的容器运行时，允许您轻松部署和管理单个容器 本文介绍了如何使用 runc 创建、运行、停止和删除 Nginx 容器，以及如何查看容器日志、配置容器网络和管理容器数据。尽管我们主要关注了 Nginx 容器，但这些方法同样适用于其他类型的容器。
57420编辑于 2023-08-16 - 来自专栏MoeLove
runc 1.0-rc7 发布之际
在 18 年 11 月底时，我写了一篇文章 《runc 1.0-rc6 发布之际》 。如果你还不了解 runc 是什么，以及如何使用它，请参考我那篇文章。本文中，不再对其概念和用法等进行说明。 不过本文主要看的是 runc 如何修复该漏洞的，以及后续产生的影响。 重新执行 runc ; (这是为了确保之后即使被攻击/替换也操作的还是内存中的这个只读的 runc) 经过以上的操作，就基本修复了 CVE-2019-5736 。 将 runc 可执行程序放到只读文件系统上，可避免被覆盖；2. 启动容器时，启用 SELinux; 3. 在容器内使用低权限用户或者采用映射的方式，但保证用户对主机上的 runc 程序无写权限。 5. https://github.com/rancher/runc-cve
82330发布于 2019-04-25 - 来自专栏运维开发故事
Docker、Containerd、RunC分别是什么
什么是RunC 上一篇文章《真正运行容器的工具：深入了解 runc 和 OCI 规范》已经讲清楚了Runc与OCI。这里再讲解一下概念。 Docker将RunC捐赠给 OCI 作为OCI 容器运行时标准的参考实现。Docker 默认提供了 docker-runc 实现。 $ runc list # stop the container $ runc kill mycontainerid # cleanup $ runc delete mycontainerid 一方面，它称自己为容器运行时，但是与运行时__RunC_不同_。不仅_containerd_和_runc_的职责不同，组织形式也不同。 显然_runc_是只是一个命令行工具，_containerd_是一个长期居住守护进程。_runc_的实例不能超过底层容器进程。
5.6K54发布于 2021-11-02 - 来自专栏Kubernetes
runC源码分析——主体调用链
本文将简单的对runC的源码调用主体逻辑进行梳理，为跟系统的阅读runC源码。 ##runC总体调用逻辑 下图中，runC源码逻辑跳转流程总体上分为三步： main入口 ——> runC处理 ——> libcontainer处理。 runC其实就是在libcontainer的基础上进行了封装成各个Command。 ? 具体runC的各个Command的调用链见如下： ##runC处理 ###checkpoint checkpointCommand(main.go) —> checkpointCommand(checkpoint.go start.go) stateCommand(main.go)—>stateCommand(state.go) updateCommand(main.go)—>updateCommand(update.go) ##runC
1.9K91发布于 2018-04-13 - 来自专栏MoeLove
runc 1.0-rc6 发布之际
Swarm: inactive Runtimes: nvidia runc Default Runtime: runc Init Binary: docker-init containerd version 什么是 runc 简单来说，它是 OCI 标准的一种实现。 runc 则是在 OCI 成立后，Docker 将其容器运行时 libcontainer 贡献出来后，并加以改造而成的。 runc 如何使用 runc 的使用本不是本篇的重点，稍微带过。 首先：runc 1.0 我们想正式 relase 么？ 答案是 想。其实早在 2017 年 8 月份的时候 runc 1.0-rc4 就已经支持 OCI v1.0.0 了。
59920发布于 2018-12-18 - 来自专栏信安百科
CVE-2024-21626｜runc容器逃逸漏洞
0x00 前言 runc是一个遵循oci标准的用来运行容器的命令行工具。runc的使用非常灵活，可以与各种容器工具和平台集成，如Docker、Kubernetes等。 0x01 漏洞描述 由于内部文件描述符泄漏，本地威胁者可以通过多种方式实现容器逃逸： 通过使新生成的容器进程（来自runc exec）在主机文件系统命名空间中拥有一个工作目录，或诱使特权用户运行恶意镜像并允许容器进程通过 runc run 访问主机文件系统，从而获得对主机文件系统的访问权限。 0x02 CVE编号 CVE-2024-21626 0x03 影响版本 v1.0.0-rc93 <= runc <= 1.1.11 0x04 漏洞详情 0x05 参考链接 https://www.docker.com /blog/docker-security-advisory-multiple-vulnerabilities-in-runc-buildkit-and-moby/ https://blog.csdn.net
1.2K10编辑于 2024-02-22 - 来自专栏Kubernetes GO
CVE-2024-21626：runc容器逃逸漏洞
： runc将包括宿主机 /sys/fs/cgroup的几个文件描述符泄漏到runc init中，攻击者可以利用这一漏洞欺骗具有特权的用户执行恶意容器镜像，导致pid1进程在宿主机挂载命名空间中拥有一个工作目录 runc exec中同样存在文件描述符泄漏和工作目录验证不足的情况。 如果容器内的恶意进程知道某个管理进程将使用 --cwd 参数和给定路径调用 runc exec，便可以通过符号链接将该路径替换为 /proc/self/fd/7/。 Snyk 在 Docker 引擎以及其他容器化技术（例如 Kubernetes）使用的runc<=1.1.11的所有版本中发现了一个漏洞。 上述漏洞可以通过社区提供的runc补丁来避免。
2.7K10编辑于 2024-02-06 - 来自专栏用户10826570的专栏
CVE-2019-5736 docker-runc escape 漏洞复现
我们可以得到runc 进程的pid号，并且我可以访问这个pid号下所有关于runc 的信息。 同样包括runc的执行文件 ->/proc/pid[runc]/exe,这意味着我们是不是可以去尝试修改这个可执行文件。答案是可行的。 但是需要一定的条件，因为runc正在运行，如果你试着open 并且写东西进去，你会得到invalid arguments。所以我们如果想要覆写exe这个可执行文件就必须等到runc运行结束。 但是当runc结束运行时/proc/pid/exe也会被替换成新的二进制可执行文件。所以我们需要先去获取一个runc得fd文件描述符，并且保留下来。 )打开runc，并且写入payload重置runc。
71620编辑于 2023-11-05 - 来自专栏云原生实验室
Runc 容器初始化和容器逃逸
构建并使用 runc 运行一个容器 构建 runc 的源码可以下载并通过 make 命令构建: git clone https://github.com/opencontainers/runc.git cd runc make runc 是一个 Go 程序，使用 CGO 调用了一些外部库。 create <container-id> runc list # 列出创建状态的容器 runc start <container-id> runc list runc delete <container-id runc 容器初始化流程 runc 目前初始化大致流程如下图所示，其中一些步骤经过了简化： ? 之前编译 runc 的步骤中，我们也已经知道了，runc 使用了 CGO 来调用 libc/libseccomp 的代码，通过ldd命令可以看到 runc 的外部依赖库: ?
1.2K20发布于 2021-02-25 - 来自专栏安全漏洞环境学习
CVE-2019-5736 runc容器逃逸漏洞复现
0X1 漏洞详情 Docker、containerd或者其他基于runc的容器运行时存在安全漏洞，攻击者可以通过特定的容器镜像或者exec操作可以获取到宿主机的runc执行时的文件句柄并修改掉runc的二进制文件 0X2影响范围：Docker版本 < 18.09.2 或者使用 runc版本 <= 1.0-rc6的环境，请自行根据厂商建议进行修复。 然后运行命令：docker run -d cve /bin/bash -c "tail -f /dev/null" 备份docker-runc文件，在kali下该文件目录在/usr/sbin/目录下： 0X4 漏洞修复 升级docker或者runC
4.4K30发布于 2019-09-24 - 来自专栏红蓝对抗
runc 漏洞可绕过容器隔离——可能已被主动利用
runc（Docker 和 Kubernetes 的容器运行时）中存在三个严重漏洞，攻击者可以利用这些漏洞打破容器隔离，并获得主机系统的 root 权限。 攻击者 /dev/null 在容器创建期间将其替换为符号链接，诱骗 runc 挂载任意主机路径。 CVE-2025-52881 利用共享挂载点的竞争条件，将 runc 写入重定向到 /proc 文件。 runc 在容器化基础设施中的广泛使用使得这些漏洞尤其危险。容器运维人员应审核已部署的环境，检查是否存在可疑的挂载配置，并监控容器逃逸尝试。 DevOps 团队应优先更新所有系统中的 runc，以防止容器化应用程序和底层主机系统可能受到损害。
31910编辑于 2025-11-14 危险的 runC 漏洞可能允许黑客逃逸 Docker 容器
漏洞详情CVE-2025-31133runC 通过 /dev/null 绑定挂载来"屏蔽"主机敏感文件。 CVE-2025-52565/dev/console 绑定挂载可通过竞争条件/符号链接被重定向，导致 runC 在启用保护机制前将非预期目标挂载到容器中。 CVE-2025-52881攻击者可诱骗 runC 向 /proc 目录写入数据，且该写入操作会被重定向到攻击者控制的目标。 影响范围CVE-2025-31133 和 CVE-2025-52881：影响所有版本的 runCCVE-2025-52565：影响 runC 1.0.0-rc3 及后续版本目前 runC 1.2.8、1.3.3 缓解措施runC 开发者分享了以下缓解措施：为所有容器启用用户命名空间，且不将主机 root 用户映射到容器命名空间中。
47420编辑于 2025-11-10- 来自专栏云鼎实验室的专栏
安全验证 | Runc CVE-2024-21626 容器逃逸漏洞预警
漏洞描述 2024年1月31号，runc官方发布安全通告（https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv 影响版本 v1.0.0-rc93 ~ 1.1.11 解决方案 1.当前runc官方已发布修复版本，建议升级至1.1.12版本 （https://github.com/opencontainers/runc static.ccs.tencentyun.com/fix-cve-2024-21626.tar.gz && tar -zxf fix-cve-2024-21626.tar.gz && fix-cve-2024-21626/runc-v1.1.12 sh 3.如无法升级到修复版本，短期内可以采用以下最佳实践来降低风险： （1）不使用非受信的镜像，包括作为基础镜像； （2）增强容器间的隔离，增强运行时安全检测能力，进而减轻漏洞的影响； 安全验证规则 runc 作为容器运行时的重要支撑组件，广泛与多种容器工具和平台集成使用，该漏洞几乎影响runc的所有历史版本，范围很广。
2.6K60编辑于 2024-02-05 - 来自专栏爱国小白帽的原创专栏
CVE-2021-30465——runc竞争条件漏洞复现与分析
0x01 漏洞简介 近日国外安全研究员发布了可导致容器逃逸的runc漏洞 POC，该漏洞影响runc 1.0.0-rc94以及之前的版本，对应CVE编号：CVE-2021-30465。 runc 是一个CLI工具，用于根据OCI规范生成和运行容器，该工具被广泛的应用于各种虚拟化环境中，如Kubernets。 runc版本：runc version 1.0.0-rc93 K8S版本：v1.15.5 Docker 版本：Docker version 18.06.3-ce a. runc 在调用 SecureJoinVFS 函数解析之后会将源目录挂载到校验通过的目标目录中。 1、 升级runc至官网给出的最新版本 2、 使用经审核和受信的容器镜像 3、 使用Red Hat官方提供的漏洞检测脚本，自检。
4.1K20发布于 2021-06-16 - 来自专栏云鼎实验室的专栏
漏洞分析｜RunC TOCTOU逃逸CVE-2021-30465分析
背景 国外安全研究员champtar[1]在日常使用中发现Kubernetes tmpfs挂载存在逃逸现象，研究后发现runC存在条件竞争漏洞，可以导致挂载逃逸[2]。 containerd和runC都是其中代表产物，从dockerd中再剥离出containerd[5]，向上提供rpc接口，再通过containerd去管理runC。 containerd在初期也是直接对runC进行管理，但为了解决containerd进行升级等操作时会造成不可用的问题，containerd再拆出containerd-shim，独立对接runC。 RunC通过命令runc create + runc start 或runc run启动一个容器，runc create主要分为两部分，一部分是准备容器进程的启动参数，与真正实施容器runc init进程进行交互 ，保证容器初始化顺利进行；另外一部分是执行克隆出的runc init进程，加入各种namespace并初始化容器进程的执行环境。
1.3K30发布于 2021-08-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号