解读

面试官想验证三件事：

1. 你是否能在国内合规场景下（等保、关保、信创）第一时间把“逃逸”风险降到可接受范围；
2. 你是否熟悉runc 与 Docker Engine 的耦合关系，能在不破坏业务连续性的前提下完成止血；
3. 你是否具备闭环思维：止血→验证→加固→复盘，并能把过程沉淀为可复用的 SOP。

知识点

• runc 是 Docker 默认的 low-level 容器运行时，漏洞直接穿透宿主机 namespace，传统网络隔离无效。
• 国内监管要求：2 小时内初步报告、24 小时内提交处置方案、72 小时内完成整改并留痕。
• 热补丁/冷补丁区别：热补丁无需重启容器，冷补丁需重启 Docker daemon，影响业务。
• 容器逃逸三板斧：升级 runc、禁用 user-namespace 映射、seccomp 黑名单拦截 exploit 系统调用。
• 镜像供应链：国内云厂商 TCR、华为 SWR 均已同步官方 runc 修复版本，需验证 SHA256 一致性。
• 灰度止血：利用 Swarm/ACK 标签，先隔离非生产集群，再分批滚动，满足金融级“双录”审计。

答案

我接到应急通知后，按**“黄金 30 分钟”**流程执行：

1. 确认漏洞真实性与影响面
   通过公司安全部邮件+国家信息安全漏洞共享平台（CNVD）编号交叉验证，确认 CVE-2025-XXXX 已收录，CVSS 9.8，可本地提权。

2. 立即启动一级响应
   在飞书应急群@相关负责人，同步**“runc 逃逸→宿主机 root”**风险，申请封禁新容器创建权限。

3. 止血三步走
   a. 版本隔离：
   查询现网 runc 版本 docker info | grep runc，发现 1.1.12 为受影响版本；立即在 YUM 仓库里屏蔽该版本，并推送自建 Nexus 仓库的 1.1.14 修复版。
   b. 运行时热补丁：
   对无法立即重启的核心支付容器，使用阿里云 ACK 提供的 runc-hotpatch-2025XXXX.so，通过 docker-runc replace 在线替换二进制，无需重启 daemon，业务 QPS 零跌落。
   c. 攻击面缩小：
   在 /etc/docker/daemon.json 追加 "no-new-privileges": true 与 "userns-remap": "default"，强制所有新容器使用用户命名空间映射，降低逃逸后 UID=0 风险；同步推送 seccomp 配置文件，拉黑 exploit 用到的 keyctl 系统调用。

4. 验证与监控
   使用 ctr run --rm --runc-binary /usr/bin/runc-test poc:latest /exp.sh 验证补丁后 exploit 无法获得宿主机 shell；
   在夜莺监控增加宿主机 dmesg | grep "overflow" 关键字告警，5 分钟内触发电话通知。

5. 合规闭环
   24 小时内输出《CVE-2025-XXXX 处置报告》提交网安支队，包含漏洞概述、影响资产清单、止血措施、复测截图、残余风险评级（中→低），并申请复测销号。

拓展思考

1. 如果企业已全面切到containerd + cri-o，如何复用上述止血逻辑？
   答：把 runc 升级动作下沉到 ctr runc upgrade 即可，seccomp 与 userns 配置在 cri-o 的 default_mounts.json 中同步，脚本无需改动，体现对 OCI 标准的深度理解。

2. 信创 ARM 场景下，官方修复包未发布，如何自编译？
   答：基于麒麟 V10 SP3的 gcc10 工具链，拉取 runc 1.1.14 源码，打开 TAGS="seccomp apparmor"，交叉编译后使用 docker-runc checksum 对比 x86 哈希，确保供应链一致性；通过私有 yum 仓库发布，解决国产 CPU 无官方 RPM 的痛点。

3. 后续如何把“应急”变“常态”？
   答：将止血脚本固化成Ansible Role，接入DevSecOps 流水线；每次构建自动对比 NVD 与 CNVD 漏洞 feed，runc 版本≥1.1.14 才允许合并到 release 分支，实现“漏洞左移”，让面试官看到你具备可持续安全运营的架构视野。