Conceder acesso sudo a um usuário confinado do SELinux no freeIPA

4

Estou usando o freeIPA para definir as regras de RBAC, HBAC e sudo , bem como os mapeamentos de usuários do SELinux para um domínio de um centenas de máquinas virtuais, onde preciso conceder diferentes níveis de acesso a várias equipes (desenvolvedores, administradores de banco de dados, administradores de sistema, gerenciamento, etc.).

Atualmente, a política do SELinux nessas máquinas está definida como targeted , e estou pensando na possibilidade de excluir o usuário unconfined_u SELinux para que esses sistemas sejam executados sob uma política strict .

Para fazer isso, um dos requisitos é tornar transparente para o usuário final o fato de que ele foi "rebaixado" de unconfined_u para staff_u . O problema reside na maneira como sudo interage com os mapeamentos de usuários do SELinux. Alguns fatos:

  1. se você quiser usar um usuário do SELinux confinado e quiser continuar usando sudo , você precisa usar staff_u , já que este é o usuário do SELinux com acesso a executáveis SETUID .

  2. quando um usuário efetua login em um sistema, ele recebe um mapeamento de usuário do SELinux. Esse mapeamento não é alterado mesmo que o usuário do SELinux possa executar su ( unconfined_u ) ou sudo ( unconfined_u , staff_u ).

  3. o SELinux Spec para sudo atualmente contém recursos para executar comandos em types e roles definidos, mas não tem a possibilidade de especificar o user também. Mais referências podem ser encontradas aqui .

  4. as máquinas envolvidas nessa implantação são todas clientes freeIPA e suas políticas sudo são gerenciadas pelo freeIPA, mas elas também têm um puppet managed, /etc/sudoers customizado, fornecido como um fallback em caso de uma falha no freeIPA.

Minha primeira tentativa de resolver esse problema envolveu a inclusão de um módulo de política contendo as regras necessárias para permitir staff_u de acesso ao sudorules não modificado. Essa abordagem provou estar errada, porque a política pode crescer indefinidamente e, finalmente, o que você está fazendo está abrindo um buraco na política.

Portanto, a maneira como eu lidei com esses fatos até agora foi reescrever o sudorules para explicitamente conter uma chamada para runcon para alternar para o usuário do SELinux apropriado, portanto, um desenvolvedor típico precisa ser executado, por exemplo :

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

Isso tem a desvantagem de ter que modificar todo o sudorules existente e forçar o usuário a mudar a maneira como o material geralmente é executado. Então as perguntas são:

  • existe uma maneira de definir explicitamente o usuário do SELinux em uma definição Runas_Spec ?
  • se não for possível por meio de sudoers , é possível definir ou vincular um sudorule a um mapeamento de usuário do SELinux no freeIPA?

Considere este cenário:

# 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

Se eu tentar:

$ 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

Porque estou usando log_output em Defaults e:

# ll -dZ /var/log/sudo-io
drwx------. root root system_u:object_r:var_log_t:s0   /var/log/sudo-io/

Tentar "corrigir" essa negação de AVC resultará no módulo de política infinita mencionado acima, porque permite:

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 };

é um problema espúrio, como mostrado ao ativar essas permissões:

$ 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

EDIÇÃO FINAL

Eu finalmente adotei uma solução de médio prazo. Eu configurei meu servidor IPA da seguinte forma:

$ 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

e eu defini alguns mapeamentos de usuários do SELinux similares a este que ligam alguns RBACs a um usuário do 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
----------------------------

As minhas regras de sudo parecem agora:

  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

Este não é o meu objetivo final, pois eu queria eliminar completamente o unconfined_u , mas é um bom passo à frente, já que aumenta um pouco a segurança geral. Obviamente, a resposta de Mateus está correta, pois staff_u deve poder fazer a transição para um domínio privilegiado superior via sudo options; mas ainda há o problema de system_u não estar completamente equipado para substituir unconfined_u . Talvez porque não tenha a intenção de fazê-lo.

    
por dawud 10.09.2013 / 23:02

1 resposta

3

Você está ciente de que pode passar para a função sysadm_r como staff_u , certo?

Por exemplo, o seguinte abaixo funcionaria.

myuser  ALL=(ALL)   TYPE=sysadm_t ROLE=sysadm_r PASSWD: ALL

Isso permitirá que você faça (quase) o que você pode fazer como root como não confinado.

Ah e uma dica final. Usar su é um pouco complicado com o RBAC (ele faz um monte de coisas que o colocam em todos os lugares). Em vez disso, você pode usar o comando runuser , que faz a mesma coisa sem muitos su de overheads.

Na verdade, eu restringi su use em sudoers assim;

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

Porque, por padrão, a política do SELinux não permite que a transição sudo gerencie os sinais necessários. Realmente as pessoas provavelmente deveriam usar o sudo -i de qualquer maneira.

Normalmente, insiro runuser a ru como uma substituição de duas letras para pessoas que preferem executar sudo su - de um mau hábito (como eu!).

    
por 10.09.2013 / 23:56