selinux策略生效需上下文标签、布尔开关和日志反馈协同；单独改规则或布尔值常导致服务被拒，最直接证据是audit.log中avc: denied记录。

SELinux策略配置不是“写完就能用”，而是必须配合上下文标签、布尔开关和日志反馈三者协同生效；单独改策略规则（.te文件）或只调布尔值，大概率导致服务仍被拒绝。

如何快速判断是SELinux拦截了访问

最直接的证据在审计日志里：/var/log/audit/audit.log 中出现 avc: denied 字样。比如：

type=AVC msg=audit(1743926400.123:456): avc:  denied  { read } for  pid=1234 comm="httpd" name="index.html" dev="sda1" ino=567890 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

这说明 httpd_t 类型进程试图读取一个类型为 admin_home_t 的文件，被拒绝。此时不是权限不够，而是类型不匹配。

• 先运行 ausearch -m avc -ts recent 快速过滤最近的拒绝事件
• 确认服务是否真在 SELinux 管控下：用 ps -eZ | grep httpd 看进程上下文是否含 httpd_t
• 别急着关 SELinux——setenforce 0 只是临时绕过，掩盖问题而非解决

修改文件安全上下文：chcon vs semanage fcontext

chcon 是即时生效但不持久的标签修改，系统重启或执行 restorecon 后会还原；semanage fcontext 才是永久方案，它把规则写入策略数据库，后续 restorecon 会按此重置。

• 临时调试：用 chcon -t httpd_sys_content_t /var/www/html/file.txt
• 永久生效：先注册规则 semanage fcontext -a -t httpd_sys_content_t "/srv/myapp(/.*)?"，再执行 restorecon -Rv /srv/myapp
• 注意正则语法：(/.*)? 表示匹配目录及其所有子路径，漏掉会导致子目录仍用默认标签
• semanage fcontext -l | grep myapp 可验证规则是否已存入

启用服务特定功能：setsebool 布尔值开关

很多服务（如 FTP、Samba、NFS）的功能受 SELinux 布尔值控制，默认关闭。这些开关不是“开就万事大吉”，要区分是否加 -P 参数：

• setsebool ftpd_anon_write on：仅当前会话有效，重启后恢复默认
• setsebool -P ftpd_anon_write on：写入策略库，永久生效（推荐生产环境使用）
• 查可用布尔值：getsebool -a | grep ftp 或 seinfo -b | grep ftp
• 常见陷阱：开了 ftpd_anon_write 却忘了同步设置文件上下文为 public_content_rw_t，写操作仍失败

从 audit.log 自动生成策略模块：audit2allow 是把双刃剑

audit2allow 能基于拒绝日志生成 .te 规则，但它生成的是“最小放行”策略，不校验合理性，盲目安装可能扩大攻击面。

• 基础流程：ausearch -m avc -ts today | audit2allow -M myhttpd → 生成 myhttpd.te 和 myhttpd.pp
• 安装模块：semodule -i myhttpd.pp
• 务必先用 audit2allow -R（-R 表示引用现有策略模块）减少冗余规则
• 生成前建议加 -w 查看人类可读解释：ausearch -m avc -ts today | audit2allow -w
• 不要在生产环境直接跑 audit2allow -a -M xxx —— 它会把所有拒绝都放开，包括明显危险的操作（如 execmem）

真正难的从来不是写一条 allow 规则，而是理解为什么这个 allow 是必要的、是否引入了新的类型越权路径；每次修改后，用 sesearch -A -s httpd_t -t admin_home_t 检查规则链，比反复重启服务试错更可靠。