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 检查规则链，比反复重启服务试错更可靠。
