Por dentro do SUDO. Chega de vícios!

Home / Security / Por dentro do SUDO. Chega de vícios!

Lá para as bandas do Debian 4(Etch), a mensagem padrão de login do usuário (motd) dizia “Para grandes poderes, grandes responsabilidades”, lógico que todo geek conhece essa frase e sabe de onde ela veio. Pois bem, o intuito deste post é dar uma de ‘Tio Ben’ pra quem usa o famoso ‘sudo su’ porque ele já veio habilitado mas não se ligou ainda no que está por trás disso.

Separando as coisas

su é um comando GNU/Linux que serve para fazer login como outro usuário.

Exemplo:

Executando o comando a partir de um login de usuário, sempre será pedida a senha do usuário com o qual se quer fazer login. Agora, vamos ver o contrário:

Notaram a diferença? Se você tiver poderes de superusuário (caso do root) e executar o ‘su’ contra qualquer usuário, por padrão, a senha não será solicitada e você vai poder fazer login direto.

Já o sudo é um programa (que pode estar instalado ou não) que dá privilégios de superusuário para que o usuário comum possa executar determinados comandos descritos no arquivo /etc/sudoers, até aí, tudo ótimo. A questão é que geralmente (e muito erradamente) o administrador deixa TODOS os comandos de root permitidos para a lista de usuários que está dentro do /etc/sudoers. É um erro muito grave!

Boas práticas

Você tem 2 caminhos: ou permite todos os comandos de root, exceto os que você não quer ou permite apenas uma lista de comandos.

Vamos fazer primeiro uma lista de exceção. E o mais interessante é sempre proibir o uso do comando su, para que o usuário permitido no sudoers não consiga fazer login como root, como no exemplo abaixo:

Entendeu? A senha que foi pedida pelo sudo foi a senha do usuário comum, o mesmo que executou o comando. Assim é mole, é só fazer login como root e literalmente SER o root.

Vamos lá então:

#visudo

No Ubuntu, lá para o meio do arquivo, vai ter uma linha assim:

%admin ALL=(ALL) ALL

Isso significa que todos os usuários do grupo ‘admin’ vão poder executar todos os comandos de que estiverem no path de qualquer usuário de sistema, inclusive o root. Em vez de fazer por grupo, também podemos fazer por usuário. Vamos criar um primeiro:

#useradd -m -d /home/teste -s /bin/bash -c ‘Usuário de teste’ teste

#passwd teste

#visudo

teste ALL=NOPASSWD: ALL, !/bin/su, !/sbin/shutdown, !/sbin/reboot

(para sair e salvar, pressione CTRL+X)

Testando:

#su teste

Observem que o usuário teste consegue executar o comando iptables, que é comando de superusuário mas o comando su não. O mesmo efeito aconteceria caso ele tentasse o comando ‘shutdown -h now’ (que desliga imediatamente o sistema) ou reboot.

Vamos agora fazer o contrário.Vamos criar uma lista de aceitação de comandos:

#visudo

teste ALL=NOPASSWD: /sbin/iptables, /sbin/route

(neste caso, apenas os comandos de superusuário iptables e route  estarão liberados para o usuário teste)

Testando:

#su teste

Repare que o usuário teste consegue usar os comando iptables e route mas não o comando shutdown -h now.

Partindo daí, já dá para montar uma estratégia segura para os usuários que vão precisar de comandos administrativos.

Se gostou do post e quer receber nossas notícias, é só cadastrar seu e-mail para receber.

Grande abraço e tudo de bom!

 

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *