如果matchpathcon检查目录的SELinux上下文,那么该服务的逆向检查是什么?

Fedora文档的一个页面描述了一个SELinux上下文的例子:

“…而不是使用/ var / www / html /作为网站,pipe理员希望使用/ srv / myweb / … [但是] SELinux阻止Apache HTTP Server(httpd)访问[错误标记的文件和目录]“

正如任何遇到SELinux问题的人都知道的那样,SELinux对错误信息没有帮助。 find正确的上下文的一种方法是使用matchpathcon (从下一页开始)

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

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

/ **编辑 :根据要求,使用httpd的示例上下文, matchpathcon将公共www目录内容的用户,angular色和types报告为:

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

如果– 这只是一个说明,而不是正确使用这个命令 –你在httpd的二进制文件上执行相同的命令,你会发现这个types不是httpd内容types,而是httpd执行types,我猜,SysV(在CentOS6上)用来启动httpd:

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

matchpathcon输出是不对称的; 它不会帮助pipe理员排除SELinux用户,angular色和types与服务作为input获取SELinux默认上下文作为输出。 ** /

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


我只是在谨慎的问题上提出这个问题。 看起来这一步在服务器正在工作并且现在被破坏时很有用。 但是,如果您正在安装系统,并且在安装之前做出了一些错误的决定,那么正确的SELinux上下文目录可能不存在。 对? 那么你会检查什么来发现正确的SELinux上下文,除了服务?

我将使用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; 

所以事实certificate,在你的情况下,实际上有很多不同的主题可以做到这一点,他们都在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)之间移动用户

让我们定义一些术语来说明这一点。

  • 主题:操纵系统中的项目的演员。 这通常是一个用户或进程。
  • 对象:正在执行的项目。 可以是很多东西(文件,目录,端口)
  • 过渡:从一个主体转变为另一个主体的行为。

在我们回答在SELinuxtypes执行过程中如何完成这个操作之前,请考虑一下在DAC(自由访问控制;标准的UNIX安全模型)中如何做到这一点。

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

在DAC中, 主题主要是UID,但GID和辅助GID也定义了主题。 对象是文件,目录,unix套接字,并且大多数是通过它们的path引用的(虽然有一些例外,如IPC共享内存)。

通常情况下,当你运行一个程序 – 没有转换 。 用户jim想运行/bin/cat 。 当他这样做的时候,这个过程被实例化,inheritance了jim的主题以及他的主题(GID,辅助组等)的任何其他属性。

但是,有些程序在运行时会转换。 当用户jim运行passwd命令时, jim转换到root ,这当然是修改影子文件所必需的。

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

所以为了清楚起见,在passwd例子中, jim变成root因为权限模式是4755,所有者是root

所以,setuid在标准的unix访问控制模型中执行转换。

不幸的是,setuid程序有一个可怕的安全问题的历史。 这是由于DAC安全模型在评估转换时的局限性。

setuid转换过程不会对调用程序的主体(用户)进行检查。 如果他们调用passwdjimbetty都会和apachemysql一起转换到root

这是不可能的(没有程序本身检查,我们都知道已经有多可靠了),所以当jim调用passwd他转换到root但是如果betty调用passwd不转换为root 。 唯一可以做的就是彻底否认betty从一开始就使用POSIX ACL来调用passwd ,但这并不是精细的。

这也是不可能的(没有应用程序这样做,并有权这样做),让文件的所有者是别人,而不是你想过渡到的人。 所以betty不能运行passwd ,而是成为用户bin而不是root

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

selinux中的主题由用户或进程正在运行的标签typeshttpd_t 。例如,可能是user_tunconfined_thttpd_t

对象是文件,目录,套接字等就像在DAC中,也被称为也是他们的types,也有标签。 httpd_exec_tuser_home_tmysql_port_t是SELinux使用的不同对象标签的示例。

在正常情况下,就像在DAC中一样,不会发生转换。 如果user_t执行/bin/cat (或者SELinux看到它,如果user_t执行一个bin_t对象),它将被实例化并inheritance调用者的user_t主题。

但是,有些程序会在被调用时转换。 如果user_t执行标记为passwd_exec_t的对象(不奇怪的是/bin/passwd ),则转换为passwd_t

这在策略中的types转换规则中定义如下:

 type_transition user_t passwd_exec_t:process passwd_t; 

在SELinux中,为了进行转换,会发生以下评估。

  • 谁想要过渡(user_t)?
  • 哪个对象被引用(passwd_exec_t)?
  • 旧主题想成为什么新主题(passwd_t)?

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

  • httpd_t永远不能成为passwd_t ,随后永远不能访问影子文件。
  • 我们可以在SELinux中给betty一个guest_t主题,她也永远不会成为passwd_t

事实上,这并不是所有的评估。 在我们允许过渡之前,还有更多的问题要问。

  1. 这个主题是否包含了目标的转换?
  2. 是否允许主题实际执行passwd_exec_t文件并有意转换?
  3. 是否允许任何人通过执行标记为passwd_exec_t的文件对象来转换为passwd_t
  4. 我们是否应该为user_t自动执行此操作,或者user_t是否必须明确要求转换?

SELinux转换模型比DAC模型更强大,更好的评估和更细化。

SELinux的大部分function都在强大的过渡模式中。 因为你可以非常具体地了解谁成为谁的条件 – 那么你可以根据主体的function可以做出任何你正在过渡的具有非常特定的权限。

所以,要回答你原来的问题 – 答案是取决于你想要做什么以及你想要做什么。