selinux 是 linux 内核的强制访问控制机制，通过安全上下文（user:role:type:level）和策略规则精细管控资源访问；问题多因上下文不匹配或策略缺失，应优先用 semanage、restorecon 修正上下文，audit2why/audit2allow 分析生成规则，谨慎使用布尔值，避免直接禁用。
SELinux 是 Linux 内核中强制访问控制（MAC）的核心机制，它通过策略规则限制进程对文件、端口、网络等资源的访问，远比传统 DAC（如 rwx 权限）更精细、更安全。实践中，多数问题并非 SELinux 本身“太严”，而是上下文（context）不匹配或策略未覆盖新场景。关键在于理解 context、正确迁移和按需微调，而非直接禁用。
看懂并检查文件 SELinux 上下文
每个文件/目录都有一个安全上下文，格式为 user:role:type:level（如 system_u:object_r:httpd_sys_content_t:s0）。Web 服务读取网页文件失败，常因 type 不匹配，而非权限 755 或属主不对。
常用命令：
-
ls -Z /var/www/html/index.html：查看文件当前上下文 -
ls -Zd /var/www/html/：查看目录上下文（注意加-d） -
sestatus -b | grep httpd：确认相关布尔值（如httpd_read_user_content）是否启用
用 semanage 和 restorecon 修正上下文
直接改 chmod 或 chown 解决不了 SELinux 拒绝——必须让上下文与服务预期一致。
典型操作流程：
- 若把静态页面放到
/srv/myapp/，但 httpd 无法读取：先查默认策略是否支持该路径 - 运行
semanage fcontext -a -t httpd_sys_content_t "/srv/myapp(/.*)?"，添加路径映射规则 - 再执行
restorecon -Rv /srv/myapp，批量重置上下文（-v 显示变更，-R 递归） - 验证：
ls -Z /srv/myapp/index.html应显示httpd_sys_content_t
临时调试：用 audit2why 和 audit2allow 快速定位与生成规则
当服务突然报“Permission denied”且日志里有 avc denied 记录时，别急着关 SELinux。
高效排查步骤：
- 重启服务后立即执行
ausearch -m avc -ts recent | audit2why，直观解释拒绝原因（如“需要 file_type httpd_sys_rw_content_t”） - 若确认是合理需求（如 PHP 需写入缓存目录），可用
ausearch -m avc -ts recent | audit2allow -M myphpcache生成自定义模块 - 加载模块：
semodule -i myphpcache.pp；模块可导出复用：semodule -l | grep myphp
谨慎使用布尔值与禁用策略
SELinux 布尔值（booleans）是策略的开关，适合常见场景的快速启停，比写自定义规则更安全可控。
常用示例：
-
setsebool -P httpd_can_network_connect 1：允许 Apache 发起外网连接（如调用 API） -
setsebool -P samba_export_all_ro 1：让 Samba 只读共享任意目录 - 禁用某条策略前，先查影响范围：
sesearch -A -s httpd_t -t user_home_t -c file -p read
除非明确测试环境且无安全要求，否则不建议设 SELINUX=disabled。更稳妥的是切换为 permissive 模式（setenforce 0），记录所有拒绝但不阻止，便于审计后修复。
