Você menciona que precisa fornecer acesso aos comandos via sudo
, para que você possa fazer coisas que fazem com que sudo
exija mais intenção prejudicial de contornar as regras. Não é uma ferramenta perfeita para o trabalho, já que está tentando bloquear o acesso depois de ser dado, em vez de permitir acesso específico de uma posição de negação padrão em outras implementações do RBAC.
Eu nunca confiaria em um auditor com acesso irrestrito. Seu trabalho é tentar quebrar seu perfil de segurança e iluminar quaisquer vulnerabilidades. Quanto mais seguro você fizer o seu sistema, mais difícil será para eles, e para qualquer parte nefasta também, para escolher seus bloqueios.
Como sudo
funciona aplicando regras em ordem, comece com os comandos que eles podem executar e adicione regras que restrinjam várias opções a esses comandos.
Você pode modificar o arquivo sudoers
para usar algo como:
%auditor ALL = /usr/bin/lsattr,
/usr/bin/find,
! /usr/bin/find *-exec*,
! /usr/bin/find *-delete*
Isso permitiria ao auditor executar o find, sem permitir que ele fosse executado com -exec, -execdir ou -delete.
tom@evil:~$ sudo id
uid=0(root) gid=0(root) groups=0(root),999(lightsd)
tom@evil:~$ sudo find . -mtime -50
.
./.bashrc
./.kshrc
./.bash_history
./.bash_logout
./.profile
tom@evil:~$ sudo find . -mtime 5 -exec ls -la {} \;
Sorry, user tom is not allowed to execute '/usr/bin/find . -mtime 5 -exec ls -la {} ;' as root on localhost.
tom@evil:~$ sudo find . -mtime -5 -name .kshrc -delete
Sorry, user tom is not allowed to execute '/usr/bin/find . -mtime -5 -name .kshrc -delete' as root on localhost.
É uma espécie de PITA para configurar e manter bons perfis de sudoers, mas considero que vale a pena o esforço, especialmente em um ambiente compatível.