我根据评论中的建议重新格式化了可读性.
我有一个使用谷歌身份验证器的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.te
policy_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.c 680 /* 681 * Check for matching specifications in reverse order,so that 682 * 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选项(这是你应该实现它的政策的实际方式),或者使用本地覆盖.
