最有效方式是检查/etc/docker/daemon.json并结合运行时排查。重点关注userns-remap、icc、no-new-privileges等配置，运行docker inspect确认Privileged和CapAdd，核查/dev、/proc/sys等挂载，修补需禁用模块加载、移除/lib/modules、锁定sysctl，并实测insmod和参数修改是否被阻断。
直接检查 Docker daemon 的配置文件 /etc/docker/daemon.json，是发现未受控特权容器及其对内核潜在危害最有效的方式。特权容器会绕过大部分命名空间和能力限制，可能加载恶意内核模块、修改关键参数，甚至触发容器逃逸。
识别 daemon.json 中的高危配置项
特权模式本身不写在 daemon.json 里，但它的启用依赖于运行时参数；而 daemon.json 控制着全局安全基线。重点关注以下几类配置：
-
"userns-remap": "default" —— 若缺失或设为
""，表示未启用用户命名空间映射，root 容器 UID 直接对应宿主机 root，放大提权后果 -
"icc": false —— 若为
true（默认值），则允许容器间无限制通信，可能被用于横向渗透并间接影响内核网络栈 -
"no-new-privileges": true —— 若缺失或设为
false，容器内进程可调用 execve 提升权限，配合 SUID 二进制文件易触发内核提权路径 -
"default-ulimits" 中若包含过宽松的
memlock或core限制，可能被用于内存锁定攻击或内核崩溃利用
检查运行时是否实际启用了特权容器
daemon.json 只管默认行为，真正危险的是运行时显式启用 --privileged 或过度授权。需结合运行中容器排查：
- 执行
docker ps --format "{{.ID}}\t{{.Names}}\t{{.Status}}" | grep "Up"获取活跃容器列表 - 对每个容器运行：
docker inspect --format='{{.HostConfig.Privileged}} {{.HostConfig.CapAdd}}' <ID>—— 返回true或非空 CapAdd 列表即属高风险 - 特别关注是否挂载了
/dev、/proc/sys、/lib/modules等目录，这些是操作内核模块和参数的关键路径
修补内核层面暴露面
特权容器常被用来加载非法内核模块或篡改 sysctl 参数。修补需从镜像构建和运行时双端入手：
- 在 Dockerfile 中禁用模块加载能力：
RUN echo 'install * /bin/true' > /etc/modprobe.d/disable-modules.conf - 构建镜像时移除
/lib/modules目录（除非明确需要）：RUN rm -rf /lib/modules - 启动容器时强制锁定关键 sysctl 值：
--sysctl net.ipv4.ip_forward=0 --sysctl kernel.modules_disabled=1 - 若使用 systemd 启动 dockerd，确认内核启动参数含
module.sig_unenforce的反例已被清除，且secure_boot或lockdown=confidentiality已启用
验证修补是否生效
修补后不能仅靠配置存在来判断，必须实测关键攻击路径是否失效：
- 进入疑似修复后的容器：
docker exec -it <容器名> sh - 尝试加载模块：
insmod /tmp/malicious.ko 2>/dev/null || echo "blocked"—— 应失败 - 尝试修改内核参数：
echo 1 > /proc/sys/kernel/unprivileged_userns_clone 2>/dev/null || echo "readonly" - 检查当前能力集：
capsh --print | grep cap_sys_module—— 输出应为空
