容器特权模式一旦开启，容器就拥有宿主机root权限和全部内核能力，安全边界基本消失，风险等级等同于直接在宿主机上执行root命令。
容器特权模式到底改变了什么安全边界
普通容器依赖Linux内核的命名空间和控制组构建隔离层,进程、文件系统、网络栈看似独立，实际上还是共享同一个宿主机内核，而--privileged参数会一次性关闭大部分隔离机制，让容器直接暴露在宿主机内核面前。
权限维度：从受限进程变成“伪root”
普通容器内的root已被降权,很多操作被Seccomp、Capabilities拦下，比如mount、ptrace、修改/sys下的内核参数，都会失败，但特权容器不同，它拥有全部Capabilities，并且可以访问宿主机所有设备节点。
最直观的区别：在特权容器里执行cat /proc/1/cgroup，你能看到宿主机的进程信息；访问/dev/sda也能直接读取宿主机磁盘块设备，这些操作在普通容器里会返回Permission denied。
设备访问：绕过设备隔离机制
普通容器默认只能看到自己命名空间内的虚拟设备,特权容器则自动挂载宿主机所有/dev设备，这意味着容器内可以直接dd磁盘、修改硬件配置，行业共识认为，这等于把宿主机硬件完全信任给容器内的进程。
容器特权模式安全风险有哪些：三条真实攻击路径
很多攻击者首先扫描暴露的Docker API，然后尝试创建特权容器，一旦成功，几乎等于拿到宿主机root shell，主要有三条路径。
直接读取宿主机敏感文件
在特权容器内执行mount /dev/sda1 /mnt，然后cat /mnt/etc/shadow，就能拿到宿主机密码哈希，这一步操作简单，不需要任何漏洞利用，实际操作中，攻击者还会读取SSH私钥、数据库备份、云服务凭证。
利用内核漏洞提权
特权容器拥有所有Capabilities,但缺少安全模块限制，如果宿主机内核存在本地提权漏洞，攻击者在容器内触发漏洞，就能直接控制宿主机，由于容器和宿主机共享内核，漏洞利用的成功率显著提升。
修改内核运行时参数
特权容器可以写入/proc/sys和/sys下的内核接口，比如禁用iptables、修改net.ipv4.ip_forward、关闭ASLR，这些操作会削弱宿主机整体防御能力，为后续攻击创造条件。
需要记住的是，上述攻击不需要容器内部有漏洞，只要攻击者能进入特权容器，就能以极低成本接管宿主机。
docker privileged参数有什么用？何时该用何时禁用
docker run --privileged这个参数的存在价值，在于解决一些特殊场景的兼容性问题，它不是为了日常使用准备的。
必须使用privileged的少数场景
- 运行Docker-in-Docker（DinD），比如CI流水线中需要构建容器镜像
- 操作宿主机硬件设备,比如加载内核模块、配置网卡、控制USB设备
- 运行需要完整SYS_ADMIN能力的监控工具,比如一些系统追踪程序
在这些场景下,开发者没有时间逐一配置Capabilities，所以选择一刀切，但业内专家指出，即使在这些场景，也建议用--cap-add精准授权，而不是直接开privileged。
禁止使用privileged的场景
- 运行来自不可信来源的镜像
- 面向公网提供服务的Web应用容器
- 多租户共享宿主机环境
- 任何需要隔离用户数据的应用
如果你只是需要容器内访问某个USB设备,用--device参数指定就行，完全没必要开privileged。
容器特权模式与普通模式区别对照表
| 维度 | 普通容器 | 特权容器 |
|---|---|---|
| Capabilities | 默认受限，约14项基础能力 | 全部约40项能力 |
| 设备访问 | 仅虚拟设备，无宿主机磁盘 | 自动挂载所有/dev设备 |
| Seccomp限制 | 默认启用默认策略 | 默认关闭 |
| AppArmor/SELinux | 默认加载 | 绕过 |
| 修改内核参数 | 多数被拒绝 | 允许 |
| 挂载文件系统 | 仅允许白名单类型 | 允许所有类型 |
| 容器逃逸风险 | 低（仍需内核漏洞） | 极高（可直接访问宿主资源） |
对照表能直观看出,privileged不是”多给了几个权限”，而是直接移除了安全边界，实践中，多数容器逃逸攻击都利用特权容器作为跳板。
生产环境如何收敛特权容器的安全边界
如果你已经承担了特权容器的风险,至少要叠加上限控制，以下操作路径都是经过验证的具体方案。
用Capabilities替代privileged
找出容器真正需要的能力,精准授予，比如只需要挂载文件系统，就执行：
docker run --cap-add=SYS_ADMIN --cap-drop=ALL your-image
如果需要修改网络配置,用--cap-add=NET_ADMIN，这样即使容器被攻破，攻击者也无法使用其他能力。
强制启用Seccomp和AppArmor
自定义Seccomp配置,阻止容器调用mount、ptrace、unshare等高危系统调用，在Docker中指定：
docker run --security-opt seccomp=./custom.json --security-opt apparmor=your-profile your-image
实测中,这套组合能拦截绝大多数利用内核漏洞的逃逸尝试。
隔离关键目录和资源
运行特权容器时,主动丢弃宿主机的敏感挂载点。
docker run --privileged -v /data:/data -e HOST_PROC_DIR=/proc host_checker
不要在容器内挂载宿主的/etc、/root、/var/lib/docker，如果必须访问宿主设备，用--device逐个指定，不要用默认的全量设备映射。
监控和审计
开启Docker的审计日志,记录所有docker run --privileged调用，同时在宿主机层面监控/dev设备访问、敏感文件读取、内核模块加载行为，一旦发现异常，立即停止容器并检查镜像来源。
常见问题：privileged容器可以访问宿主机文件吗
privileged容器能直接修改宿主机系统时间吗？
能,特权容器拥有SYS_TIME能力，可以调用settimeofday，在容器内执行date -s就能修改宿主机时间，普通容器会报错，这验证了特权容器对宿主系统资源拥有完全控制权。
docker run –privileged和–cap-add=ALL有区别吗？
本质上区别不大,两者都授予全部Capabilities，但privileged额外关闭了Seccomp，并自动挂载宿主机设备文件系统，所以privileged的权限范围大于单纯的--cap-add=ALL，多数安全基线检查会把privileged视为高危配置。
容器内已经有root权限，还需要开启privileged吗？
普通容器内的root只是命名空间内的root,没有宿主机的完整权限，开启privileged后，容器内root直接对应宿主机root，多数业务场景不需要这种权限映射，如果应用提示权限不足，优先排查文件属主和Capabilities，而不是直接加privileged。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641930.html
