我有一个使用谷歌身份验证器的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文件路径上下文不与正则表达式一起使用所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)