简介：一份面向Linux系统管理员与安全初学者的SELinux策略配置实验文档，聚焦操作系统安全中强制访问控制的落地操作。文档以实验一为主线，完整覆盖SELinux三种模式（enforcing、permissive、disabled）的切换与查看、安全上下文检查、文件复制与移动时上下文变化、chcon命令修改上下文、布尔值查询与永久修改等核心内容，并辅以samba与nfs服务的配置示例，便于按步骤实操对照。资源为单个docx文档，共216KB，内容紧凑，适合作为实验指导或复习笔记。已有478人学习下载，可用性得到初步验证。通过完成文档中的练习，读者能够掌握SELinux核心命令与排错思路，提升服务器安全配置能力，也能为后续安全实验打下基础。 干过Linux运维或者上过操作系统安全课的人，多半都有过这种经历：服务端口正常、进程也在跑、防火墙都放行了，可客户端就是连不上；或者文件明明有权限，程序一读取就被拒绝。查了半天，最后setenforce 0一试，一切正常——罪魁祸首就是SELinux。很多人遇到这种情况就直接关掉SELinux，图一时省事，可生产环境里这么干隐患非常大。我这篇就把实验一里涉及的SELinux策略配置完整拆开讲，从三种模式区别、布尔值开关、文件上下文管理，到用audit2allow生成自定义策略，把原理和实操串起来，新手照着做就能复现，老手也能查漏补缺。
需要提前说一句，这篇实验的操作全部在CentOS 7.9/RHEL 7兼容环境里完成，用的都是系统自带工具，没有额外装第三方组件。如果你用的是CentOS 8以上的版本，部分命令输出格式会略有差异，但核心思路完全一致。
1. 实验定位与整体思路拆解
1.1 为什么SELinux值得单独花一个实验去配
很多同学第一次接触SELinux，都会觉得它“除了添乱没别的用”。这种印象其实是因为SELinux和传统Linux权限模型根本不在一个维度上。
传统Linux权限是DAC（自主访问控制），意思是文件属主可以自己决定谁能访问自己的文件。这种模型有一个天然缺陷：一旦某个进程被攻破，攻击者就继承了这个进程的所有权限，能在系统里横向移动。而SELinux实现的是MAC（强制访问控制），它给每个进程和每个文件都贴了安全标签，进程能不能访问某个文件，不是由文件属主说了算，而是由系统全局策略说了算。即使用root账户操作，一样要遵守策略约束。
这个实验的核心目标就是把SELinux从“知道”变成“会用”。实验一不涉及太复杂的网络策略，重点在于让你亲手完成一次策略配置的闭环：发现问题、定位授权问题、执行策略调整、验证策略是否生效。这个闭环思路会贯穿后续所有实验。
1.2 实验流程的设计逻辑
整个实验我建议按四步走，顺序不要乱：
第一，确认SELinux当前状态，搞清楚系统处于哪种模式、哪些布尔值被修改过、哪些文件上下文异常。第二，制造一个典型的访问失败场景，比如HTTP服务读取不到自定义目录下的文件，让问题真实暴露出来。第三，针对问题做策略调整，分别用布尔值、文件上下文、自定义策略模块三种手段解决。第四，验证调整结果，同时测试策略回滚。
很多实验指导书上来就让你改配置，忽略了第一步，结果就是改了半天连问题都复现不了，自然也就不知道策略到底生效没有。我先踩过这个坑，所以建议你务必按顺序来。
2. 实验环境准备与基础概念
2.1 系统环境和初始化准备
建议准备一台最小化安装的CentOS 7.9虚拟机，内存2GB即可，磁盘20GB足够。最小化安装默认就带SELinux，不需要额外操作。如果你用的系统是CentOS 8或者Rocky Linux，同样适用。
装完系统后，先做两件事。第一件事，确认内核启动参数里没有selinux=0或enforcing=0，这两个参数会在内核层面直接禁用或降级SELinux：
cat /proc/cmdline正常输出里不应该出现selinux=0。第二件事，确认SELinux相关的包都已经安装：
rpm -qa | grep selinux至少能看到selinux-policy、selinux-policy-targeted和libselinux这几个包。缺哪个就yum install补上。
2.2 三种运行模式：Enforcing、Permissive、Disabled
SELinux一共三种模式，很多人记住了名字但理解不透。我用大白话解释一下：
- Enforcing（强制模式）：策略完全生效，违反策略的操作会被直接拒绝，并记录到审计日志。这是生产环境应该使用的模式。
- Permissive（宽容模式）：策略不真正拦截操作，但违反策略的行为会被记录下来。这个模式非常适合排查问题，相当于“只警告不处罚”。
- Disabled（禁用模式）：SELinux彻底关闭，连标签都不打。想重新开启只能修改配置文件后重启，不能运行时直接切换。
三种模式的切换方式：
getenforce # 查看当前模式 setenforce 0 # 临时切换为Permissive setenforce 1 # 临时切换为Enforcing注意：
setenforce只能在这两种模式之间切换，不能从Disabled切回Enforcing。如果/etc/selinux/config里设置了SELINUX=disabled，必须先改配置文件再重启。
永久生效需要修改/etc/selinux/config：
SELINUX=enforcing SELINUXTYPE=targeted其中SELINUXTYPE=targeted表示只对部分受保护进程（如httpd、sshd、named等）强制策略，其他进程不受限制，这是最常用的策略类型。还有一个mls类型，是更严格的多级安全策略，一般用不上。
2.3 三个核心概念：类型强制、布尔值和文件上下文
实验一的所有操作都围绕三个核心概念展开。
**类型强制（Type Enforcement）**是SELinux最核心的机制。系统里每个进程都有一个域（domain），每个文件都有一个类型（type），规则就定义“哪个域可以访问哪个类型”。举个例子，httpd_t这个域能否访问httpd_sys_content_t类型的文件，就是由策略规则决定的。
**布尔值（Boolean）**是SELinux提供的一组开关，用来在运行时调整策略中的某些规则，不需要重新编译策略。比如httpd_can_network_connect这个布尔值，控制httpd能否主动向外发起网络连接，默认是关闭的。布尔值的操作命令：
getsebool -a # 查看所有布尔值 getsebool httpd_can_network_connect setsebool httpd_can_network_connect on # 临时开启 setsebool -P httpd_can_network_connect on # 永久开启**文件上下文（File Context）**是SELinux给文件打的标签。ls -Z可以查看文件的SELinux标签，第一列就是用户、角色、类型等信息。文件移动到新位置后，标签可能不匹配，导致进程无法访问，这时需要用restorecon或semanage fcontext来修复。
这三个概念搞清楚了，后面的实验就顺理成章。
3. 策略配置实操全流程
3.1 先复现一个访问失败场景
实验一里我用的场景是：把网站文件放到自定义目录/webdata，然后配置httpd访问这个目录，结果浏览器始终打不开页面。这个场景非常典型，能同时触发文件上下文和布尔值两类问题。
初始化操作如下：
# 安装httpd yum install -y httpd # 创建自定义目录并写入测试页面 mkdir /webdata echo "<h1>SELinux Test Page</h1>" > /webdata/index.html # 修改httpd主配置 vim /etc/httpd/conf/httpd.conf # 找到 DocumentRoot "/var/www/html"，改为： # DocumentRoot "/webdata" # 同时找到 <Directory "/var/www/html">，改为： # <Directory "/webdata"> # 启动服务 systemctl start httpd启动服务本身不会报错，但用浏览器访问服务器IP，会一直转圈或直接拒绝连接，同时/var/log/httpd/error_log里会出现类似：
AH00132: file permissions deny server access: /webdata/index.html这个报错特别有迷惑性，因为ls -l /webdata/index.html看权限明明没问题。实际上问题出在SELinux标签上——/webdata目录被打上了default_t类型，而不是httpd_sys_content_t，httpd进程自然无权访问。
3.2 用semanage和restorecon修复文件上下文
定位到问题后，不要急着用chcon去改上下文。chcon只是临时修改，系统重新打标签或者执行restorecon后就会被覆盖。正确做法是用semanage fcontext定义默认上下文规则，然后执行restorecon让规则生效。
先确认当前标签和应有的标签：
ls -Zd /webdata # 输出类似：system_u:object_r:default_t:s0 /webdata ls -Zd /var/www/html # 输出类似：system_u:object_r:httpd_sys_content_t:s0 /var/www/html然后执行：
# 安装semanage工具（如果没装） yum install -y policycoreutils-python # 为/webdata目录添加默认上下文规则，加上正则匹配所有子文件 semanage fcontext -a -t httpd_sys_content_t "/webdata(/.*)?" # 让规则立即生效 restorecon -Rv /webdata执行完再确认标签：
ls -Zd /webdata # 输出应该变为：system_u:object_r:httpd_sys_content_t:s0 /webdata再次刷新浏览器，页面就能正常访问了。
这里有个细节值得注意：/webdata(/.*)?这个正则写法，既匹配/webdata目录本身，也匹配下面所有子文件和子目录。如果只写/webdata，那么子目录里的文件还是默认标签，网页引用嵌套目录时依然会访问失败。实验指导书上经常不写这部分，实际用的时候特别容易踩坑，我专门补充一句。
还有，restorecon -Rv的-R是递归，-v是显示过程，习惯性加上这两个参数，能看到哪些文件的标签被修正了，方便确认结果。
3.3 用布尔值解决httpd网络访问限制
文件上下文修好以后，页面能打开了。但如果你在这个服务器上部署了一个需要访问外部API的Web应用，会发现curl外部地址一直超时。这不是网络不通，而是SELinux布尔值httpd_can_network_connect默认为off，拦住了httpd进程发起对外连接。
查看和确认：
getsebool httpd_can_network_connect # 输出：httpd_can_network_connect --> off验证确实是这个原因导致的，可以临时打开再测：
setsebool httpd_can_network_connect on此时再执行curl就通了。确认无误后，加上-P参数永久生效：
setsebool -P httpd_can_network_connect on这个案例完美说明了布尔值的作用：它是SELinux策略预留给管理员的开关，让你在不修改策略文件的前提下，按需放行某些行为。
重要提示：在生产环境配布尔值，建议先用
setsebool不带-P测试，确认业务正常后再加-P永久化。如果直接永久化，万一引发安全问题，回滚就多了一步。
3.4 用audit2allow生成自定义策略模块
布尔值能解决常见的开关类问题，但有些场景布尔值没有对应选项，比如某个程序需要访问一个自定义端口的网络数据。这时候就要用到audit2allow，从审计日志里提取被拒绝的操作，自动生成一个自定义策略模块。
实验一里我用了一个相对简单的例子：让httpd允许使用自定义端口监听。先将httpd配置监听8000端口，然后启动服务，会发现启动失败，再看/var/log/audit/audit.log里有denied记录。把对应的AVC拒绝信息导入audit2allow：
# 查看最近的拒绝事件 grep "denied" /var/log/audit/audit.log | tail -20 # 将拒绝事件转换为自定义策略模块 grep "denied" /var/log/audit/audit.log | audit2allow -M httpd_custom执行后会在当前目录生成httpd_custom.pp和httpd_custom.te两个文件。其中.te是策略源码，.pp是编译好的二进制模块。加载模块：
semodule -i httpd_custom.pp然后重启httpd：
systemctl restart httpd服务就能正常启动了。
audit2allow的原理是分析DENIED事件中的源域、目标类型和操作类型，生成一条放行规则。用它可以快速解决问题，但也要注意：直接生成的规则往往比较宽泛，比如可能会放行所有域对特定类型的访问。在实验环境没问题，在真实生产环境里，建议对生成的.te文件做进一步细化。
4. 验证与回滚：确认策略生效并可控
4.1 场景复测与状态确认
配置完成后，需要系统性验证一次，而不只是“页面能打开就完事”。我的验证清单如下：
# 1. 确认当前模式 getenforce # 期望输出：Enforcing # 2. 确认布尔值状态 getsebool httpd_can_network_connect # 期望输出：on # 3. 确认文件上下文 ls -Zd /webdata # 期望输出：system_u:object_r:httpd_sys_content_t:s0 /webdata # 4. 确认自定义模块已加载 semodule -l | grep httpd_custom # 期望看到 httpd_custom 这一行 # 5. 实际访问测试 curl http://localhost # 期望输出：<h1>SELinux Test Page</h1> # 6. 确认没有新的拒绝事件 grep "denied" /var/log/audit/audit.log | tail -5如果第6步还能看到关于/webdata的拒绝记录，说明标签还有遗漏，需要排查子目录或嵌套文件。
另外还要梳理所有改过的配置项，我习惯统一汇总记录：
| 配置项 | 修改前 | 修改后 | 生效方式 |
|---|---|---|---|
| /etc/selinux/config | SELINUX=enforcing | 保持不变 | 永久 |
| httpd_can_network_connect | off | on | 永久（-P参数） |
| /webdata 文件上下文 | default_t | httpd_sys_content_t | 默认规则+semanage |
| httpd_custom模块 | 未加载 | 已加载 | semodule -i |
这份记录后续撤掉实验或者排错的时候非常有用。
4.2 策略回滚与模块卸载
实验做完要恢复环境，或者后续确认某个模块不再需要时，回滚操作必须熟练掌握。
布尔值回滚：
setsebool -P httpd_can_network_connect off文件上下文回滚：
# 删除自定义规则 semanage fcontext -d "/webdata(/.*)?" # 恢复默认标签 restorecon -Rv /webdata自定义模块卸载：
semodule -r httpd_custom回滚后同样要验证一遍服务状态是否回到实验前的表现。这里需要注意：restorecon恢复的是SELinux默认规则下的标签，如果/webdata本身就不在默认规则里，那么恢复之后它会变成default_t，HTTP服务自然就无法访问了——这才是符合预期的回滚结果。
我在做实验的时候，一开始图省事没有写回滚步骤，结果后面做第二次实验时环境状态不对，排查了很久才发现是上一次实验的残留策略没有清干净。从那次以后，我每个实验结束都会完整回滚并验证，这个习惯强烈推荐你也养成。
5. 常见问题与排查技巧实录
5.1 配置完成后依然被拒绝
这是最常见的坑。文件上下文、布尔值都改了，页面还是打不开，或者服务还是起不来。我总结的排查顺序是这样的：
第一步，先看SELinux模式是不是被临时切到了Enforcing以外。如果你之前用setenforce 0测试过，可能忘了切回来。getenforce一眼就能确认。
第二步，看审计日志里有没有对应拒绝记录：
ausearch -m avc -ts recent这一步会列出最近的AVC拒绝事件，里面有完整的源域、目标类型、操作信息，比直接在audit.log里grep更好用。如果没有记录，说明请求可能在到达SELinux之前就被其他机制拦截了，比如防火墙、文件系统权限或TCP wrapper。
第三步，确认标签是否真正生效。很多新手用chcon改完标签以为就完了，结果文件被某个进程改写了，标签又被重置。用semanage fcontext + restorecon的组合就不会有这个问题。
5.2 重启后配置丢失
配置重启后失效，十有八九是没加持久化参数。setsebool不带-P，重启就还原；chcon改的标签，执行restorecon就还原。解决办法参考3.2和3.3节，用semanage fcontext和setsebool -P。
还有一种情况是自定义模块加载了，但执行semodule -i之后没有确认模块真的加载成功。使用semodule -l | grep 模块名检查一下最稳妥。
5.3 日志刷屏和不当恢复
实验过程中如果调用很频繁，audit.log会被刷得很大。这时候不要用rm直接删掉日志文件，应该用：
service auditd restart或者更稳妥的方式：
auditctl -e 0 # 临时暂停审计 # 清理或归档日志 auditctl -e 1 # 恢复审计另外提醒一句：不要在生产环境直接删除audit.log，那可能同时破坏了审计链。
如果把SELinux设成了disabled又想恢复，注意修改/etc/selinux/config后必须重启系统。重启后文件系统可能需要重新打标签，启动过程会花一些时间，这是正常现象，耐心等即可。系统会自动在根目录生成.autorelabel标记文件来触发这个过程，重启完成后该文件会被自动删除。
5.4 快速排错速查表
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 服务启动失败 | 域无权限绑定特定端口 | ausearch -m avc -ts recent | semanage port -a -t http_port_t -p tcp 8000 |
| 网页403/404 | 文件上下文标签错误 | ls -Z对比标准目录 | semanage fcontext+restorecon |
| 程序无法访问网络 | 布尔值未开启 | getsebool -a | grep network | setsebool -P 对应布尔值 on |
| 配置重启后消失 | 未使用永久参数 | 检查命令是否带-P | 重新用setsebool -P |
| 自定义模块不生效 | 模块未加载 | semodule -l | semodule -i xxx.pp |
| 所有访问都被拒绝 | 系统进入Enforcing但策略被误改 | seinfo -t查看类型 | 恢复快照或重新编译策略 |
6. 实操心得与下一步延伸
这一个实验做下来，最核心的感受是：SELinux其实并不是故意跟管理员作对，它的每一个拒绝背后都有明确规则，关键是学会通过日志和标签去理解它的思路。就像新到一个城市，导航还没普及的时候，你会觉得红绿灯都是阻碍；可一旦掌握了路网规律，红绿灯反而成了保护你安全通行的工具。SELinux也是类似，它的类型强制、布尔值和文件上下文，本质上是在帮系统建立一套清晰的访问控制边界。
实验一用的都是最基础的配置手段，后续如果继续深入，还有不少值得探索的方向。比如用semanage port管理端口上下文，解决自定义端口监听问题；用semanage boolean批量管理布尔值，适合多台服务器统一策略；有条件的话还可以试试用sepolicy generate生成应用的自定义策略模板。这些都是实验一基础上的自然延伸，原理是一致的。
最后再分享一个我在实际排障中养成的习惯：每次做完SELinux相关操作，都会随手执行一次ausearch -m avc -ts recent，确认没有新的拒绝记录再继续干别的。看似多花几秒钟，实际上能省下后面大量排查时间。希望这篇实验笔记能让你少走我走过的弯路，把SELinux从“拦路虎”变成“守护者”。
本文还有配套的精品资源，点击获取
