A menos que você queira reescrever praticamente toda a refpolicy , não vejo utilidade para uma nova função. Observe que, depois de criá-lo, você precisará criar regras de política personalizadas para literalmente cada módulo que a função deve ser capaz de usar.
Minha ideia de dar ao usuário uma função de administrador restrita é implementada por:
- mapeando-o para
guest_u
, é um usuário do SELinux altamente confinado (e já existente). - criando regras RBAC (Role Based Access Control) associadas a regras
sudo
para permitir que pessoas específicas executem comandos específicos em máquinas específicas sob uma função e tipo específicos do SELinux. - (É claro que essa é uma versão limitada do ambiente realmente confinado. É necessário adicionar, por exemplo, uma
rbash
, umaPATH
, 2FA autenticação, autorização adequada, ...)
O ponto chave aqui é a capacidade de conceder a um usuário guest_u
sem privilégios a capacidade de executar um comando de privilégio elevado sem sair do seu mapeamento restrito de usuários do SELinux .
Verifique a% man_de% manpage para detalhes.
Cmnd_Spec ::= Runas_Spec? SELinux_Spec? Tag_Spec* Cmnd
SELinux_Spec On systems with SELinux support, sudoers entries may optionally have an SELinux role and/or type associated with a command. If a role or type is specified with the command it will override any default values specified in sudoers. A role or type specified on the command line, however, will supersede the values in sudoers.
Para verificar o suporte do SELinux em sudoers(5)
, execute:
# ldd $(which sudo) | grep selinux
No RHEL, sudo
tem suporte a SELinux ativado por padrão.