A Evolução do sudo: do su do Unix aos Privilégios Modernos

Este fato surpreende a maioria das pessoas: quando você digita sua senha no sudo, não aparece absolutamente nenhum feedback. Nenhum asterisco, nenhum ponto, nada. O cursor simplesmente fica parado. Essa decisão de design foi tomada nos anos 1980 e confunde os usuários há mais de quatro décadas. As pessoas costumam achar que o terminal travou, digitam a senha várias vezes ou acham que algo está quebrado. O Ubuntu finalmente decidiu mostrar asteriscos por padrão, encerrando uma tradição de 46 anos de digitação silenciosa de senhas.

Essa pequena mudança revela algo maior: a forma como o Linux lida com a escalada de privilégios é uma colcha de retalhos de decisões tomadas ao longo de décadas, algumas brilhantes, outras bastante questionáveis, todas carregando o peso da compatibilidade com versões anteriores. Entender como chegamos até aqui ajuda você a tomar decisões de segurança melhores hoje.

Antes do sudo: o mundo do su

A ferramenta original de escalada de privilégios no Unix era o su, de “substitute user”. Ela fazia exatamente uma coisa: trocava toda a sessão do shell para outro usuário, normalmente o root. Você digitava su, informava a senha do root, executava o trabalho administrativo e depois saía, voltando para sua conta normal.

$ su
Password: [type root's password]
# whoami
root
# apt install nginx
# exit
$ whoami
normaluser

Os problemas do su ficaram evidentes conforme os sistemas Unix cresceram além de um punhado de operadores confiáveis. Todo mundo que precisava de acesso administrativo tinha que conhecer a senha do root. Quando alguém saía da equipe, era preciso trocar a senha do root e distribuir a nova para todos os outros. Não havia trilha de auditoria: depois que alguém virava root, todas as ações eram registradas como “root”, sem nenhum registro de quem executou o quê. E o su entregava um shell root completo, o que significava que um único erro de digitação podia destruir o sistema.

A história de terror clássica: um administrador queria digitar rm -rf /tmp/old_files, mas acabou apertando enter depois de rm -rf /. Com um shell root completo, nada impede que esse comando seja executado. O su não fazia diferença entre “essa pessoa precisa reiniciar o nginx” e “essa pessoa precisa de acesso irrestrito ao sistema inteiro”.

Como o sudo resolveu o problema da senha do root

O sudo (“superuser do”) foi criado em 1980 na SUNY Buffalo por Bob Coggeshall e Cliff Spencer. A ideia central era simples, mas transformadora: em vez de compartilhar a senha do root, permitir que usuários individuais executassem comandos específicos como root usando a própria senha. O administrador do sistema controla quem pode executar o quê por meio de um arquivo de configuração.

Isso resolveu vários problemas de uma só vez:

Sem senha compartilhada do root. Cada usuário se autentica com as próprias credenciais. Quando alguém sai, você remove o acesso dessa pessoa ao sudo. Não é preciso rotacionar senhas.
Permissões granulares. Você pode permitir que um desenvolvedor reinicie um serviço específico sem dar acesso root completo.
Trilha de auditoria. Cada comando executado com sudo é registrado com o nome de usuário de quem o executou, o que foi executado e quando.
Escalada temporária. Em vez de um shell root sem prazo, o sudo executa um único comando com privilégios elevados e depois volta ao modo normal.

# Run a single command as root
$ sudo apt install nginx
[sudo] password for priya:
# That's YOUR password, not root's
# The audit trail in /var/log/auth.log:
# Mar 20 14:23:01 web-03 sudo: priya : TTY=pts/0 ;
#   PWD=/home/priya ; USER=root ; COMMAND=/usr/bin/apt install nginx

O arquivo sudoers: poderoso e perigoso

A configuração do sudo fica em /etc/sudoers, e a sintaxe dele é, sem exagero, uma das coisas mais confusas da administração Linux. Um único erro de sintaxe pode deixar você sem acesso ao sudo, e é por isso que existe o comando visudo: ele valida o arquivo antes de salvar.

# /etc/sudoers syntax:
# WHO  WHERE = (AS_WHOM) WHAT
# Let priya run anything as root on any host
priya ALL=(ALL:ALL) ALL
# Let the 'webdev' group restart nginx only
%webdev ALL=(root) /usr/bin/systemctl restart nginx,\
/usr/bin/systemctl reload nginx
# Let deploy user run deploys without a password
deploy ALL=(root) NOPASSWD: /opt/deploy/run.sh
# DANGEROUS: This looks restrictive but isn't
bob ALL=(root) /usr/bin/vim
# Bob can now run: sudo vim, then :!bash to get a root shell

Esse último exemplo, dar acesso ao sudo para o vim, é uma armadilha de segurança que pega muita gente o tempo todo. O Vim (e muitos outros programas) consegue abrir comandos de shell. Se um usuário consegue fazer sudo vim, ele efetivamente tem acesso root irrestrito. O mesmo vale para less, man, awk, find, python e dezenas de outros comandos. O projeto GTFOBins mantém uma lista completa de binários que podem ser usados para escapar de shells restritos.

Peculiaridades e armadilhas de segurança do sudo

O sudo acumulou alguns comportamentos realmente estranhos ao longo de mais de 40 anos de história. Entender essas peculiaridades é importante para a segurança:

Cache de credenciais. Depois que você digita sua senha, o sudo a mantém em cache por 15 minutos por padrão. Durante essa janela, qualquer comando sudo roda sem autenticação. Se você se afastar de um terminal desbloqueado, qualquer pessoa pode executar comandos sudo por até 15 minutos. Execute sudo -k para limpar o cache imediatamente.
A configuração tty_tickets. Por padrão, o cache de credenciais do sudo é por terminal. Mas em alguns sistemas, autenticar em uma sessão de terminal desbloqueia o sudo em todas as outras. Verifique suas configurações Defaults.
Variáveis de ambiente. O sudo higieniza a maioria das variáveis de ambiente, mas não todas. LD_PRELOAD e LD_LIBRARY_PATH são removidas, mas se o env_keep estiver mal configurado, um atacante pode injetar caminhos de bibliotecas maliciosas. Isso já serviu de base para várias explorações reais de escalada de privilégios.
A armadilha do NOPASSWD. NOPASSWD é conveniente para automações, mas perigoso quando aplicado de forma ampla demais. Uma aplicação comprometida rodando como um usuário com acesso sudo NOPASSWD efetivamente tem root, sem nenhuma senha para quebrar.

# Security hardening for sudoers:
# Require password every time (disable caching)
Defaults timestamp_timeout=0
# Or reduce cache to 1 minute
Defaults timestamp_timeout=1
# Ensure credential cache is per-terminal
Defaults tty_tickets
# Log all sudo I/O (records full terminal sessions)
Defaults log_input, log_output
Defaults iolog_dir=/var/log/sudo-io
# Require root password instead of user password
# (prevents compromised user accounts from sudo-ing)
Defaults rootpw
# Show asterisks when typing password
Defaults pwfeedback

Alternativas modernas: doas, polkit e run0

A complexidade do sudo deu origem a várias alternativas, cada uma seguindo uma filosofia diferente.

doas: o sudo sem a complexidade

O doas do OpenBSD (“dedicated OpenBSD application subexecutor”, ou subexecutor dedicado de aplicações do OpenBSD) foi criado por Ted Unangst em 2015, especificamente porque o sudo tinha ficado complexo demais para ser auditado. A configuração inteira costuma ter de 2 a 3 linhas:

# /etc/doas.conf — the entire configuration
permit persist priya
permit nopass deploy as root cmd /opt/deploy/run.sh
# That's it. Compare this to a typical sudoers file.
# 'persist' is like sudo's credential caching
# 'nopass' is like NOPASSWD

O código-fonte do doas tem cerca de 2.500 linhas de C. O do sudo passa de 150.000. Para sistemas em que você não precisa dos recursos avançados do sudo (como correspondência de argumentos por comando ou integração com LDAP), o doas é muito mais simples de configurar, auditar e proteger. Uso em meus servidores pessoais há anos e nunca senti falta do sudo.

polkit: privilégios granulares no desktop

O PolicyKit (polkit) segue uma abordagem completamente diferente. Em vez de encapsular comandos individuais, ele define ações que as aplicações podem solicitar. Quando um app de desktop precisa alterar configurações de rede, ele pede permissão ao polkit, que decide, com base nas suas regras, se concede, nega ou pede confirmação ao usuário.

É assim que o seu desktop Linux permite montar um pendrive sem senha, mas exige autenticação para instalar software. A granularidade está no nível de ação, e não de comando, o que combina melhor com a forma como usuários de desktop pensam sobre permissões.

run0: a reformulação radical do systemd

O run0 do systemd é a opção mais recente, e funciona de um jeito fundamentalmente diferente do sudo. Em vez de executar um comando como root a partir da sua sessão existente (o que exige bits setuid e cria dores de cabeça de segurança), o run0 pede ao gerenciador de serviços que inicie um novo serviço que roda como root. A sua sessão de usuário nunca ganha privilégios elevados: o processo privilegiado é totalmente separado.

Isso elimina categorias inteiras de vulnerabilidades do sudo. Não há binário setuid, nem cache de credenciais, nem superfície para injeção de variáveis de ambiente. O custo é que ele exige o systemd, o que torna o run0 uma opção inviável para sistemas BSD e instalações Linux mínimas. Mas, em servidores com systemd, é provavelmente a opção mais segura disponível.

Recomendações práticas

Depois de anos administrando servidores Linux e investigando incidentes de escalada de privilégios, eis o que eu realmente recomendo:

Desative o login direto como root. Use sudo ou doas para tudo. Não deve existir nenhuma senha compartilhada do root.
Use grupos, e não usuários individuais, no sudoers. Gerencie o acesso pela associação a grupos. Quando alguém sair, basta remover a pessoa do grupo.
Nunca dê acesso sudo a interpretadores ou editores. Nada de sudo vim, sudo python ou sudo less. Se precisar editar um arquivo que pertence ao root, use o sudoedit.
Minimize as regras NOPASSWD. Use-as apenas para processos automatizados e apenas para comandos específicos, com caminhos completos.
Ative o log do sudo. No mínimo, registre todos os comandos sudo. Em sistemas sensíveis, ative o log completo de entrada e saída.
Considere o doas para sistemas mais simples. Se você não precisa de integração com LDAP ou de regras de correspondência complexas, o doas é mais fácil de configurar corretamente.
Renove os caches de credenciais com agressividade. Reduza o timestamp_timeout para 1 a 5 minutos ou desative o cache por completo em servidores de produção.

O melhor mecanismo de escalada de privilégios é aquele que concede o acesso mínimo necessário, pelo tempo mínimo necessário, com uma trilha de auditoria completa. Todo o resto é concessão.

O sudo não vai a lugar nenhum. Ele está profundamente incorporado em scripts, automações, documentações e na memória muscular de todo mundo para desaparecer. Mas o cenário de alternativas nunca esteve tão saudável. Seja qual for sua escolha, manter o sudo (bem endurecido), migrar para o doas (pela simplicidade) ou adotar o run0 (para sistemas críticos de segurança), o importante é entender o que sua ferramenta de escalada de privilégios realmente faz, porque a distância entre o que as pessoas acham que o sudo faz e o que ele realmente faz é onde mora a maioria dos incidentes de segurança.