在启用 SELinux 的 Linux 发行版上运行 Docker 时，最常见的报错就是容器启动后无法读取宿主机挂载的目录，或者容器内进程被拒绝执行某些操作。日志中出现类似 avc: denied { read } for pid=... comm=... name=... 的信息，说明 SELinux 强制访问控制正在阻止容器进程。理解这一点是后续配置兼容的基础。
SELinux 与 Docker 冲突的根因
SELinux 使用类型强制（Type Enforcement）和 MLS 等机制为每个进程和文件打标签。Docker 容器进程通常运行在 container_t 域，其可访问的文件类型包括 container_file_t、svirt_sandbox_file_t 等。宿主机目录一般是 usr_t、var_t、etc_t 等，不在容器域允许范围内，于是出现 Permission Denied。如果不加任何处理，单纯使用 docker run -v /data:/data 来挂载目录，容器内访问 /data 时就会被 SELinux 拦截。这种情况下即使把目录权限改成 777，或者让容器以 root 身份运行，错误依然存在，因为 SELinux 的强制访问控制与传统的 DAC（自主访问控制）是叠加关系，不是替代关系。
Docker 默认启用命名空间、cgroups 等隔离技术，但这些技术主要隔离进程视图和资源限制，并不能替代 SELinux 的标签策略。相反，启用 SELinux 之后，容器进程会受到额外的策略约束，这本身是增强容器安全的一种方式。问题在于，许多用户在初始部署时对挂载目录没有做标签转换，导致 Docker 与 SELinux 之间产生不兼容的假象。实际上只需要让挂载目录的 SELinux 类型符合容器域的可访问范围，大部分故障就能消除。下面的命令可以直观复现这个问题：
docker run --rm -v /srv/app:/data alpine ls /data # 可能出现 ls: /data: Permission denied
要查看具体的拒绝原因，可以使用 ausearch -m avc -ts recent 或者 journalctl -t setroubleshoot 来读取 AVC 日志。日志中会明确指出源域、目标类型以及被拒绝的操作，这是后续排错的重要依据。
启用 Docker 的 SELinux 支持与卷标签
Docker 守护进程提供了一个 --selinux-enabled 选项，用来让 Docker 配合 SELinux 工作。开启之后，Docker 会为每个容器分配独立的 SELinux 标签，而不是让所有容器共用同一个域，这样就能有效避免容器之间的互相访问。在 /etc/docker/daemon.json 中可以这样配置：
{
"selinux-enabled": true
}
保存配置文件后，需要执行 systemctl restart docker 让守护进程重新加载。开启该选项之后，容器进程会被打上不同的 MCS（Multi-Category Security）标签，即使两个容器都运行在 container_t 域，它们的类别也不同，互相之间无法访问对方的文件。这是 SELinux 为容器提供额外隔离层的关键机制。需要注意的是，仅开启该选项并不能解决宿主机目录挂载的权限问题，还需要对挂载卷进行标签处理。
对于挂载卷，使用 :z 和 :Z 后缀是最直接的方法。:z 会重新标记宿主机目录为 container_file_t 类型，并允许多个容器共享访问；:Z 则会给目录加上私有标签，只有当前容器能够访问，其他容器即使挂载同一目录也会被 SELinux 拒绝。常见用法如下：
# 多个容器共享同一挂载点 docker run -d -v /srv/shared:/data:z nginx # 仅当前容器私有访问 docker run -d -v /srv/private:/data:Z nginx
这两种后缀在底层相当于执行了 chcon -Rt svirt_sandbox_file_t 之类的标签修改操作，只是 Docker 在挂载时自动完成。使用 :Z 时要谨慎，因为它会改变宿主机目录的 SELinux 标签，如果该目录被其他系统服务使用，可能会影响它们的正常访问。若需要恢复原始标签，可以执行 restorecon -Rv /srv/private。对于系统关键目录，不建议使用 :Z，应优先考虑通过其他方式调整策略。
使用布尔值与自定义策略处理特殊场景
有些容器操作需要额外权限，例如绑定低端口、访问用户主目录、使用 NFS 挂载等。SELinux 提供了一系列布尔开关来控制这些行为。与容器相关的布尔值可以通过 getsebool -a | grep container 查看，其中 container_manage_cgroup 控制容器进程管理 cgroup，virt_use_nfs 允许容器访问 NFS 挂载，container_use_devices 控制容器对设备节点的访问。永久开启某个布尔值的命令如下：
getsebool -a | grep container setsebool -P virt_use_nfs on setsebool -P container_use_devices on
布尔值方式的优点是简单、可逆，而且不会破坏 SELinux 的整体策略。不过它只能覆盖策略中预先设计好的开关，不能满足所有自定义需求。如果布尔值仍无法解决故障，就需要根据 AVC 拒绝日志生成自定义策略模块。这种方式可以做到最小权限授权，既让容器正常运行，又不会关闭 SELinux 的保护。
自定义策略的典型步骤是：先复现问题，再收集 AVC 日志，然后使用 audit2allow 工具将拒绝记录转换成策略模块。下面的命令展示了从日志到模块安装的完整过程：
ausearch -m avc -ts recent | audit2allow -w ausearch -m avc -ts recent | audit2allow -M mydocker semodule -i mydocker.pp
第一条命令用于查看建议开启的布尔值，第二条命令生成名为 mydocker 的策略模块，第三条命令安装该模块。生成的策略只允许被拒绝的那部分操作，因此比直接使用 setenforce 0 或者 --security-opt label=disable 要安全得多。临时调试时可以用 --security-opt label=disable 来快速验证问题是否与 SELinux 有关，但生产环境应避免长期使用，否则等于放弃了 SELinux 对容器的安全约束。
排错流程与最佳实践
在实际运维中，遇到 SELinux 与 Docker 的兼容问题时，可以按照固定的排查顺序来处理。首先确认 SELinux 当前是否处于 enforcing 模式，使用 getenforce 即可查看。然后检查 AVC 拒绝日志，确定是哪个源域访问哪个目标类型被拒绝。接着检查挂载目录的 SELinux 标签，使用 ls -Z /srv/app 查看。如果目标类型不是 container_file_t，可以尝试在挂载时添加 :z 或 :Z。若问题依旧，再查询相关布尔值，最后考虑自定义策略模块。整个思路可以用下面的表格概括：
| 现象 | 常见原因 | 解决方式 |
|---|---|---|
| 容器访问挂载目录 Permission denied | 宿主机目录标签不是 container_file_t | 挂载时加 :z 或 :Z |
| 容器无法绑定低端口 | 缺少对应 SELinux 布尔值 | setsebool -P virt_use_nfs on 等 |
| 多个容器互相访问数据 | 未开启 --selinux-enabled | 在 daemon.json 中启用 selinux-enabled |
最佳实践是默认开启 Docker 的 SELinux 支持，挂载卷统一使用 :z 或 :Z 标签，遇到特殊需求优先调整布尔值，只有在前几种方法都无效时才编写自定义策略模块。同时要养成查看 AVC 日志的习惯，不要一遇到权限问题就直接关闭 SELinux。只有把 SELinux 当作容器安全的一部分来维护，才能真正做到既兼容 Docker，又不降低主机防护能力。