SELinux —使Web变得更简单

所以一切都很好,对吧? 当然可以,除非我们修改了有关NGINX从何处提供文件的任何内容。 我们将在下一节中讨论。

模拟常见的SELinux Web服务器冲突

现在,我将配置NGINX来演示您可能会遇到的Web服务器和SELinux常见问题:Web服务器将被拒绝访问Web根目录。

NGINX Web根目录的默认位置是/usr/local/nginx/html但是由于许多原因,这可能不是您的Web目录的理想位置,或者您以后可能需要添加其他Web根目录。 这意味着SELinux可能会干预并阻止Web服务器访问这些新位置。

我们可以通过将默认Web根更改为网站文件的另一个公共位置/var/www/html来轻松模拟此问题。

  #修改NGINX的默认配置 
#我们将更改Web根目录,如下面的粗体所示:$> vi /etc/nginx/conf.d/default.confserver {
听80;
server_name localhost;
#charset koi8-r;
#access_log /var/log/nginx/host.access.log main; 位置 / {
#root / usr / share / nginx / html;
根/ var / www / html;
index index.html index.htm;
}
...#重新加载NGINX配置以使我们的设置生效
$> nginx -s重新加载

我们会在新的Web根目录位置放置一个索引文件,以确保可以确保更改生效。 我们首先需要创建/var/www/html子目录,因为它们在CentOS中默认不存在。

  $> mkdir -p / var / www / html 
$> vi /var/www/html/index.html

世界,你好!



#保存文件
:wq

如果我们再次访问服务器IP,则应该看到“ hello world页面。 但是我们没有。

那么,这是怎么回事? SELinux认识到NGINX可以访问在安装过程中创建的自己的文件夹,但是NGINX现在正试图访问/var/www/html文件夹并阻止我们,这一事实引起了人们的质疑。

我们可以查看权限,但是我们会看到NGINX的原始路径/usr/share/nginx/index.html全部由root拥有,就像我们的/var/www/html/index.html路径和文件一样。 SELinux政策明确限制了NGINX对我们路径的访问。

我们可以通过查看审核日志来确认这一点, 我们将在下一部分中进行介绍。

我们也可以通过暂时禁用SELinux来确认这一点。 可是等等! 我们不是认为这是一个坏主意吗? 是的,我们做到了,但是我们可以使用许可设置来模拟禁用SELinux。 但是,重要的是要记住在测试后重新启用强制执行。

…我们可以使用许可设置来模拟禁用SELinux但是,重要的是要记住在测试后重新启用强制执行。

要将SELinux设置为许可状态,我们可以执行以下操作:

  $> setenforce 0 

如果再次刷新服务器IP网页,我们将看到403错误已消失,现在我们可以看到Hello, World! 索引页正在工作。 由于我们只是暂时停止了SELinux的执行并突然使我们的页面正常工作,因此可以合理地确定SELinux策略有问题。

现在,我们可以使用我们的审核工具来审核审核日志并创建一些自定义策略设置,这些设置将使一切正常运行。

首先,让我们将执行策略重新设置为enforcing

  $> setenforce 1 

查看审核日志

之前,我们安装了两个Linux命令行工具policscoreutils-pythonsetroubleshoot 。 我们可以使用它们来检查我们的审核日志,并在下一步中创建自定义策略来克服我们的SELinux障碍。

要查看审核日志,请导航到审核日志目录,然后运行简单的grep命令。

  $> cd / var / log / audit 
$> cat audit.log | grep失败

我们还没有真正审核日志。 我们正在寻找单词“ fail”的实例,该实例表示SELinux阻止了某些操作。 您会注意到,其中有些包含“ AVC”一词,而有些包含“ nginx”,这正是我们所追求的。

  类型= AVC消息=审核(1538439060.411:4960):AVC:对于pid = 10007 comm =“ nginx” path =“ / var / www / html / index.html” dev =“ vda1” ino = 25250737 scontext,拒绝{open} = system_u:system_r:httpd_t:s0 tcontext = unconfined_u:object_r:var_t:s0 tclass =文件 

我不会为您带来任何细节,但是此日志包含许多有价值的信息,我们的审核工具可以利用这些信息来创建允许执行此操作的策略。 接下来,让我们通过审核工具运行此操作。

要实际审核该日志,请使用命令audit2why ,它将为我们提供一些更易于理解的格式说明。

  #使用audit2why $> grep nginx /var/log/audit/audit.log |  audit2why type = AVC msg = audit(153​​8439060.411:4960):avc:为pid = 10007拒绝{打开} 
comm =“ nginx” path =“ / var / www / html / index.html” dev =“ vda1”
ino = 25250737 scontext = system_u:system_r:httpd_t:s0
tcontext = unconfined_u:object_r:var_t:s0 tclass =文件

原因是:
缺少类型强制(TE)允许规则。

您可以使用audit2allow生成可加载模块以允许此访问。

这告诉我们SELinux阻止了此操作,因为没有规则允许此类操作,并且默认情况下会阻止此类操作。 如果我们要允许该操作,则可以完全按照最后一行的说明进行操作-使用audit2allow创建可加载模块(该模块将为我们安装策略)并允许此访问。

在此之前,让我们简要讨论一下为什么我们不首先跳到audit2allow的原因。 在某些情况下,当您遇到一个简单的权限问题时,您可能会认为SELinux有问题。 适当的Linux权限管理不在本教程的讨论范围之内,但是我将向您显示与在这种情况下可能看到的类似的消息。

如果看到此消息,则可能意味着您需要检查SELinux之外的其他内容来确定问题的原因。

  #此问题存在SELinux策略时的示例输出$> grep nginx audit.log |  audit2whytype = AVC msg = audit(153​​8439136.849:4963):avc:为pid = 10007拒绝{打开} comm =“ nginx” path =“ / var / www / html / index.html” dev =“ vda1” ino = 25250737 scontext = system_u:system_r:httpd_t:s0 tcontext = unconfined_u:object_r:var_t:s0 tclass = file是由以下原因引起的: 
未知-现行政策允许
此策略与生成审核消息的策略之间可能不匹配 。 当前的内存布尔设置与永久设置之间可能不匹配

使用audit2allow创建自定义策略模块

使用audit2allow类似于我们使用audit2why的方式,实际上,我们将使用几乎相同的命令格式。 在继续运行命令之前,让我们回顾一些关键点。

每个好的服务器管理员都会定期监视他们的工作,以确保其有效,这没有什么不同。

重要的是要记住 ,您可能需要多次执行此操作,这就是为什么我提到在接下来的几天中监视服务器的原因:您的Web服务器应用程序(在这种情况下为NGINX)完全有可能采取措施,随后触发SELinux响应。

您可能需要多次执行此操作

以我的经验,一旦一切正常运行,此后可能会有几次,可能是三到四个实例,一旦最终使您的应用程序或网站正常工作,您需要在最初的尝试之后创建其他自定义策略模块。 如果您没有在/var/log/audit/audit.log看到来自NGINX的其他失败日志,那么您已经解决了冲突。

如果在/var/log/audit/audit.log中没有看到其他失败日志,那么您已经解决了冲突。

现在,我们可以继续学习使用audit2allow。 让我们先回顾一下命令语法。

  #让我们回顾一下命令语法 
grep [关键字] audit.log | audit2allow -M [政策名称]
| |
关键字是什么我们的政策名称
我们正在搜索日志。 可以是我们想要的任何东西。 #使用“ nginx”作为关键字的示例。
$> grep nginx audit.log | audit2allow -M nginxpolicy

该命令将创建两个文件,我们只需要担心其中一个,并且还将使用semodule命令通知您如何使用该文件。 让我们使用它。

  $> grep nginx audit.log |  audit2allow -M nginxpolicy 
********************重要***********************
要激活此策略包,请执行: semodule -i nginxpolicy.pp

现在,我们可以按照说的做,然后运行semodule命令来安装此SELinux策略。

  semodule -i nginxpolicy.pp 

如果您使用浏览器再次尝试测试页,则可能会发现它现在可以工作了。 如果没有,请冲洗并重复直到有工作页。

您可能希望在刷新页面时follow审核日志-这将向您显示最新日志并有助于更轻松地识别错误。 您可以使用tail执行此操作。

  $> tail -f /var/log/audit/audit.log 

现在,当您刷新页面时,最新的SELinux冲突将输出到Shell。 您可以从此错误中提取关键字以在运行audit2why时使用,并在创建策略模块时针对此问题使用audit2allow

还算不错,嗯?

在本教程中,我们仅介绍了SELinux管理的基础知识,但是,如果仅在服务器上运行Web应用程序和网站,那么这可能正是您所需要的。 如果人们要求,我将尝试更详细地介绍这一点。

我希望这可以使您使用SELinux配置服务器,以成功执行安全策略。 让我知道您在评论中的想法,如果本文对您有所帮助,或者您遇到麻烦了, 请告诉我!

有关SELinux的更多信息,请从CentOS Wiki上的书中获取它-https://wiki.centos.org/HowTos/SELinux。