Usuários, papéis e RBAC no Solaris: por que o root é um papel por padrão e como o pfexec substitui o sudo

O que é

O Oracle Solaris implementa a administração privilegiada por meio do Role-Based Access Control (RBAC): perfis de direitos reúnem privilégios e autorizações e são atribuídos diretamente a um usuário ou a um papel (role) que o usuário precisa assumir explicitamente. Por padrão no Solaris 11.4, o próprio root é configurado como papel, e não como usuário com login direto: o administrador entra com seu próprio usuário nominal e, para as tarefas privilegiadas, assume o papel root, em vez de entrar como root ou trocar para uma conta compartilhada e anônima com su.

Por que importa

Como o root é um papel, toda ação privilegiada pode ser atribuída ao usuário nominal que o assumiu. Esse é o objetivo do projeto: uma trilha de auditoria melhor do que a de uma senha de root compartilhada. O sudo não é o mecanismo nativo aqui: as ferramentas próprias do Solaris (pfexec, papéis, su para um papel) são anteriores a ele e o substituem. O Solaris 11.4 inclui o sudo (pacote security/sudo) e, em muitas instalações, ele está presente, com o usuário inicial criado pelo instalador recebendo direitos em /etc/sudoers.d/. Mas a presença do pacote e o que o usuário pode executar variam de host para host, por isso não se pode presumir que estejam disponíveis.

Como aplicar

• Para tarefas administrativas compartilhadas, crie um papel em vez de um login normal: roleadd -c "description" -P "<profile>" <rolename>, defina a senha dele com passwd <rolename> e atribua-o com usermod -R +<rolename> <user> (-R <rolename> sem + substitui toda a lista de papéis do usuário). Um papel não pode fazer login diretamente; roles <user> e profiles <user> listam o que um usuário possui.
• Para executar um único comando privilegiado sem abrir um shell persistente de papel, use pfexec <command>. O pfexec ativa o flag de processo do profile shell e executa o comando apenas com os direitos dos perfis atribuídos ao próprio usuário que o chamou, e não com os de algum papel que ele possa assumir. Para comandos em um perfil de direitos autenticado, a senha do usuário é solicitada antes.
• Antes de presumir o padrão, verifique se root é atualmente um papel ou um usuário no host em questão: userattr type root imprime role para um papel e nada ou normal para um usuário. O Solaris permite ao administrador alternar nos dois sentidos com usermod -K type=role root (transformar em papel) ou rolemod -K type=normal root (voltar a ser um usuário com login direto). Antes de transformar o root em papel, atribua o papel a pelo menos um usuário nominal (usermod -R +root <user>) e teste su root a partir dessa conta em uma segunda sessão; caso contrário, ninguém conseguirá se tornar root pela rede.
• Para scripts não supervisionados, atribua um perfil de direitos de escopo restrito à conta sob a qual o script roda e chame os comandos privilegiados por meio do pfexec. Um papel exige su e a respectiva senha, o que não serve para uso sem supervisão.

Armadilhas

• Presumir que um host Solaris 11.4 tem o sudo disponível e configurado para você. Verifique com command -v sudo e sudo -n -l antes de escrever automação que o chame.
• Esperar que o pfexec use os direitos de um papel: um usuário que recebeu o papel root, mas nenhum perfil adequado, não ganha nada extra com o pfexec. Ele precisa assumir o papel com su root (ou su <rolename>), que é uma etapa separada e auditada.