Desabilita alguns programas do sudo

Question

Eu tenho um grupo de desenvolvedores confiáveis que dei permissões sudo em um servidor, mas eu quero ser capaz de excluir alguns programas para serem executados com o sudo. Por exemplo, eu gostaria de desabilitar o comando su de ser executado com o sudo, mas deixá-los executá-lo como seu usuário.

Como posso conseguir isso?

    

Answer 1

Você pode excluir o comando com sudoers. Por exemplo:

 Cmnd_Alias  DEV_EXCEPTIONS=/bin/su, /usr/bin/vi
 %devgrp    ALL = ALL, !DEV_EXCEPTIONS

Resultados em

 User XYZ may run the following commands on this host:
 (root) ALL, (root) !/bin/su, !/usr/bin/vi

O usuário ainda poderá executar o comando su

    

Answer 2

Veja meu Detalhado Solução Aqui . Sua solução será a mesma. O que você vai querer fazer diferente é usar vários Cmnd_Alias para fazer a depuração, e adicionar novos comandos mais facilmente. Você pode usar essas várias cadeias de apelidos, em conjunto com o Negate Operator, como DarkHeart apontou em sua resposta.

    

Answer 3

Você não pode fazer isso, não com segurança .

Embora sudo tenha uma sintaxe de configuração para isso, ele não realizará o que você espera. Depois que você permitir o acesso root a um sistema, nenhuma quantidade de ações específicas na lista negra poderá bloqueá-lo novamente. O sistema de arquivos Linux e o modelo de permissão de processo simplesmente não permitem isso.

comentário de Gilles começa a sugerir porque:

Note that while it's possible, it's completely useless. If you forbid sudo su, it still allows sudo env su, sudo sh -c su, sudo /totally/not/su where /totally/not/su is a symlink to /bin/su, sudo ~/bin/ls where ~/bin/ls is a shell script that runs su, sudo bash, sudo zsh, sudo python, sudo vi followed by :shell, ...

Mas isso dificilmente risca a superfície das possibilidades.

Não inclua na lista negra lista de permissões .

Ações de lista negra que você não quer que aconteçam serão um jogo perdido. Com uma abordagem de lista negra, na melhor das hipóteses você pode pegar erros mentais ausentes e sinalizar educadamente para um usuário para lembrá-los de que você queria que algo fosse feito de outra maneira, você absolutamente não pode forçá-los a não fazer nada.

Se você quiser um sistema restrito, sua única oração é colocar tipos de ações muito específicos na lista de permissões. As ações que você pode colocar na lista de permissões sem abrir um sistema para acesso root completo são executáveis em um local fixo que executa tarefas fixas sem processar a entrada controlável pelo usuário. Coloque o outro lado que você não pode permitir

• Gravar o acesso a qualquer arquivo marcado como executável ou setuid ou analisado de outra forma e executado pelo root.

  Inesperadamente, isso pode incluir arquivos de configuração para muitos programas. Até mesmo os formatos baseados em *.ini , *.yaml ou *.conf aparentemente inofensivos geralmente têm opções que fazem com que os programas executem outros processos com base em um valor de configuração. Uma olhada rápida pela pasta /etc e vejo muito poucos arquivos de configuração que eu não seria capaz de explorar para um escalonamento de privilégios de root completo se meu acesso de gravação à configuração fosse a única coisa que eu comecei com .

• Execute qualquer processo que crie outro processo com base na entrada do usuário.

  Observe especialmente a concessão de acesso a scripts controláveis por variáveis de ambiente, processos de entrada do usuário etc. Na verdade, não há muita segurança.

Em suma, não dê acesso a sudo de qualquer tipo, a menos que você entenda que está dando controle total sobre todos os demais ou entenda completamente as implicações da única ação cuidadosamente controlada que está na lista de permissões.

¹ _{Eu sei que isso contradiz outro responde mas depois de ver essa pergunta em outros lugares como uma" solução ", acho que vale a pena notar em uma resposta para que ela seja lida pelos visitantes das perguntas. O comentário de Gilles não está sendo levado a sério o suficiente .}