我正在 Alma Linux 9.2 上试验和学习 SELinux。目的是构建一个具有文件包含漏洞的 flask 应用程序,并展示 SELinux 如何防止该漏洞以保护某些文件,即使 flask 应用程序受到攻击,这些文件也不应该被攻击者访问。为了测试这一点,我在用户的主目录中创建了一个文本文件,并尝试通过 flask 应用程序访问它,并且 SELinux 强制执行。SELinux 阻止了它。到目前为止一切顺利。然后我尝试/etc/passwd
通过 flask 应用程序读取该文件,它允许了。我不确定为什么!我认为这足够敏感,SELinux 可以阻止对它的未经授权的访问。以下是两个文件的/etc/passwd
输出。ls -Z
system_u:object_r:passwd_file_t:s0 /etc/passwd
unconfined_u:object_r:user_home_t:s0 /home/vagrant/test.txt
我不确定这是否是预期的行为。
答案1
重复我最初的评论:
- 一般而言,这些
/etc/passwd
信息并不敏感。例如,应用程序需要这些信息来查找 UID 号码并显示人性化的用户名。
第二个考虑:
- 除非您为自定义应用程序/守护程序创建自定义 SELinux 上下文,否则它将不会以任何特定的保护/限制运行。(并且实际上只有常规文件系统权限才会拒绝访问。)
-Z
您可以使用 中的选项检查正在运行的守护进程的当前 SELinux 上下文ps
。您看到的内容将取决于您如何启动守护进程,但对于例子:
ps -efZ | grep mydaemon
system_u:system_r:unconfined_service_t:s0 root 4117 1 0 16:56 ? 00:00:00 /usr/local/bin/mydaemon
显示unconfined_service_t
,这意味着:没有限制,没有 SELinux 策略。
这Red Hat SELinux 手册简要介绍了如何创建此类自定义 SELinux 策略:
- 生成自定义策略:
sepolicy generate --init /usr/local/bin/mydaemon
- 使用安装脚本用新的策略模块重建系统策略:
cd /home/example.user/mysepol ; ./mydaemon.sh
- 使用 restorecon 命令重新标记文件系统的相应部分:
restorecon -v /usr/local/bin/mydaemon /usr/lib/systemd/system
- 重新启动守护进程,并检查它现在是否受 SELinux 限制运行
- 现在您应该会看到 SELinux 拒绝/错误。