Ubuntu SELinux如何案例分析

Ubuntu SELinux 案例分析

前置说明与准备

• Ubuntu 默认启用的是 AppArmor，并非 SELinux；在 Ubuntu 上启用 SELinux 属于可选方案，需充分评估与测试。准备工作中建议安装审计与策略工具：auditd、setools、policycoreutils、selinux-basics、selinux-policy-default，并确认当前 SELinux 状态：sestatus、getenforce。SELinux 有三种模式：Disabled、Permissive、Enforcing，排查问题时常在 Permissive 下验证是否为 SELinux 导致。日志默认写入 /var/log/audit/audit.log，可用 ausearch/aureport 检索 AVC 拒绝事件。

案例一 启用与首次启动问题定位

• 现象：执行 getenforce 返回 Disabled，或 setenforce 1 报错；系统启动后未加载 SELinux 策略。
• 排查与修复：
  • 安装与激活：sudo apt update && sudo apt install -y selinux-basics selinux-policy-default auditd；执行 sudo selinux-activate，该命令会在 /etc/default/grub 增加内核启动参数 security=selinux，随后执行 sudo update-grub && sudo reboot。
  • 持久化模式：编辑 /etc/selinux/config，设置 SELINUX=permissive（先宽容验证，再改为 enforcing）；重启后再次检查 sestatus。
  • 首次启动无策略加载：若仍为 Disabled，说明未成功注入内核参数或策略包未就绪，回到上一步确认 grub 参数与重生成 initramfs 是否成功。
  • 验证命令：sestatus、getenforce、cat /proc/cmdline | grep security、ls -Z /etc。上述步骤可系统化完成在 Ubuntu 上的启用与验证。

案例二 Web 服务访问用户主目录被拒

• 现象：在 Enforcing 模式下，Apache/Nginx 访问 /home/ 下内容返回 403 或启动失败；ausearch -m avc -ts recent 可见 avc: denied 记录，涉及域类型如 httpd_t 与目标类型如 user_home_t。
• 排查与修复：
  • 判定是否 SELinux：临时切换 sudo setenforce 0，若恢复正常，基本可判定为 SELinux 权限问题；再切回 setenforce 1 继续修复。
  • 合规方案（推荐）：为 Web 内容设置正确的文件上下文并恢复。示例：sudo semanage fcontext -a -t httpd_sys_content_t “/var/www(/.*)?”；sudo restorecon -Rv /var/www。若确需在用户主目录提供内容，可启用布尔值（示例：sudo setsebool -P httpd_enable_homedirs 1），并确保目录标签与策略匹配。
  • 临时方案（仅测试）：sudo setenforce 0 验证问题来源，再回到策略修复，避免长期运行在宽容模式。
  • 验证命令：ausearch -m avc -ts recent | audit2why、ls -Z /var/www、getsebool httpd_enable_homedirs。该案例体现了最小权限与标签一致性的原则。

案例三 自定义服务端口绑定被拒

• 现象：自定义或第三方服务尝试绑定 非默认端口 失败；AVC 日志显示 name_bind 或 port 相关拒绝，域类型可能是 myapp_t，目标端口类型如 http_port_t 不匹配。
• 排查与修复：
  • 确认拒绝细节：ausearch -m avc -ts recent | audit2why，定位被拒的 源类型、目标类型、操作（如 name_bind） 与端口号。
  • 合规方案（推荐）：优先将服务迁移到该服务类别的默认端口范围（例如 Web 服务使用 http_port_t 范围），或调整策略以允许绑定到目标端口。示例流程：ausearch -m avc -ts recent | audit2allow -M myapp_port；sudo semodule -i myapp_port.pp。若仅需临时验证，可 setenforce 0，验证通过后务必以策略固化。
  • 验证命令：semanage port -l | grep http_port_t、ss -ltnp | grep <端口>、ausearch -m avc -ts recent。该案例展示了端口类别与策略绑定的关系及最小变更原则。

案例四 策略编写与加载的标准流程

• 场景：为自研或第三方应用（域类型假设为 myapp_t）编写最小权限策略模块，允许其读取配置目录 /opt/myapp/conf 与日志目录 /var/log/myapp。
• 标准步骤：
  • 生成模板：ausearch -m avc -ts recent | audit2allow -M myapp_policy；编辑生成的 myapp_policy.te，仅添加必需规则（如 allow myapp_t myapp_conf_t:file { read open }; allow myapp_t myapp_log_t:file { write append };）。
  • 编译与加载：checkmodule -M -m -o myapp_policy.mod myapp_policy.te；semodule_package -o myapp_policy.pp -m myapp_policy.mod；sudo semodule -i myapp_policy.pp。
  • 标签与持久化：为目录设置上下文（如 semanage fcontext -a -t myapp_conf_t “/opt/myapp/conf(/.*)?”；restorecon -Rv /opt/myapp/conf），确保文件系统标签与策略一致。
  • 验证：ausearch -m avc -ts recent | audit2why、sestatus、ls -Z /opt/myapp。该流程遵循“最小权限 + 可审计 + 可回滚”的工程实践。