я использую freeIPA для определения RBAC, HBAC и sudo правила, а также сопоставления пользователей SELinux для домена из пары сотен виртуальных машин, где мне нужно предоставить разные уровни доступа нескольким группам (разработчикам, администраторам баз данных, системным администраторам, руководству, ...).

В настоящее время политика SELinux на этих машинах установлена ​​на targeted, и я обдумываю возможность удаления unconfined_u Пользователь SELinux, чтобы эти системы работали под strict политика.

Для этого одним из требований является обеспечение прозрачности для конечного пользователя того факта, что он / она был «понижен» в должности. unconfined_u к staff_u. Проблема кроется в пути sudo взаимодействует с сопоставлениями пользователей SELinux. Некоторые факты:

1. если вы хотите использовать ограниченного пользователя SELinux, но при этом хотите иметь возможность использовать sudo, вам нужно использовать staff_u, поскольку это пользователь SELinux с доступом к исполняемым файлам SETUID.

2. когда пользователь входит в систему, ему / ей назначается сопоставление пользователей SELinux. Это сопоставление не меняется даже в том случае, если пользователь SELinux может запустить su (unconfined_u) или sudo (unconfined_u, staff_u).

3. в SELinux Spec для sudo в настоящее время содержит средства для запуска команд в определенных types и roles, но не имеет возможности указать user слишком. Дополнительную ссылку можно найти Вот.

4. все машины, задействованные в этом развертывании, являются клиентами freeIPA и их sudo политиками управляет freeIPA, но у них также есть puppet управляемый, индивидуальный /etc/sudoers файл, предоставляемый в качестве запасного варианта в случае сбоя freeIPA.

Моя первая попытка решить эту проблему заключалась в создании модуля политики, содержащего необходимые правила, позволяющие staff_u доступ к неизмененному sudorules. Этот подход оказался неправильным, потому что политика может расти бесконечно долго, и, в конце концов, вы пробиваете дыру в политике.

Так что до сих пор я обращался с этими фактами, переписывая sudorules явно содержать вызов runcon чтобы переключиться на соответствующего пользователя SELinux, поэтому типичному разработчику теперь необходимо запустить, например:

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

Недостатком этого является необходимость изменения всех существующих sudorules и принуждение пользователя изменить способ, которым обычно запускается. Итак, вопросы:

• есть ли способ явно определить пользователя SELinux в Runas_Spec определение?
• если невозможно через sudoers, можно ли определить или иным образом связать sudorule сопоставлению пользователей SELinux в freeIPA?

Рассмотрим этот сценарий:

# 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 в Defaults и:

# 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, но это хороший шаг вперед, поскольку он немного повышает общую безопасность. Конечно, ответ Мэтью правильный, так как staff_u должен иметь возможность перейти на домен с более высокими привилегиями через sudo параметры; но все еще есть проблема system_u не полностью оборудованы для замены unconfined_u. Может быть, потому, что это не предназначено.