sudo e privilégios mínimos

Módulo 3: Utilizadores, permissões e sudo · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: No final desta lição, será capaz de trabalhar como utilizador normal com sudo, adicionar um administrador em segurança, alterar as definições do sudo sem ficar trancado fora do servidor e explicar por que razão os privilégios mínimos protegem o seu servidor.

Conceitos-chave: sudo, grupo sudo, grupo wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, bloquear o root, registo do sudo, privilégios mínimos (least privilege), utilizador de serviço

Porque não trabalhar simplesmente como root?

Após a instalação, é frequente iniciar sessão como root. É cómodo: tudo é permitido. Mas é precisamente esse o problema:

• Basta um erro de digitação. rm -rf / home/anna/oud (repare no espaço depois da primeira barra) apaga, como root, todo o seu servidor. Como utilizador normal, recebe uma mensagem de erro.
• Tudo é executado como root. Um script que cola da internet, um programa que está a testar: tudo recebe permissões totais.
• Nenhum rasto. Se três pessoas trabalham como root, ninguém sabe depois quem fez o quê.
• root é o nome que todos os atacantes experimentam. O início de sessão como root deve ser totalmente desativado (lição 2.2), mas isso só é possível quando dispõe de outro caminho para as permissões de administração.

Esse outro caminho é o sudo: inicia sessão com o seu próprio utilizador e coloca sudo apenas antes de um comando que precise de permissões de administração.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Desde a versão 25.10, o Ubuntu utiliza por predefinição o sudo-rs, uma nova implementação do sudo. Para tudo o que é tratado nesta lição, funciona da mesma forma.)

O sudo pede a sua palavra-passe, não a do root. Depois, memoriza-a por predefinição durante um quarto de hora, para que não tenha de a introduzir em cada comando. Cada comando que executa com sudo fica registado.

Criar um administrador

No Debian e no Ubuntu, todos os membros do grupo sudo podem fazer tudo através do sudo. Isso está definido em /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Leia-se: os membros do grupo sudo (%) podem, em todas as máquinas (ALL), como qualquer utilizador e grupo ((ALL:ALL)), executar qualquer comando (ALL).

Adicionar um administrador faz-se, portanto, em dois passos, como root:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Em seguida, coloque a chave pública da Anna em /home/anna/.ssh/authorized_keys com o proprietário e as permissões corretos:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

Não se esqueça do chown: se foi copiado pelo root, o ficheiro pertence ao root, e a Anna não consegue iniciar sessão com a sua chave.

Agora teste numa segunda janela, mantendo a sessão de root aberta:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Só quando isto funcionar deve definir PermitRootLogin no nas suas definições de SSH (lição 2.2). A partir daí, inicia sempre sessão como Anna.

Um ponto a reter: a Anna precisa agora de uma palavra-passe para o sudo. Guarde-a no seu gestor de palavras-passe. O início de sessão é feito com a chave, o sudo com a palavra-passe: duas coisas diferentes que um intruso teria de obter.

Alterar as definições do sudo: sempre com visudo

Um erro em /etc/sudoers pode fazer com que o sudo deixe completamente de funcionar. Se o root também não puder iniciar sessão, fica sem saída. Por isso, nunca edite as definições do sudo com um editor normal, mas sim com o visudo. Este abre uma cópia temporária e verifica o conteúdo antes de guardar:

root@web1:~# visudo -f /etc/sudoers.d/backup

Tal como no SSH, utilize de preferência um ficheiro próprio em /etc/sudoers.d/ em vez do ficheiro principal. Tenha em atenção duas regras desta pasta:

• Os ficheiros cujo nome contém um ponto ou termina em ~ são ignorados. Assim, backup.conf não funciona, mas backup funciona. O objetivo é ignorar cópias criadas por editores, mas apanha muita gente de surpresa.
• O ficheiro tem de pertencer ao root e não pode ser gravável por outros (440 é o habitual; o visudo trata disso).

Se quiser verificar um ficheiro existente sem o editar: visudo -c verifica tudo.

NOPASSWD: prático, mas saiba o que está a fazer

Com NOPASSWD, o sudo deixa de pedir palavra-passe:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Algumas imagens de VPS definem isto para o utilizador predefinido, para que, depois de iniciar sessão com uma chave, seja imediatamente administrador. Verifique com sudo -l o que se aplica no seu caso. A consequência: quem tiver a chave da Anna é imediatamente root. Deixa de existir uma segunda fechadura. Num servidor pessoal pode optar por isso, mas faça-o de forma consciente.

Muito melhor é usar NOPASSWD apenas para um comando específico, por exemplo para um script de cópia de segurança que tem de poder ser executado automaticamente:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

O utilizador backup pode então executar exatamente esse script como root, sem palavra-passe, e nada mais. Duas armadilhas:

• Utilize sempre o caminho completo. Com apenas maak-backup, alguém pode colocar um programa próprio com esse nome no início do seu caminho.
• O próprio script não pode ser gravável por esse utilizador. Caso contrário, este altera-o e executa comandos arbitrários como root. O mesmo se aplica a comandos que podem abrir uma shell, como um editor (vim, nano) ou less: quem os puder iniciar através do sudo consegue abrir uma shell de root a partir do programa. Nunca autorize esses comandos isoladamente através do sudo.

O que fica registado

Sempre que alguém utiliza o sudo, é escrita uma linha no journal (e, em sistemas com rsyslog, também em /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Vê quem, onde, como que utilizador e que comando. Esta é uma das razões para não trabalhar como root com várias pessoas. Tentativas de sudo falhadas ("incorrect password attempts", ou seja, tentativas com palavra-passe errada) de uma conta que não é a sua são um sinal de alarme.

Privilégios mínimos em grande escala

O sudo é uma aplicação de um princípio geral: os privilégios mínimos (least privilege). Cada utilizador e cada serviço recebe exatamente as permissões de que precisa, e não mais. Num servidor, isto significa, entre outras coisas:

• trabalha como utilizador normal e utiliza o sudo apenas quando necessário;
• cada serviço é executado com um utilizador próprio sem shell (lição 3.1), não como root;
• uma aplicação web recebe um utilizador de base de dados que só pode usar a sua própria base de dados, e não o administrador do servidor de bases de dados;
• um script de cópia de segurança só pode executar o único comando de que precisa (NOPASSWD com caminho completo);
• um colega que apenas atualiza o site recebe permissão de escrita em /var/www/example.com através de um grupo, e não sudo.

A ideia: se algo correr mal (uma falha num plugin, uma chave roubada), os danos ficam limitados a esse utilizador ou serviço. Isto volta a surgir nos princípios do CIS e na lição sobre hardening (10.1).

No AlmaLinux e no Rocky Linux

Aí, o grupo de administradores chama-se wheel em vez de sudo: usermod -aG wheel anna. A linha em /etc/sudoers é %wheel ALL=(ALL) ALL. O visudo e /etc/sudoers.d funcionam da mesma forma. As mensagens do sudo também ficam registadas em /var/log/secure.

Resumo

• Trabalhe como utilizador normal e utilize o sudo para a administração; o sudo pede a sua própria palavra-passe e regista cada comando.
• Criar um administrador: adduser anna, adduser anna sudo (wheel nas distribuições do tipo RHEL), chave com proprietário e permissões corretos, teste numa segunda janela e só depois desativar o início de sessão como root.
• Edite as regras do sudo apenas com visudo, de preferência num ficheiro próprio em /etc/sudoers.d/ sem ponto no nome.
• NOPASSWD para tudo elimina uma fechadura; utilize-o de preferência apenas para um comando, com caminho completo, que o utilizador não possa alterar.
• Privilégios mínimos: cada utilizador e serviço recebe exatamente o que precisa, para que um erro ou uma falha tenha um impacto reduzido.

Questionário

Exercício

Exercício O3.2: Um administrador com sudo. Crie no seu servidor um administrador normal (por exemplo anna), configure a sua chave, teste o início de sessão e sudo -l numa segunda janela e, em seguida, desative o início de sessão como root através de SSH (PermitRootLogin no). Assinale os passos, cole o resultado de id (apenas nome e grupos) e responda às perguntas: que linha dá permissões ao seu administrador, existe NOPASSWD em algum lado e como consegue entrar se se esquecer da sua palavra-passe?

Para saber mais

Os passos destes artigos aplicam-se aos VPS da WebOké; noutros fornecedores, o funcionamento é semelhante.

• Proteger o seu VPS: os primeiros cinco minutos
• Sem acesso ao seu VPS: o que fazer?
• Manual DirectAdmin 12.2: Utilizadores de bases de dados, permissões e palavras-passe
• Ubuntu Server: User management: https://ubuntu.com/server/docs/how-to/security/user-management/
• Manual do Debian sobre sudoers: https://manpages.debian.org/trixie/sudo/sudoers.5.en.html