容器内的提权工具
容器内装 sudo 把提权面搬进了镜像：任何能执行 sudo 的应用漏洞都可能放大成容器内最高权限。除非场景明确，基础镜像里就不应该带它。
基本信息
| 检查方式 | 用 command -v 核对，或看镜像历史与包清单 |
|---|---|
| 影响 | 提权链更短、审计噪声更多 |
| 修复方向 | 构建期移除，改用固定的非特权用户运行 |
| 适用环境 | 所有容器镜像 |
| 配套措施 | 镜像扫描把提权工具列为检查项 |
典型使用场景
- 审查基础镜像里是否带有提权工具
- 排查容器内应用可以调用哪些提权手段
- 整理镜像瘦身清单时定位多余组件
- 应对合规检查中对提权路径的要求
- 事故复盘：确认容器内的权限放大路径
检查与清理
检查与清理
docker run --rm --entrypoint sh myapp:1.4 -c 'command -v sudo || echo 无 sudo'
docker history --no-trunc myapp:1.4 | grep -i sudo | head -5 # 看构建历史
# 构建期清理：按发行版卸载提权工具并切换到非特权用户关注点与风险表现
| 关注点 | 正常表现 | 风险表现 |
|---|---|---|
| 工具是否存在 | 未安装 | 镜像内可直接调用 |
| 提权配置 | 无免密配置 | 免密配置叠加提权位 |
| 运行用户 | 固定非特权用户 | 以最高权限运行 |
| 审计记录 | 无提权事件 | 频繁提权记录 |
多阶段构建的最终镜像只保留运行时依赖，这类工具在收尾阶段自然会被剥离。
免密配置叠加提权能力时风险明显放大，扫描清单里要把提权工具设为检查项。
按发行版用包管理器清理并验证依赖，直接删二进制而不走包管理会留下不一致状态。
应用以非特权用户运行时，即使被攻破影响面也明显更小，这是最有效的收敛手段。
构建历史里出现提权工具不代表当前镜像仍有，核对时要看最终镜像的实际内容。
把镜像内用户改成非特权用户属于运行方式变更，改完要回归验证应用的读写路径是否仍然可用。