Comandos sudo e su: privilégios com controlo no Linux

Em qualquer sistema Linux bem administrado há uma regra que não se discute: ninguém trabalha com sessão de root aberta. Um engano num rm ou um terminal desbloqueado transformam-se em desastre quando cada tecla tem privilégios absolutos. O sudo resolve o dilema: dá privilégios elevados a quem precisa, um comando de cada vez, com a password do próprio utilizador — e regista tudo o que foi feito e por quem.

Neste artigo da série sobre comandos Linux tratamos o sudo e o seu antecessor su: como funcionam, em que diferem, como se edita o sudoers em segurança e porque é que esta dupla está no centro do princípio do menor privilégio — com um simulador interativo no final para praticar tudo, incluindo as recusas.

O que fazem o sudo e o su

O sudo (superuser do) executa um comando como outro utilizador — por omissão, root. Antes de o fazer, autentica quem pede (com a password do próprio utilizador, não a de root), consulta a política definida em /etc/sudoers para decidir se o pedido é permitido e regista o resultado no log de autenticação. O su (substitute user) é mais antigo e mais rudimentar: inicia uma shell como outro utilizador, pedindo a password da conta de destino — para se tornar root, é preciso saber a password de root.

sudo [opções] comando        # executa um comando como root (ou outro utilizador)
su [-] [utilizador]          # abre uma shell como outro utilizador (root por omissão)

A diferença de modelo é o que importa: com sudo, cada pessoa usa a sua credencial, recebe só os privilégios definidos na política e cada elevação fica associada ao seu nome; com su, a password de root é um segredo partilhado e o log apenas mostra que alguém mudou de identidade. Por isso muitas distribuições nem definem password para root, forçando toda a administração a passar pelo sudo.

As opções que interessam

sudo no dia a dia

• sudo comando — a forma base: pede a password do utilizador, executa e volta à sessão normal. A autenticação fica em cache alguns minutos (timestamp_timeout), pelo que comandos seguidos não voltam a pedir password.
• sudo -l — lista as regras aplicáveis ao utilizador atual. É o comando de auditoria por excelência: mostra exatamente o que aquela conta pode executar, como que utilizador e se precisa de password.
• sudo -u utilizador comando — executa como outro utilizador que não root. Útil para testar permissões de contas de serviço, por exemplo sudo -u www-data whoami.
• sudo !! — combinação com a expansão de histórico do bash: repete o último comando, agora com privilégios. O reflexo natural depois de um «Permissão negada».
• sudo -v e sudo -k — renovam e invalidam a cache de credenciais. O -k é boa prática antes de abandonar um terminal partilhado.
• sudoedit (ou sudo -e) — edita um ficheiro privilegiado com o editor do próprio utilizador, através de uma cópia temporária, sem nunca lhe dar uma shell de root.

Shells de root: sudo -i, su e su –

Quando é mesmo necessária uma sessão administrativa completa, há três caminhos com resultados subtilmente diferentes:

• sudo -i — abre uma login shell de root com ambiente limpo: HOME=/root, PATH com os diretórios sbin e variáveis reiniciadas pelo env_reset. Usa a password do próprio utilizador e fica registado em seu nome.
• su - — o equivalente clássico: também é uma login shell completa, mas exige a password de root.
• su (sem hífen) — muda de identidade mas preserva o diretório atual e grande parte do ambiente, incluindo o PATH do utilizador. Este ambiente misto é fonte clássica de erros subtis e deve ser evitado.

O ficheiro sudoers e o visudo

Toda a política do sudo vive em /etc/sudoers e nos ficheiros de /etc/sudoers.d/. Uma regra tem a forma utilizador máquinas=(destino) comandos:

Defaults    env_reset
Defaults    timestamp_timeout=15

root      ALL=(ALL:ALL) ALL
%sudo     ALL=(ALL:ALL) ALL
backup    ALL=(root) NOPASSWD: /usr/bin/rsync

O prefixo % aplica a regra a um grupo — é assim que as distribuições dão privilégios aos administradores, via grupo sudo ou wheel. A etiqueta NOPASSWD: dispensa a password para os comandos listados e deve ser usada de forma cirúrgica: um binário concreto, para uma conta de automação concreta. E há uma regra de sobrevivência: o sudoers edita-se sempre com visudo, que bloqueia o ficheiro e valida a sintaxe antes de gravar — um sudoers inválido pode impedir qualquer elevação na máquina, incluindo a necessária para o corrigir.

sudo e su em cibersegurança

Menor privilégio aplicado na prática. O sudoers transforma o princípio do menor privilégio em configuração concreta: em vez de «root para tudo», define-se exatamente que comandos cada conta ou grupo pode executar. Uma conta de backup que só pode correr rsync não serve para instalar pacotes nem abrir shells.

Trilho de auditoria. Cada invocação do sudo — aceite ou recusada — gera uma linha no log de autenticação (/var/log/auth.log em sistemas Debian, ou via journalctl) com o utilizador, o diretório, o destino e o comando completo. Em resposta a incidentes, este trilho responde à pergunta central: quem executou o quê, e quando. Tentativas recusadas valem uma regra de deteção no SIEM.

Escalada de privilégios. Do lado ofensivo, sudo -l é dos primeiros comandos que um atacante corre numa conta comprometida: revela de imediato os caminhos de escalada. O conceito documentado como GTFOBins resume o risco — muitos binários legítimos (editores, paginadores, ferramentas de cópia) sabem lançar shells ou ler ficheiros arbitrários; autorizados no sudoers, tornam a regra «restrita» equivalente a root completo. Prefira binários sem capacidade de escape e evite NOPASSWD amplo.

Hardening da conta root. Bloquear a password de root (passwd -l root) e desativar o login remoto de root no SSH obriga todo o acesso administrativo a passar pelo sudo — com credenciais individuais e registo nominal. O su, que não consulta o sudoers, deixa de ser um caminho de ataque.

Experimente no simulador interativo

O simulador abaixo põe lado a lado a sessão atual (identidade, grupos, excerto do sudoers e o auth.log a crescer) e um terminal que executa os comandos. Escolha um dos três utilizadores — aluno (grupo sudo), backup (só rsync, com NOPASSWD) e convidado (sem privilégios) — e combine-o com sudo apt update, sudo -l, sudo -u www-data, sudo -i, sudo !!, su, su - ou visudo. Use Demonstrar tudo para a sequência guiada, ou avance com Anterior/Seguinte — e repare como cada recusa fica no log.

Erros comuns e boas práticas

• Editar o /etc/sudoers com um editor normal: um erro de sintaxe pode trancar toda a administração. Use sempre visudo, e visudo -c para validar em automação.
• NOPASSWD: ALL: dispensar a password para todos os comandos elimina a última barreira entre uma sessão comprometida e root. Restrinja a binários concretos e contas de automação.
• Permitir binários com escape de shell: autorizar no sudoers editores, paginadores ou interpretadores «só para uma tarefa» costuma equivaler a autorizar root completo.
• Usar su sem hífen e depois perder tempo com erros de ambiente: se precisa mesmo de uma shell de root, prefira sudo -i (ou, em último caso, su -).
• Trabalhar permanentemente em sudo -i: a shell de root deve ser exceção com princípio e fim, não o ambiente de trabalho por omissão.
• Ignorar as recusas nos logs: linhas «NOT in sudoers» e «command not allowed» raramente são inocentes em servidores — monitorize-as.
• Esquecer a cache de credenciais: num terminal partilhado, corra sudo -k antes de se afastar.

Conclusão

O sudo é muito mais do que «o prefixo que faz os comandos funcionarem»: é a fronteira auditável entre o utilizador comum e o administrador, configurada regra a regra no sudoers e registada linha a linha nos logs. Dominar a dupla sudo/su é um dos fundamentos de qualquer prática séria de administração e segurança em Linux. Se este conteúdo lhe é útil, a equipa HJFR oferece formação prática em Linux e cibersegurança, além de consultoria especializada: conheça o nosso catálogo de serviços e veja também o artigo da série sobre o comando useradd.

Este artigo faz parte da série «Comandos Linux, um a um» do blog HJFR — fique atento aos próximos comandos.