企业官网建设流程全解析

简介：操作系统安全实验配置SELinux策略（实验一）docx文档，面向Linux系统管理员、安全运维人员及高校相关课程师生，旨在帮助读者系统掌握SELinux强制访问控制机制的配置方法。文档完整覆盖实验目的、操作步骤与原理说明，依次讲解enforcing、permissive、disabled三种模式的含义与切换，getenforce、sestatus、setenforce等核心命令的用法，以及文件与进程安全上下文的查看方式；同时深入演示了复制与移动文件时安全上下文的变化、chcon命令修改类型、setsebool布尔值查询与永久修改，并结合httpd、samba、nfs等典型服务场景说明策略配置的应用要点。资源为1个docx文档，包体仅216KB，内容结构清晰、步骤完整，可直接按文档动手实验。该文档已有478人学习下载，适合作为实验教学或自学参考。

1. 一份配置 SELinux 策略的实验文档，值得照着敲一遍

很多人的 Linux 生涯是从setenforce 0开始的——装完系统第一件事就是把 SELinux 关掉，仿佛它是台机器上最碍事的安全模块。但等你真正要应付等保测评、过安全审计，或者在生产环境排查"为什么服务起来却连不上"的诡异问题时，会发现 SELinux 的强制访问控制（MAC）恰恰是操作系统安全里最不能绕开的一环。这份《操作系统安全：实验配置SELinux策略(实验一).docx》就是面向这个场景的完整实验指导：它把 SELinux 从模式切换、安全上下文排查到布尔值设置、AVC 拒绝日志定位串成了一条可复现的主线。适合正在上操作系统安全课的学生、刚接触 CentOS/RHEL 系列的运维新手，以及一直用关闭 SELinux 当"解药"的开发者。

2. 前置准备：三种模式与安全上下文是绕不开的基础

2.1 三种模式与切换命令：先搞清楚当前系统在哪个状态

SELinux 是 Linux 内核自带的强制访问控制机制，和传统的 Unix 权限（DAC，即文件 owner/group/other 的 rwx）不一样，它由内核强制实施，进程无法自行绕过。实验文档的第一部分基本都会要求你理解它的三种模式：Disabled（禁用）、Permissive（宽容，只记录不拦截）、Enforcing（强制，按策略拦截并记录）。判断当前状态用getenforce，临时切换用setenforce。

# 查看当前 SELinux 模式 getenforce # 临时切换到 Permissive（只记录日志，不拦截访问） setenforce 0 # 临时切换到 Enforcing（强制模式，按策略拦截） setenforce 1

这里的逻辑很关键：setenforce只对当次运行生效，重启后以配置文件/etc/selinux/config里的SELINUX=行为准。我一般会建议实验前先跑一遍getenforce确认初始状态，免得后面排查问题时连"当前到底拦没拦"都没概念。

三种模式的行为差异我用一张表整理过，实验报告里也常用：

需要提醒的是，Disabled 与 Permissive 看起来都是"不拦截"，但实际差别很大：Permissive 下 SELinux 内核模块仍然在跑，策略、上下文、布尔值全部生效，只是违反策略的动作不阻断，所以它是排障时用来"确认是不是 SELinux 拦的"最好手段；Disabled 则是整个内核安全模块都不加载，恢复回来必须重启。实验指导里通常也强调：不要在 Disabled 状态下做策略实验，因为你改的上下文和布尔值根本没生效。

2.2 安全上下文：ls -Z 与 user:role:type:level

SELinux 里每个文件、进程、端口、设备都有安全上下文，格式是user:role:type:level，比如system_u:object_r:httpd_sys_content_t:s0。其中最重要的字段是 type（类型），因为 SELinux 策略的绝大多数规则是"域（domain，进程的类型）与类型（type，资源的类型）之间的允许关系"，这就是 TE（Type Enforcement，类型强制）的核心思路。

# 查看文件的安全上下文 ls -Z /var/www/html/index.html # 查看 httpd 进程的域 ps -eZ | grep httpd

命令本身不复杂，但要把四个字段拆开理解：system_u是 SELinux 用户，通常与 Linux 登录用户无关；object_r是角色，对文件来说基本都是 object_r；httpd_sys_content_t是类型，决定这个文件能被哪个域读取；s0是 MLS/MCS 级别，在 targeted 策略下一般不用动。实验里最容易翻车的不是不会敲ls -Z，而是不理解"文件类型必须与访问它的进程域匹配"这件事。

2.3 实验环境检查清单：快照与策略工具包

实验前提是装好必备工具包和审计服务，并给虚拟机拍一个干净快照。这个快照就是后悔药——后面做semanage、setsebool的修改如果污染了环境，一件还原就能回到基线。

# CentOS / RHEL / Rocky Linux 下安装 SELinux 管理工具 yum install -y policycoreutils-python-utils setools-console audit # 确保 auditd 审计服务在运行 systemctl start auditd systemctl enable auditd

policycoreutils-python-utils提供semanage，setools-console提供sesearch和seinfo，auditd负责把内核的 AVC 拒绝记录写进/var/log/audit/audit.log。对环境有疑惑时，先用sestatus看详细状态。

这里有个发版差异要提前说：如果你用的是 Ubuntu，默认强制访问控制组件是 AppArmor 而不是 SELinux，直接敲semanage大概率报 command not found。实验准备阶段先确认发行版和内核参数，别在错误的系统上硬套命令浪费时间。

3. 核心实验：把 Apache 端口迁移到 8090，完整走一遍策略配置

3.1 实验场景：为什么 httpd 绑定 8090 会失败

这份实验文档的主线我按最经典的场景理解为"把 httpd 从默认端口迁到非标准端口"。生产者环境里，为了减少默认端口扫描,把 Web 服务改到 8090 是很常见的做法。但在 Enforcing 模式下，httpd_t域只被策略允许绑定少数几个已定义的端口类型，8090 不在其中，于是启动就会失败。这条主线能同时覆盖端口类型、文件上下文、布尔值三类策略操作，是 SE Linux 实验里性价比最高的一条。

# 安装 httpd 并修改监听端口 yum install -y httpd vim /etc/httpd/conf/httpd.conf # 把 Listen 80 改为 Listen 8090 # 启动服务 systemctl start httpd

如果当前是 Enforcing，start 后大概率拿到失败，systemctl status httpd会提示"权限被拒"或"无法绑定地址"。第一反应不要去看/var/log/httpd/error_log，先去查 AVC 拒绝记录：

# 检索 AVC 拒绝日志 grep avc /var/log/audit/audit.log | grep httpd | tail -20

日志里的关键条目长这样：type=AVC msg=audit(...): avc: denied { name_bind } for pid=... comm="httpd" ... scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=tcp_socket。denied { name_bind }已经说得很明白了：httpd 这个域不允许绑定这个端口。这行日志是整个实验的出发点——SELinux 不是玄学，它把所有拒绝都写在了日志里。

3.2 用 semanage port 添加端口映射

理解了拒绝原因后，正确做法是查看 SELinux 定义的端口类型，再把 8090 映射到http_port_t：

# 查看当前 http 端口类型的现有端口 semanage port -l | grep http_port_t # 把 8090 端口加入 http_port_t semanage port -a -t http_port_t -p tcp 8090

semanage port -a中-a代表 add，-t http_port_t是端口安全类型（不是 httpd_port_t，拼写容易错，注意最后是_t），-p tcp指定协议。这一步做完再systemctl start httpd，服务通常就能起来了。

一个值得注意的细节是：修改后不要急着收工，运行semanage port -l | grep http_port_t确认 8090 已进入列表。很多排障卡在"我明明加过了"——结果是加到了http_cache_port_t或其他类型上，类型不匹配等于白加。

3.3 布尔值开关：httpd 访问后端网络服务

端口问题解决后，实验文档通常会进一步引入布尔值（boolean）。布尔值是 SELinux 提供给管理员"开关式"调整策略的机制，不需要重新编译策略模块。典型场景是 httpd 需要跨网络访问后端应用服务器或数据库，默认策略不允许httpd_t域主动建立向外连接。

# 查看与 httpd 相关的布尔值 getsebool -a | grep httpd # 打开 httpd 的网络连接能力，-P 持久化到磁盘 setsebool -P httpd_can_network_connect 1

-P表示把修改写入策略存储，重启后仍生效；不加-P只是临时生效。实验报告里我一般会建议两个都验证一遍：先不带-P确认问题解决了，再带-P做持久化，最后用reboot验证配置没有丢。

3.4 文件上下文：自定义网站目录为什么返回 403

第三个常见实验点是自定义网页目录。很多人把网站文件放在/data/webroot并改好 httpd 配置后，发现服务起来但访问返回 403 Forbidden，删除文件权限也没用。这不文件权限的事，而是新目录的安全上下文类型还是default_t，httpd 域根本没有读取它的权限。

# 为自定义目录添加文件上下文规则 semanage fcontext -a -t httpd_sys_content_t "/data/webroot(/.*)?" # 按规则恢复目录的上下文标签 restorecon -Rv /data/webroot

semanage fcontext -a是把规则写入文件上下文数据库，它本身不改文件标签；真正生效靠restorecon，-R递归、-v显示变更内容。这一点初学者最容易搞混：光加规则不执行 restorecon，文件还是旧标签。

临时验证可以用chcon -t httpd_sys_content_t /data/webroot，但它只改当前标签，不写数据库，一旦执行restorecon会被还原。表格对比一下两种命令：

整套流程走下来，刚好覆盖了端口类型、布尔值、文件上下文这三个 SELinux 策略配置的核心操作面，和实验文档的目录结构是逐节对应的。

4. 避坑排查：六条值得写进笔记的 SELinux 配置踩坑记录

4.1 setsebool 没加 -P，重启后配置全丢

现象：实验里打开了httpd_can_network_connect，服务当时恢复正常，重启后再次访问失败，getsebool -a | grep httpd_can_network_connect显示回 0。

原因：setsebool不带-P只修改运行时策略内存里的值，重启后从磁盘策略重新加载，修改全部丢失。

解决：需要持久化就用setsebool -P。如果已经做了一半实验才发现，直接重跑setsebool -P httpd_can_network_connect 1，再用reboot验证。

4.2 audit.log 里查不到 AVC 记录的三种可能

现象：服务端口绑不上，但进/var/log/audit/audit.log去 grep denied 却一条都没有，排查直接卡住。

原因：通常是三类情况——第一，策略里有dontaudit规则，某些常见拒绝被主动抑制不进日志；第二，auditd 服务没跑，或/var/log/audit不存在；第三，当前是 Permissive 模式且日志级别配置不当。

解决：先用systemctl status auditd确认审计服务在跑；再压制 dontaudit 规则用semodule -D（实验结束记得semodule -B重建）；实在不行，把 SELinux 临时切到 Permissive 复现一次，然后看/var/log/messages里的setroubleshoot提示。

4.3 端口类型加到了 http_cache_port_t，服务照样起不来

现象：semanage port -l里明明看到了 8090，但systemctl start httpd还是报 bind 失败。

原因：加端口时类型写成了http_cache_port_t。SELinux 策略里 httpd 域允许绑定的类型是http_port_t，http_cache_port_t是给 squid 这类缓存服务用的，类型不匹配等于没加。

解决：清理错误配置再重加。semanage port -d -t http_cache_port_t -p tcp 8090，然后重新semanage port -a -t http_port_t -p tcp 8090，执行完再核对一次类型。

4.4 restorecon 没加 -F，旧文件标签始终不变

现象：给/data/webroot加了semanage fcontext规则并执行restorecon -Rv，但ls -Z看子目录下文件还是default_t。

原因：restorecon默认只把不符合数据库规则的标签改过来，但一些通过复制得到的文件继承了来源目录的上下文，如果不加-F强制重置，restorecon 认为"标签和来源一致"就不动它。

解决：用restorecon -RFv /data/webroot强制递归重置。-F是强制恢复、-R递归、-v输出变更。执行后再ls -Z验证。

4.5 实验做了一半想重来，没有快照只能手工逆向

现象：实验中途配置改乱了，想回到最开始的环境，结果发现semanage port -l里一堆测试端口，布尔值也被改了一堆。

原因：没在实验前拍虚拟机快照。SELinux 的持久化配置散落在端口映射、布尔值、文件上下文数据库和策略模块里，手工逆向很容易漏。

解决：实验开始前拍干净快照；实验结束按"反向操作"清理：semanage port -d移除测试端口、setsebool -P还原布尔值、semanage fcontext -d删除自定义规则；最后一个兜底是快照恢复。

4.6 Ubuntu 系统上照抄命令全线报错

现象：在 Ubuntu 上执行semanage、restorecon，终端提示command not found或者根本没有 SELinux 相关目录。

原因：Ubuntu 桌面版默认强制访问控制用的是 AppArmor，不是 SELinux；服务器版即使有 SELinux 支持，默认也是 disabled 状态，且工具链不完整。

解决：先getenforce确认模式；如果是 AppArmor 系统，就按 AppArmor 的aa-status和aa-complain思路走，或者在一台 RHEL/CentOS/Rocky Linux 虚拟机里重做实验——课程文档一般也都是基于 Red Hat 系环境写的。

5. 验证与进阶：用 audit2allow 把实验收尾收扎实

5.1 让 audit2allow 生成自定义策略模块

做完整套实验后，我习惯把日志里被拒绝的动作收集起来，用audit2allow生成策略模块。这能反向验证你对策略的理解是否正确——如果你对 S

本文还有配套的精品资源，点击获取