我正在使用freeIPA来定义RBAC，HBAC和sudo规则，以及一百个虚拟机的域的SELinux用户映射，我需要为几个团队授予不同级别的访问权限（开发人员，数据库pipe理员，系统pipe理员，pipe理……）。

目前，这些机器上的SELinux策略被设置为targeted ，我正在考虑删除unconfined_u SELinux用户以使这些系统在strict策略下运行的可能性。

为了做到这一点，其中一个要求是让最终用户了解他/她已经从unconfined_u降级到staff_u 。 问题在于sudo与SELinux用户映射的交互方式。 一些事实：

1. 如果你想使用一个受限制的SELinux用户，并且你还想使用sudo ，那么你需要使用staff_u ，因为这是可以访问SETUID可执行文件的SELinux用户。

   • 谷歌authentication与OpenLDAP或Fedora 389服务器或FreeIPA
   • 备份和恢复Freeipa基础设施
   • 无法更改FreeIPApipe理员的密码 – “当前密码的最短使用期限未到期”
   • 将Synology NASconfiguration为freeIPA客户端
   • 使用FreeIPA进行中央sudo – 使用SSSD做sudoers

2. 当用户login系统时，他/她被分配一个SELinux用户映射。 即使在SELinux用户可以运行su （ unconfined_u ）或sudo （ unconfined_u ， staff_u ）的情况下，映射也不会改变。

3. 用于sudo的SELinux Spec目前包含用于以定义的types和roles运行命令的工具，但是缺less指定user的可能性。 进一步的参考可以在这里find。

4. 参与这个部署的机器都是freeIPA客户端，他们的sudo策略是由freeIPApipe理的，但是他们也有一个puppetpipe理的，定制的/etc/sudoers文件，在freeIPA失败的情况下作为备用文件提供。

我第一次尝试解决这个问题涉及到一个包含所需规则的策略模块，以允许staff_u访问未修改的sudorules 。 这种方法已被certificate是错误的，因为政策可以无限制地增长，最终你所做的是在政策上打出一个漏洞。

所以到目前为止，我处理这些事实的方式是重写sudorules以显式地包含对runcon的调用以切换到相应的SELinux用户，因此现在需要运行一个典型的开发人员，例如：

 $ sudo -u jboss runcon -u sysadm_u jboss_cli.sh 

这有一个缺点，就是不得不修改所有现有的sudorules并迫使用户改变通常运行的东西的方式。 所以问题是：

• 有一种方法可以在Runas_Spec定义中明确定义SELinux用户吗？
• 如果不能通过sudoers ，是否可以定义或绑定一个sudorule到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 

时间 - > 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

因为我在Defaults使用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 

时间 - > 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

最终编辑

我终于采取了一个中期解决scheme。 我已经configuration我的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 

 %wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r NOPASSWD: ALL, ! /bin/su