☰

Selinux‘var_t’基类型警告

tag-icon • tag-icon nginx centos httpd selinux uwsgi
Selinux‘var_t’基类型警告

我目前在 CentOS Selinux 森林中“迷失”了。

我的设置涉及设置 WSGI 套接字，/var/www/demo/outnginx 使用该套接字与 UWSGI 进程进行通信。每当我在浏览器中请求页面时，都会收到 nginx 错误。

这和 Selinux 为何相关？

  • 禁用 Selinux 即可setenforce 0修复该问题。
  • /var/log/audit/audit.log 和 audit2why 显示denied和missing type enforcement (TE) allow rule

我已尝试将httpd_sys_content_t标签添加到套接字，以便允许 nginx 读取和写入套接字文件，并在添加新标签后恢复。

运行违规操作将audit2allow返回以下策略：

module nginx 1.0;

require {
        type httpd_t;
        type var_t;
        type httpd_sys_content_t;
        class sock_file write;
}

#============= httpd_t ==============
allow httpd_t httpd_sys_content_t:sock_file write;

#!!!! WARNING: 'var_t' is a base type.
allow httpd_t var_t:sock_file write;

我理解第一条规则，但是第二条规则传达了什么？我猜是因为 nginx 进程正在请求一个包含新上下文的 tcontext，var_t所以需要包含此新上下文的新 selinux 策略？

那么为什么会出现这个警告？是不是在抱怨将 var 这样的目录添加到策略中太笼统/不够具体？如果是这样，这个策略不能缩小到类似这样的范围吗var_www_t？此外，如果是这样，那么为什么允许在非 root 用户下运行的 uwsgi 进程写入套接字？

答案1

考虑将您的套接字放置在 SELinux 已经预期的位置。

# semanage fcontext -l | grep httpd_var_run_t | grep wsgi
/var/run/wsgi.*                                    socket             system_u:object_r:httpd_var_run_t:s0

因此，如果您创建/run/wsgi.anything并使用该套接字，它将完美地工作。请记住，由于这是一个在每次启动时都会清除的临时目录，因此您应该在启动时自己创建套接字，通常使用配置tmpfiles.d​。 例如：

p+ /run/wsgi.anything 0660 user group - -

答案2

出现警告是因为您可能泄露了太多信息。您允许 httpd 写入 /var 中的任何套接字，这可能不是您想要的。

除非您启用了 httpd_unified 布尔值，否则 httpd_sys_content_t 上下文仅允许对文件进行读取访问。如果您希望您的套接字可由 httpd 写入，则需要将其设置为 httpd_sys_rw_content_t

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/demo/out"
restorecon -Rv /var/www/demo/out

我相信 Michael Hampton 很快就会来纠正我

答案3

selinux 基类型是一种通用类型，当被授予时，允许访问底层系统的很大一部分。启用 selinux 访问权限var_t几乎等同于不受限制地运行进程。

从一位 selinux 开发人员的博客：

我们真正想要阻止的是域写入 BASE 类型。如果我允许受限域写入 BASE 类型（如 etc_t 或 usr_t），那么被黑客入侵的系统就可以攻击其他域，因为几乎所有其他域都需要读取一些 etc_t 或 usr_t 内容。

下的文件/var/www/已标记为httpd_sys_content_t；通过用相同标签重新标记它，您不会更改任何内容。据我记得，httpd_sys_content_t应该用于静态 HTML 文件而不是套接字。尝试用以下内容重新标记您的套接字：

semanage fcontext -a -t httpd_var_run_t </your/socket/path>
restorecon -RF </your/socket/path>

你可以阅读这里对于类似的问题。

相关内容