Criação do comando sudo: os bastidores da ferramenta que redefiniu permissões e controle no Linux

Escrito por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...

A história do sudo vai muito além do terminal: poder, segurança e uma revolução silenciosa no Linux.

O comando sudo é tão presente no cotidiano de qualquer usuário Linux que sua existência raramente é questionada. Bastaria lembrar o número de vezes em que um simples sudo apt install ou sudo nano evitou que se digitasse a senha de root diretamente. Porém, a criação do comando sudo não foi apenas uma melhoria funcional: ela representa uma mudança paradigmática na forma como o Linux e os sistemas Unix lidam com permissões e controle de usuários. Neste artigo, mergulhamos nos bastidores históricos, técnicos e culturais dessa ferramenta, explorando como o sudo surgiu, por que se tornou o padrão e o impacto profundo que teve na segurança dos sistemas.

O cenário pré-sudo: a era do su e seus riscos

Antes do sudo, o método dominante de escalonamento de privilégios era o uso do comando su (“substitute user”). Seu objetivo era claro: permitir que um usuário comum assumisse a identidade de outro — frequentemente o superusuário — desde que soubesse a senha.

Como o comando su funcionava

su
Password: [senha do root]

Ao digitar a senha correta, o terminal passava a operar como se fosse o usuário root. O problema? Todos os usuários que precisassem de permissões administrativas precisavam conhecer a senha do root. Isso criava uma série de riscos, como:

  • Compartilhamento irrestrito da senha de root, dificultando o rastreio de atividades administrativas.
  • Impossibilidade de limitar comandos específicos — qualquer usuário com acesso ao root poderia fazer qualquer coisa.
  • Falta de auditoria individualizada, já que todos operavam sob a mesma identidade administrativa.

Essa situação foi o estopim para a busca por uma solução mais segura, controlada e auditável. Assim nasceu a ideia por trás do sudo.

O nascimento de um padrão: a criação do comando sudo (1980s)

A criação do comando sudo remonta ao início da década de 1980, na Universidade Estadual de Nova Iorque em Buffalo. Os responsáveis foram Bob Coggeshall e Cliff Spencer, que enfrentavam um problema comum em laboratórios universitários: como dar aos usuários certos poderes administrativos sem abrir completamente as portas da máquina?

A solução veio com uma ideia simples, mas poderosa: permitir que usuários executassem comandos como root sem saber a senha de root, respeitando regras previamente definidas por um administrador.

Por que quase ninguém quis o sudo no começo?

Curiosamente, o sudo quase morreu antes de virar padrão. Durante parte dos anos 1980 e 1990, o projeto ficou abandonado e só era mantido por forks isolados, dentro de universidades e empresas que adaptavam o código conforme suas necessidades. Muitos administradores veteranos, profundamente ligados à cultura Unix tradicional, rejeitavam a ideia do sudo. Achavam que ele “enfraquecia o sistema” ao permitir múltiplos administradores e introduzir regras externas ao root. Foi uma treta silenciosa entre pragmatismo e purismo. Veja também o nosso artigo aonde falamos sobre a diferenças entre sudo e su, e conheça mais sobre este comando que revolucionou.

A virada: Todd C. Miller e a reconstrução do sudo

Tudo mudou quando Todd C. Miller assumiu a manutenção do projeto nos anos 90. Ele reescreveu boa parte do código, formalizou um ciclo de desenvolvimento, melhorou a segurança, e transformou o sudo em um projeto respeitado e auditável, com código aberto e documentação formal. O sudo passou de “um hack útil” para uma ferramenta essencial de segurança em ambientes Unix-like. O trabalho de Miller está documentado no site oficial do projeto.

Como o sudo funciona: a engenharia por trás das permissões e controle Linux

O coração do sudo está no arquivo /etc/sudoers, que define quem pode fazer o quê em termos de comandos, alvos e privilégios.

Estrutura e sintaxe do arquivo /etc/sudoers

Esse arquivo permite combinações complexas de permissões:

# Exemplo de linha no /etc/sudoers
joao ALL=(ALL) ALL

Isso significa que o usuário joao pode executar qualquer comando como qualquer usuário em qualquer host, desde que se autentique com sua própria senha.

Para editar o arquivo com segurança e evitar erros de sintaxe que podem bloquear o sistema, utiliza-se:

sudo visudo

Esse comando garante que a edição seja validada antes de salvar.

Principais opções do sudoers

  • NOPASSWD: permite executar comandos sem solicitar senha.
  • RUNAS: define outro usuário além do root como alvo da execução.
  • Cmnd_Alias: agrupa comandos para facilitar regras.
  • User_Alias, Host_Alias, Runas_Alias: agrupam usuários, hosts e identidades para controle granular.

Integração com PAM (Pluggable Authentication Modules)

O sudo também é integrado com o PAM, permitindo autenticação multifatorial, logs centralizados e políticas adicionais.

Sudo vs. su: por que o sudo se tornou o padrão de segurança?

A comparação entre sudo e su revela por que o primeiro venceu em quase todas as distribuições modernas. Veja a tabela abaixo:

Critériosusudo
Requer senha do rootSimNão
Auditoria por usuárioNãoSim
Permissões granularesNãoSim
Princípio do menor privilégioNãoSim
Comandos restritos por usuárioNãoSim
Registro de logs individuaisNãoSim

O sudo implementa o princípio do menor privilégio, permitindo conceder apenas o necessário para uma tarefa específica — o que é uma base essencial de boas práticas de hardening em servidores Linux modernos.

Controvérsias com o Ubuntu: quando o sudo virou regra

Em 2004, quando o Ubuntu foi lançado, tomou uma decisão polêmica: eliminar o uso do root por padrão, exigindo que todas as ações administrativas passassem pelo sudo. Muitos consideraram isso uma afronta à tradição Unix. Houve críticas pesadas da comunidade Debian, que via a medida como um excesso de paternalismo com o usuário.

Mark Shuttleworth, fundador do Ubuntu, defendeu a escolha com base em segurança prática: “Com sudo, cada ação administrativa é rastreável por usuário. Isso é melhor que um root genérico, sem histórico nem contexto”.

Essa decisão consolidou o sudo como o padrão de administração em desktops Linux.

A segurança do sudo: desafios e boas práticas

Apesar de sua robustez, o sudo não é imune a vulnerabilidades.

O caso Baron Samedit (CVE-2021-3156)

Uma falha crítica descoberta em 2021 permitia a escalada de privilégios local não autenticada, afetando múltiplas versões do sudo. Essa falha foi batizada de Baron Samedit. A gravidade da vulnerabilidade foi detalhada em publicações como o alerta da Qualys e exigiu correção imediata por todas as distros.

Essa vulnerabilidade reacendeu debates internos na comunidade sobre reescrever o sudo em Rust ou C++. Até hoje, o projeto segue em C, mas a pressão por mais segurança de memória aumentou.

Sudo sob vigilância da NSA?

Nos documentos vazados por Snowden em 2013, o sudo não foi citado diretamente, mas foi indiretamente mencionado em análises de escalonamento de privilégios. Má configurações de sudo apareciam como vetores exploráveis em servidores mal administrados — reforçando a máxima: “sudo seguro é sudo bem configurado”.

Boas práticas de configuração

  • Use visudo sempre.
  • Defina timeouts com Defaults timestamp_timeout=5.
  • Habilite Defaults logfile="/var/log/sudo.log" para rastreio.
  • Evite NOPASSWD fora de contextos automatizados.

Segurança adicional: 2FA e logs

O uso de autenticação de dois fatores no Linux para o sudo está crescendo, especialmente em ambientes corporativos. Além disso, a auditoria de logs (/var/log/auth.log, journalctl) é essencial para detectar usos indevidos.

Para iniciantes: o que são permissões, root e sudo?

Para entender o sudo, é necessário compreender como o Linux organiza privilégios de acesso. Pense no root como o diretor da empresa. Ele pode entrar em qualquer sala, acessar qualquer dado e tomar qualquer decisão. Um usuário comum, por outro lado, tem acesso restrito apenas ao seu setor.

O sudo funciona como um cartão de acesso temporário, que permite ao funcionário fazer algo fora de sua alçada — mas com autorização documentada e temporária.

Permissões são como chaves para portas. Elas definem quem pode ler, escrever ou executar determinado arquivo ou comando. Com o sudo, o usuário comum não precisa receber todas as chaves — apenas um acesso monitorado e pontual.

O impacto do sudo no ecossistema Linux e na administração de sistemas

Desde que se tornou padrão no Ubuntu e outras distribuições como Debian, Fedora e Arch, o sudo transformou a administração de sistemas.

  • Permite múltiplos administradores com rastreabilidade.
  • Reduz riscos de comprometimento da senha de root.
  • Facilita o trabalho de equipes DevOps com políticas definidas.
  • Está presente em servidores, desktops e dispositivos embarcados.

Hoje, o sudo é considerado uma ferramenta fundamental para segurança e conformidade, sendo auditado em normas como PCI-DSS e ISO 27001.

O futuro das permissões e controle Linux

Apesar de sua solidez, o sudo enfrenta novos desafios. Surgiram alternativas como o doas, oriundo do OpenBSD, com uma filosofia minimalista. Algumas distros experimentam modelos baseados em políticas como o polkit ou soluções baseadas em containers.

No entanto, o sudo continua evoluindo. Suporte aprimorado a logs estruturados, integração com autenticação moderna e melhorias em desempenho são áreas ativas no desenvolvimento atual.

Conclusão

A criação do comando sudo não foi apenas um marco técnico, mas uma mudança cultural na forma como o Linux e os sistemas Unix lidam com permissões e controle. Ele substituiu a fragilidade do su por um modelo granular, auditável e adaptável. Com décadas de desenvolvimento, o sudo permanece essencial para a segurança de sistemas, e seu impacto será sentido por muitos anos ainda.

Compartilhe este artigo