SELinux文件路径上下文不与正则表达式一起使用

SELinux文件路径上下文不与正则表达式一起使用,第1张

概述我根据评论中的建议重新格式化了可读性. 我有一个使用谷歌身份验证器的RADIUS服务器,SELinux阻止RADIUS访问用户主目录中的.google_authenticator文件(这些也是winbind用户,家庭目录在/ home / API中).我试图通过构建以下策略文件来授予它访问权限: $cat ./google-authenticator.fc /home/API(/.*)?/\.g 我根据评论中的建议重新格式化了可读性.

我有一个使用谷歌身份验证器的RADIUS服务器,SELinux阻止RADIUS访问用户主目录中的.Google_authenticator文件(这些也是winbind用户,家庭目录在/ home / API中).我试图通过构建以下策略文件来授予它访问权限:

$cat ./Google-authenticator.fc /home/API(/.*)?/\.Google_authenticator      gen_context(system_u:object_r:radiusd_Google_authenticator_t,s0)$cat ./Google-authenticator.tepolicy_module(radiusd_Google_authenticator,0.0.10)require {  type radiusd_t;  type user_home_dir_t;  type admin_home_t;}type radiusd_Google_authenticator_t;role object_r types radiusd_Google_authenticator_t;allow radiusd_t radiusd_Google_authenticator_t:file { rename create unlink rw_file_perms };files_type(radiusd_Google_authenticator_t)filetrans_pattern(radiusd_t,user_home_dir_t,radiusd_Google_authenticator_t,file,".Google_authenticator")filetrans_pattern(radiusd_t,admin_home_t,".Google_authenticator")

安装它们会显示semanage fcontext -l中的路径,但它不起作用:

$sudo semanage fcontext -l | grep Google_authenticator /home/API(/.*)?/\.Google_authenticator             all files          system_u:object_r:radiusd_Google_authenticator_t:s0  $matchpathcon /home/API/tcr/.Google_authenticator /home/API/tcr/.Google_authenticator    unconfined_u:object_r:user_home_t:s0

奇怪的是,当我更改它以使路径完全匹配时(即使是转义期间),它的工作原理如下:

$sudo semanage fcontext -l | grep Google_authenticator/home/API/tcr/\.Google_authenticator               all files          system_u:object_r:radiusd_Google_authenticator_t:s0 $matchpathcon /home/API/tcr/.Google_authenticator/home/API/tcr/.Google_authenticator system_u:object_r:radiusd_Google_authenticator_t:s0

甚至更奇怪的是,正如Iain的答案中所建议的那样,正则表达式使用semanage直接添加路径而不是策略文件(首先删除策略路径以便不存在冲突):

$sudo semanage fcontext -l | grep Google_authenticator$matchpathcon /home/API/tcr/.Google_authenticator/home/API/tcr/.Google_authenticator unconfined_u:object_r:user_home_t:s0$sudo semanage fcontext -a -t radiusd_Google_authenticator_t '/home/API(/.*)?/\.Google_authenticator'$sudo semanage fcontext -l | grep Google_authenticator/home/API(/.*)?/\.Google_authenticator             all files          system_u:object_r:radiusd_Google_authenticator_t:s0 $matchpathcon /home/API/tcr/.Google_authenticator/home/API/tcr/.Google_authenticator system_u:object_r:radiusd_Google_authenticator_t:s0

我也尝试过使用HOME_DIR的各种设置,但也没有运气.

解决方法 尝试使用
HOME_DIR/\.Google_authenticator -- gen_context(system_u:object_r:radiusd_Google_authenticator_t,s0)

代替.主目录不一定在/ home中,当您重建策略时,它将充当宏.

编辑

所以我检查了源代码,它提供了以下文本,可能表明这里发生了什么.

label_file.c680     /*681      * Check for matching specifications in reverse order,so that682      * the last matching specification is used.683      */

匹配最后的正则表达式,赢. SElinux库使用以下文件查找顺序来匹配:

/etc/selinux/targeted/contexts/files/file_contexts.subs_dist/etc/selinux/targeted/contexts/files/file_contexts.subs/etc/selinux/targeted/contexts/files/file_contexts/etc/selinux/targeted/contexts/files/file_contexts.homedirs/etc/selinux/targeted/contexts/files/file_contexts.local

在您的情况下赢得的匹配正则表达式是这样的:

grep user_home_t /etc/selinux/targeted/contexts/files/file_contexts.homedirs/home/[^/]+/.+  user_u:object_r:user_home_t:s0

通过将条目添加为本地上下文,它将从此文件中获取:/etc/selinux/targeted/contexts/files/file_contexts.local,它出现在此刻匹配的文件之后.

因此,为了解决这个问题(这基本上是一个黑客攻击),您可以将条目添加为本地覆盖.

或者,我尝试将其添加为HOME_DIR覆盖(就像我最初建议的那样,但使​​用audio_home_t来测试主体)执行以下 *** 作:

HOME_DIR/(tcr)?/\.Google_authenticator          --      gen_context(system_u:object_r:audio_home_t)

这对我有用,因为它添加了后面文件的条目和’last regex won’,当我这样做时.

它实际上在文件中将正则表达式更改为:

grep tcr /etc/selinux/targeted/contexts/files/*/etc/selinux/targeted/contexts/files/file_contexts.homedirs:/home/[^/]+/(tcr)?/\.Google_authenticator   --  user_u:object_r:audio_home_t:s0

我建议首先尝试HOME_DIR选项(这是你应该实现它的政策的实际方式),或者使用本地覆盖.

总结

以上是内存溢出为你收集整理的SELinux文件路径上下文不与正则表达式一起使用全部内容,希望文章能够帮你解决SELinux文件路径上下文不与正则表达式一起使用所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/1036425.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-24
下一篇 2022-05-24

发表评论

登录后才能评论

评论列表(0条)

保存