如果 matchpathcon 检查目录的 SELinux 上下文，那么该服务的反向检查是什么？

Question

Fedora 文档中的一个页面描述了一个 SELinux 上下文问题，示例如下：

“...而不是使用 /var/www/html/ 作为网站，管理员想要使用 /srv/myweb/。... [但是] SELinux 阻止 Apache HTTP 服务器 (httpd) 访问 [错误标记的文件和目录]”

任何使用 SELinux 的人都知道，SELinux 对错误消息没有帮助。发现正确上下文的一种方法是使用matchpathcon（从页面下方）

matchpathcon 命令检查文件路径的上下文并将其与该路径的默认标签进行比较。以下示例演示在包含错误标记文件的目录上使用 matchpathcon：

$ /usr/sbin/matchpathcon -V /var/www/html/*

/**EDIT：根据要求，使用 httpd 的示例上下文matchpathcon，将公共 www 目录内容的用户、角色和类型报告为：

[root@mrwizard ~]# /usr/sbin/matchpathcon /var/www/html/*
/var/www/html/info.php  system_u:object_r:httpd_sys_content_t:s0

如果——这只是一个说明，而不是正确使用这个命令——你对 httpd 的二进制文件执行相同的命令，你会发现类型不是 httpd 内容类型，而是 httpd 执行类型，我猜，SysV（在CentOS6上）用来启动httpd：

[root@mrwizard ~]# /usr/sbin/matchpathcon /usr/sbin/httpd /usr/sbin/httpd system_u:object_r:httpd_exec_t:s0

的matchpathcon输出是不对称的; 它无助于管理员对 SELinux 用户、角色和类型进行故障排除，并将服务作为输入以获取 SELinux 默认上下文作为输出。**/

如果 matchpathcon 检查正确配置目录的 SELinux 上下文，那么在服务上使用的相反过程是什么？换句话说，是否有反向检查/usr/sbin/httpd？

---

我问这个是出于谨慎。当服务器正在工作但现在坏了时，这一步似乎很有用。但是，如果您正在安装系统并决定在安装早期将某些内容放在错误的位置，那么正确的 SELinux 上下文目录可能不存在。对？那么除了服务之外，你会检查什么来发现正确的 SELinux 上下文？

Answer 1

我将使用该passwd程序来解释很多这些。

在 DAC（标准 unix 访问控制模型）的上下文中明确回答这个问题：

你如何从文件中找出我最终可能会在其中运行二进制文件的主题？

答案是您运行ls -l /bin/passwd，检查是否设置了 setuid 位。如果是，您将以文件所有者的身份运行该程序，否则，您将以您自己的用户身份运行该程序。

在 SELinux 的上下文中明确回答这个问题：

你如何从文件中找出我最终可能会在其中运行二进制文件的主题？

那么，它不是那么简单，因为它取决于谁你是当您尝试运行的二进制！幸运的是，该sesearch实用程序对于检查在这种情况下可能是什么策略非常方便。我们可以要求它告诉我们运行标记为 的对象时可能发生的所有转换是什么httpd_exec_t。

哪个产量

$ sesearch -T -c process -t httpd_exec_t
Found 14 semantic te rules:
    type_transition system_cronjob_t httpd_exec_t : process httpd_t; 
    type_transition crond_t httpd_exec_t : process httpd_t; 
    type_transition certwatch_t httpd_exec_t : process httpd_t; 
    type_transition initrc_t httpd_exec_t : process httpd_t; 
    type_transition dirsrvadmin_t httpd_exec_t : process httpd_t; 
    type_transition kdumpctl_t httpd_exec_t : process httpd_t; 
    type_transition cluster_t httpd_exec_t : process httpd_t; 
    type_transition logrotate_t httpd_exec_t : process httpd_t; 
    type_transition condor_startd_t httpd_exec_t : process httpd_t; 
    type_transition cobblerd_t httpd_exec_t : process httpd_t; 
    type_transition openshift_initrc_t httpd_exec_t : process httpd_t; 
    type_transition piranha_pulse_t httpd_exec_t : process httpd_t; 
    type_transition init_t httpd_exec_t : process httpd_t; 
    type_transition svc_run_t httpd_exec_t : process httpd_t;

所以事实证明，在你的情况下，实际上有一大堆不同的主题可以做到这一点，它们最终都在 httpd_t 域中。

不过现在总是这样：-

$ sesearch -T -c process -t ssh_exec_t
Found 8 semantic te rules:
   type_transition virsh_t ssh_exec_t : process virsh_ssh_t; 
   type_transition sge_job_t ssh_exec_t : process sge_job_ssh_t; 
   type_transition ajaxterm_t ssh_exec_t : process ajaxterm_ssh_t; 
   type_transition nx_server_t ssh_exec_t : process nx_server_ssh_t; 
   type_transition sysadm_t ssh_exec_t : process ssh_t; 
   type_transition staff_t ssh_exec_t : process ssh_t; 
   type_transition condor_startd_t ssh_exec_t : process condor_startd_ssh_t; 
   type_transition user_t ssh_exec_t : process ssh_t; 

此可执行文件为不同的主题执行不同的转换。因为我们知道virsh_t应该只在 SSH 中做一组非常具体的事情，所以它会进入virsh_ssh_t一个过渡阶段，这比过渡到ssh_t.

我在下面的转换主题上添加了很长的答案，以便人们了解 SELinux 试图解决的问题以及它如何尝试解决这些问题。

在 DAC (Unix) 和 MAC/TE (SELinux) 中的用户之间移动

让我们定义一些术语以使其有意义。

• 主题：操作系统中项目的参与者。这通常是用户或进程。
• 对象：正在对其执行操作的项目。可以是很多东西（文件、目录、端口）
• 转换：从一个主题转换到另一个主题的行为。

在我们回答如何在 SELinux 类型强制中执行此操作之前，请考虑如何在 DAC（自由访问控制；标准 UNIX 安全模型）中执行此操作。

这是如何在 Unix 安全模型中工作的

在 DAC 中，主体主要是 UID，但 GID 和补充 GID 也定义了主体。对象是文件、目录、unix 套接字，并且主要由它们的路径引用（尽管存在一些例外，例如 IPC 共享内存）。

通常，当你运行一个程序时 - 没有过渡。用户jim想要运行/bin/cat. 当他这样做时，进程被实例化并继承主题jim以及他的主题的任何其他属性（GID、补充组等）。

但是，有一些程序在运行时会进行转换。当用户jim运行passwd命令时，jim 转换为root，这当然是对影子文件进行更改所必需的。

这种自动转换行为是通过翻转文件系统权限中的 SUID 位来控制的，它通过将磁盘上的可执行文件的所有者设置为您想要转换到的目标主体来定义您转换到的对象。

因此，为了清楚起见，passwd示例中jim变为root因为权限模式是 4755 而所有者是root.

因此，setuid 在标准的 unix 访问控制模型中执行转换。

不幸的是，setuid 程序有着可怕的安全问题历史。这是由于 DAC 安全模型在评估转换的方式方面存在局限性。

setuid 转换过程不检查调用程序的主体（用户）。双方jim并betty会过渡到root沿apache，mysql而nobody如果他们调用passwd。

这是不可能的（而不必自己检查程序，我们都知道如何可靠的已）使它这样，当jim呼叫passwd他转换到root，但如果betty调用passwd中它不转变root。您唯一能做的就是完全拒绝首先使用 POSIX ACL 进行betty调用passwd，但这不是细粒度的。

也不可能（没有应用程序执行此操作并具有执行此操作的权限）让文件的所有者成为您想要转换的人以外的其他人。所以betty不能运行passwd并成为用户bin而不是root.

这在 SELinux 安全模型中是如何工作的

selinux 中的主题由用户或进程正在运行的标签类型引用。这可能是user_t，unconfined_t或者httpd_t例如。

对象是文件、目录、套接字等，就像在 DAC 中一样，也可以通过它们的类型来引用，也有标签。httpd_exec_t，user_home_t并且mysql_port_t是 SELinux 使用的不同对象标签的示例。

在正常情况下，就像在 DAC 中一样，不会发生转换。如果user_t执行/bin/cat（或 SELinux 看到的方式，如果user_t执行bin_t对象），它会被实例化并user_t从调用者那里继承主题。

但是，某些程序会在调用时进行转换。如果user_t执行标记的对象passwd_exec_t（这/bin/passwd并不奇怪），他将转换为passwd_t.

这是在类型转换规则中定义的，在策略中如下所示：

type_transition user_t passwd_exec_t:process passwd_t;

在 SELinux 中，要发生转换，会发生以下评估。

• 谁是想要转换的主题（user_t）？
• 正在引用哪个对象 (passwd_exec_t)？
• 旧科目想成为什么新科目（passwd_t）？

因为我们在允许之前考虑了谁在执行请求，所以我们可以对谁来做什么做出更明智的决定。

• httpd_t永远不会成为passwd_t并且随后永远无法访问影子文件。
• 我们可以guest_t在 SELinux 中给贝蒂一个主题，而她也永远无法成为passwd_t.

事实上，评估的还不止这些。在我们允许过渡之前，还会提出更多问题。

1. 主体是否处于包含要转换的目标的角色中？
2. 是否允许主体passwd_exec_t以转换意图实际执行文件？
3. 是否允许任何人都可以passwd_t通过执行标记为 的文件对象来转换passwd_exec_t？
4. 我们甚至应该自动执行此操作user_t还是应该user_t明确要求转换？

SELinux的过渡模式是这样强，可以更好的评估，远远超过了DAC模型更精细。

SELinux 的大部分功能都体现在您拥有的强大的转换模型中。因为您可以非常具体地确定谁成为谁的条件——然后您可以根据主题的功能可能使您正在转换的任何内容具有非常具体的权限。

所以，要回答你最初的问题——答案是这取决于你想做什么以及你想做什么。