目前,这些机器上的SELinux策略设置为目标,我正在考虑删除unconfined_u SELinux用户的可能性,以使这些系统在严格的策略下运行.
为了做到这一点,其中一个要求是向最终用户透明他/她已从unconfined_u“降级”到staff_u的事实.问题在于sudo与SELinux用户映射互操作的方式.一些事实：
>如果你想使用一个受限的SELinux用户并且你仍然想要使用sudo,你需要使用staff_u,因为这是SELinux用户with access to SETUID executables.
>当用户登录系统时,他/她被分配了SELinux用户映射.即使在SELinux用户可以运行su(unconfined_u)或sudo(unconfined_u,staff_u)的情况下,该映射也不会改变.
> suin的SELinux规范目前包含以定义的类型和角色运行命令的工具,但也缺乏指定用户的可能性.可以在here找到进一步的参考.
>此部署中涉及的计算机都是freeIPA客户端,它们的sudo策略由freeIPA管理,但它们也有一个puppet托管,自定义/ etc / sudoers文件,作为freeIPA故障时的后备提供.
我第一次尝试解决这个问题涉及到一个包含所需规则的策略模块,以允许staff_u访问未修改的sudorule.这种方法被证明是错误的,因为政策可以无限增长,最后你正在做的是在政策上打一个漏洞.
因此,到目前为止我处理这些事实的方式是重写sudorules以显式包含对runcon的调用以切换到适当的SELinux用户,因此典型的开发人员现在需要运行,例如：
$sudo -u jboss runcon -u sysadm_u jboss_cli.sh
这具有必须修改所有现有的sudorule并迫使用户改变通常运行的东西的方式的缺点.所以问题是：
>有没有办法在Runas_Spec定义中显式定义SELinux用户？
>如果不能通过sudoers,是否可以在freeIPA中定义或绑定一个sudorule到SELinux用户映射？
考虑这种情况：
# ipa sudorule-show services_4_operators_3 Rule name: services_4_operators_3 Description: Operator Level 3 access to service management commands Enabled: TRUE User Groups: operators_3 Host Groups: all-hosts Sudo Allow Command Groups: services Sudo Option: type=sysadm_t,role=sysadm_r # ipa sudocmdgroup-show services Sudo Command Group: services Description: commands for services and daemons management Member Sudo commands: /sbin/service,/sbin/chkconfig
如果我尝试：
$sudo service sshd status sudo: unable to open /var/log/sudo-io/seq: Permission denied
time->Wed Sep 11 09:57:30 2013
type=PATH msg=audit(1378886250.584:46644668): item=0 name="/var/log/sudo-io/seq" inode=154 dev=fd:0c mode=0100600 ouid=0 ogid=1168000009 rdev=00:00 obj=unconfined_u:object_r:var_log_t:s0
type=CWD msg=audit(1378886250.584:46644668): cwd="/home/some_user"
type=SYSCALL msg=audit(1378886250.584:46644668): arch=c000003e syscall=2 success=no exit=-13 a0=7fff2e7ab970 a1=42 a2=180 a3=0 items=1 ppid=2374 pid=2442 auid=1168000009 uid=1168000009 gid=1168000009 euid=0 suid=0 fsuid=0 egid=1168000009 sgid=1168000009 fsgid=1168000009 tty=pts0 ses=6459 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 key="access"
type=AVC msg=audit(1378886250.584:46644668): avc: denied { read write } for pid=2442 comm="sudo" name="seq" dev=dm-12 ino=154 scontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file
因为我在默认值中使用log_output并且：
# ll -dZ /var/log/sudo-io drwx------. root root system_u:object_r:var_log_t:s0 /var/log/sudo-io/
试图“修复”此AVC拒绝将导致上述无限策略模块,因为允许：
allow staff_sudo_t var_log_t:file { open read write lock create };
allow staff_sudo_t var_log_t:dir { write add_name create search };
是一个虚假的问题,如启用此类权限时所示：
$sudo service sshd status env: /etc/init.d/sshd: Permission denied
time->Wed Sep 11 11:00:53 2013
type=PATH msg=audit(1378890053.185:46646934): item=0 name="/etc/init.d/sshd" inode=5490 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:sshd_initrc_exec_t:s0
type=CWD msg=audit(1378890053.185:46646934): cwd="/"
type=SYSCALL msg=audit(1378890053.185:46646934): arch=c000003e syscall=59 success=no exit=-13 a0=7fffc0829862 a1=7fffc0829578 a2=607030 a3=ffffe000 items=1 ppid=6715 pid=6720 auid=1168000009 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=6459 comm="env" exe="/bin/env" subj=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1378890053.185:46646934): avc: denied { execute } for pid=6720 comm="env" name="sshd" dev=dm-1 ino=5490 scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sshd_initrc_exec_t:s0 tclass=file
最终编辑
我终于采用了中期解决方案.我已按如下方式配置我的IPA服务器：
$sudo -u dsastrem ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/rbash Default users group: ipausers Default e-mail domain: company.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=COMPANY.COM Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: guest_u:s0 Default PAC types: MS-PAC
我已经定义了一些SELinux用户映射,类似于将一些RBAC绑定到SELinux用户(staff_u)的用户映射.
$sudo -u dsastrem ipa selinuxusermap-find --------------------------- X SELinux User Maps matched --------------------------- .... Rule name: semap_operators_3_mad SELinux User: staff_u:s0-s0:c0.c1023 HBAC Rule: operators_3_access Description: SELinux user mapping for MAD level 3 operators Enabled: TRUE .... ---------------------------- Number of entries returned X ----------------------------
我的sudo规则现在看起来像这样：
Rule name: services_4_operators_3 Description: Operator Level 3 access to service management commands Enabled: TRUE User Groups: operators_3 Host Groups: all-hosts Sudo Allow Command Groups: services Sudo Option: role=unconfined_r
这不是我的最终目标,因为我想完全消除unconfined_u,但这是一个很好的进步,因为它增强了整体安全性.当然,Matthew的回答是正确的,因为staff_u应该能够通过sudo选项转换到更高权限的域;但是仍然存在system_u没有完全配备替换unconfined_u的问题.也许是因为它不打算这样做.
解决方法
例如,以下内容可行.
myuser ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r PASSWD: ALL
这将允许您(几乎)以root身份执行无限制的操作.
哦,最后一个提示.使用su对于RBAC来说有点棘手(它有很多东西可以进入各种各样的地方).相反,您可以使用runuser命令执行相同的操作,而无需大量的开销.
我实际上限制su在sudoers中的使用;
%wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r NOPASSWD: ALL,! /bin/su
因为默认情况下SELinux策略不允许sudo转换来管理必要的信号.真的人们应该只使用sudo -i.
我通常将runuser与ru硬链接为两个字母的替代品,用于那些喜欢运行sudo su的人 – 出于坏习惯(像我一样！).
