Ubuntu 26.04: o que muda no sudoers com sudo-rs

O que o sudo-rs altera no Ubuntu

O Ubuntu 26.04 LTS inclui o sudo-rs como sudo predefinido. Por isso, o comando sudo num servidor acabado de instalar executa a reimplementação em Rust, e não o programa original em C. A maioria dos ficheiros sudoers continua a funcionar exatamente como antes. A regra que deixa de funcionar é a que contém um curinga nos argumentos de um comando, porque o sudo-rs não compara padrões glob com o texto dos argumentos.

O Ubuntu 25.10 fez primeiro esta mudança, e o Ubuntu 26.04 LTS manteve-a. O Ubuntu 24.04 LTS não é afetado, porque continua a selecionar o sudo original, exceto se instalar o sudo-rs manualmente. Isto torna-se relevante quando atualizar do Ubuntu 24.04 para o 26.04, ou quando preparar um novo servidor na versão mais recente. Se também utiliza versões intermédias, como diferem as versões LTS e intermédias do Ubuntu num servidor explica qual das máquinas encontra primeiro uma alteração deste tipo.

Verifique qual sudo o servidor está realmente a executar

Não deduza isto pelo número da versão. Consulte a própria máquina.

sudo --version
update-alternatives --config sudo
dpkg -l 'sudo*'

Confie no sudo --version da sua própria máquina, e não em qualquer tabela de versões na Internet, incluindo esta página. update-alternatives --config sudo é a outra parte da resposta: lista todos os fornecedores instalados de /usr/bin/sudo e assinala o selecionado. Um pacote estar instalado não significa que esteja selecionado. Por isso, consulte a seleção, não a lista de pacotes.

As duas implementações são empacotadas durante a transição. A implementação em Rust é sudo-rs, na versão 0.2.13 no 26.04, em agosto de 2026. A implementação original, mantida por Todd C. Miller, continua a ser o pacote sudo. A alteração é que os seus programas têm o sufixo .ws, para que ambas possam ser instaladas ao mesmo tempo: /usr/bin/sudo.ws e /usr/bin/visudo.ws, juntamente com cvtsudoers.ws e sudoreplay.ws. Verificado no arquivo do 26.04 em setembro de 2026: dpkg -L sudo lista os binários com sufixo, e sudo-rs disponibiliza /usr/bin/sudo-rs juntamente com eles.

Por que o Ubuntu mudou para sudo-rs

sudo usa setuid root. Qualquer utilizador no sistema pode iniciá-lo, e ele começa com privilégios completos. Por isso, um erro de memória dentro dele pode permitir uma exploração local para obter root. A CVE-2021-3156 foi exatamente isso: um overflow de buffer na heap acessível a qualquer utilizador local. O problema permaneceu no código distribuído durante cerca de dez anos. O Rust deteta essa classe de erro em tempo de compilação. Esse é o principal motivo da reescrita.

O segundo motivo é o escopo. É também o motivo que afeta a sua configuração. O sudo original acumulou um conjunto amplo de funcionalidades ao longo de três décadas. Cada funcionalidade representa mais código executado como root. O sudo-rs implementa um subconjunto de propósito. Os autores deixaram de fora tudo o que consideraram pouco utilizado ou potencialmente prejudicial. Por isso, uma construção do sudoers que funcionou durante anos pode simplesmente não existir. A sua regra com wildcard é um desses casos.

A segurança de memória elimina uma classe de erros. Ela não torna um programa livre de bugs. O sudo-rs também recebeu correções de segurança próprias desde que se tornou o padrão. Aplique as atualizações como faria com qualquer outro software.

Quais regras do sudoers continuam a funcionar

O ficheiro é o mesmo. O sudo-rs lê /etc/sudoers e os ficheiros de inclusão em /etc/sudoers.d/. As regras normalmente escritas por um administrador de servidores são suportadas:

• deploy ALL=(ALL:ALL) ALL e formatos para grupos, como %sudo ALL=(ALL:ALL) ALL
• as tags NOPASSWD: e PASSWD:
• User_Alias, Runas_Alias, Host_Alias e Cmnd_Alias
• um comando com uma lista exata de argumentos, por exemplo /usr/bin/systemctl restart app-api
• um comando seguido de "", que permite o comando apenas sem argumentos
• um comando seguido de * como argumento final, que permite quaisquer argumentos adicionais
• um caminho de diretório terminado em /, que permite qualquer comando nesse diretório
• ! para remover um comando de uma lista
• um subconjunto útil de Defaults, incluindo secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw e use_pty

Dois padrões têm um comportamento diferente e causam problemas. env_reset não pode ser desativado no sudo-rs: está sempre ativo. use_pty está ativo por predefinição, pelo que o comando é executado no seu próprio pseudo-terminal.

Por que a regra sudoers com wildcard deixou de corresponder

Os wildcards continuam permitidos num único local: no nome do ficheiro do comando. Uma regra com %ops ALL = /sbin/fsck* continua a permitir sudo fsck e sudo fsck_exfat, porque * faz parte do caminho que é comparado com o sistema de ficheiros.

Na lista de argumentos, sudo-rs aceita apenas duas formas especiais, e nenhuma delas é um padrão. "" significa que não existem argumentos. Um * no final significa quaisquer argumentos adicionais. Todos os outros argumentos são comparados como texto literal. Por isso, %ops ALL = /sbin/service ntp * é válido: ntp é literal e * está no fim. No entanto, uma regra como esta não concede nada do que pretendia:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart app-*

app-* é um padrão no meio de um argumento. sudo-rs não o expande, por isso a regra não abrange systemctl restart app-api e sudo recusa o comando. Dois comandos mostram o resultado real de qualquer regra no seu servidor: sudo -l -U deploy, executado como root, mostra o que essa conta pode realmente executar, e sudo visudo -c indica se o ficheiro pode ser analisado. Execute-os antes de começar a editar ficheiros ao acaso.

A regra curinga sempre foi uma brecha

No sudo original, os argumentos que você informa são unidos em uma única string e comparados com a string de argumentos da regra usando um glob. Um glob corresponde a espaços em branco. Esse é o ponto que quase todo mundo ignora.

A documentação do sudo-rs apresenta a demonstração mais clara. Uma regra com /bin/rm *.txt também permite sudo rm -rf /home .txt, porque o único * absorve -rf /home e a string unida ainda termina em .txt. A regra é interpretada como "apenas ficheiros de texto". Na prática, significa "quaisquer argumentos, desde que a linha termine em .txt".

O mesmo se aplica ao exemplo com systemctl. Como os argumentos são comparados como uma única string unida, um padrão no final também corresponde ao que for acrescentado depois dele. Portanto, restart app-* permite restart app-api e quaisquer outros argumentos adicionados pelo chamador. Um padrão dentro de um argumento expõe os argumentos que estão à sua volta, e é nos argumentos que reside o poder de um comando. O sudo-rs rejeita essa construção em vez de tentar torná-la segura, porque não existe uma forma geral segura de a utilizar.

Substitua o curinga por uma lista explícita de comandos

A maioria das regras com curingas existe porque alguém não quis escrever quatro linhas. Escreva as quatro linhas.

Cmnd_Alias APP_RESTART = /usr/bin/systemctl restart app-api, /usr/bin/systemctl restart app-worker
Cmnd_Alias APP_STATUS = /usr/bin/systemctl status app-api, /usr/bin/systemctl status app-worker
deploy ALL=(root) NOPASSWD: APP_RESTART, APP_STATUS

Use o caminho correto. Uma regra que indica /bin/systemctl num sistema em que o binário está em /usr/bin/systemctl nunca corresponde, e a falha parece idêntica a um problema de permissões. Confirme com command -v systemctl e cole o resultado.

Coloque a regra no seu próprio ficheiro drop-in, em vez de a colocar em /etc/sudoers. Assim, uma atualização do pacote nunca entra em conflito com a sua edição:

sudo visudo -f /etc/sudoers.d/90-deploy
sudo visudo -c
sudo -l -U deploy

Dê ao ficheiro um nome sem ponto e sem til no fim. O sudo original ignora os ficheiros em sudoers.d cujos nomes contêm um ponto, pelo que 90-deploy.conf é um erro silencioso clássico. Seguir esta convenção não tem qualquer custo.

Use um wrapper pertencente a root quando a lista ficar longa

Quando a lista permitida for demasiado grande para ser incluída diretamente, transfira a decisão do sudoers para um programa pequeno pertencente a root.

sudo tee /usr/local/sbin/app-restart >/dev/null <<'EOF'
#!/bin/sh
set -eu
case "${1:-}" in
  app-api|app-worker) ;;
  *) echo "app-restart: not allowed: ${1:-}" >&2; exit 1 ;;
esac
exec /usr/bin/systemctl restart "$1"
EOF
sudo chown root:root /usr/local/sbin/app-restart
sudo chmod 0755 /usr/local/sbin/app-restart
ls -l /usr/local/sbin/app-restart

No sudoers, indique apenas um comando:

deploy ALL=(root) NOPASSWD: /usr/local/sbin/app-restart *

O * final é aceitável neste caso porque é o script, e não o sudo, que decide o que é permitido. Isto só é válido enquanto o script pertencer a root e não puder ser escrito por nenhuma outra conta. Se deploy puder escrever no ficheiro, deploy poderá substituir o conteúdo e executar qualquer coisa como root, o que é pior do que a regra com wildcard que removeu. Verifique o modo com ls -l. Se o resultado não for claro, aprender a interpretar a string de permissões drwxr-xr-x demora cinco minutos. A mesma regra aplica-se ao diretório: /usr/local/sbin também não pode ter permissões de escrita para essa conta, porque um diretório com permissões de escrita permite substituir o ficheiro inteiro.

Atribua um utilizador próprio ao job em vez de uma regra sudo

A pergunta mais importante costuma ser por que o comando precisa de root. Um serviço executado com o seu próprio utilizador pode ser gerido por esse utilizador, sem envolver nenhuma linha do sudoers. Para unidades do sistema, o systemd já delega essa decisão ao polkit, portanto uma regra pode especificar uma unidade e um operador:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "app-api.service" &&
        subject.user == "deploy") {
        return polkit.Result.YES;
    }
});

Guarde isso como /etc/polkit-1/rules.d/50-app-api.rules, e deploy poderá executar systemctl restart app-api sem usar sudo. Teste a partir do contexto exato que o utilizará, porque vale a pena confirmar uma regra que funciona na sua sessão SSH a partir do cron antes de depender dela. Em qualquer caso, a conta que executa o trabalho deve existir exclusivamente para esse fim. Esse é o mesmo princípio por trás de contas de utilizador com privilégio mínimo numa VPS.

O que o sudo-rs não implementa

sudo -E não está implementado. Declare as variáveis necessárias com Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". Lembre-se de que env_reset está sempre ativo, portanto tudo o que não for mantido é eliminado.

O armazenamento central de sudoers em LDAP foi removido. sudoers.ldap e cvtsudoers não estão implementados, e o pacote sudo-ldap foi removido em 26.04. A autenticação LDAP através de PAM ou SSSD continua a funcionar. O que está fora do âmbito é a parte da política armazenada num diretório.

INTERCEPT, que tentava impedir escapes para a shell a partir de um comando permitido, não está implementado. De qualquer forma, nunca resistiria a um utilizador determinado. Se uma regra permite executar um editor ou um interpretador como root, esse utilizador tem root, e nenhuma opção do sudo altera isso.

A gravação de sessões não está implementada. Por isso, não existe um log de I/O nem sudoreplay. O registo é enviado apenas para o syslog. Não existe a opção logfile para o redirecionar para outro local. As mensagens do sudo são enviadas para o destino já configurado pelo sistema para o syslog.

Deve voltar para sudo.ws?

Pode. Durante o ciclo 26.04, a versão original continua empacotada exatamente por esse motivo.

sudo apt install sudo
update-alternatives --config sudo
sudo update-alternatives --set sudo /usr/bin/sudo.ws

Copie os caminhos exatos da saída de --config, e não desta página, porque essa é a lista que o seu próprio sistema aceitará. Para voltar ao sudo-rs mais tarde, defina a alternativa como o caminho do binário sudo-rs indicado na mesma lista.

Mantenha uma segunda sessão SSH aberta, autenticada e inativa antes de alterar qualquer coisa que afete o sudo. Um ficheiro sudoers que não possa ser analisado, ou uma alternativa que aponte para um binário não instalado, pode deixá-lo sem forma de obter root num sistema remoto. Esse hábito deve fazer parte de tudo o que faz nos primeiros dez minutos num novo VPS.

Trate a reversão como um prazo, e não como uma correção. Ela dá-lhe uma semana para reescrever corretamente as regras. Essa reescrita vale a pena por si só, porque cada regra com wildcard que elimina concedia mais permissões do que o autor percebeu.

FAQ

Por que a regra com curinga do sudoers deixou de funcionar no Ubuntu 26.04?

Porque o Ubuntu 26.04 LTS seleciona o sudo-rs como sudo padrão, e o sudo-rs não corresponde a padrões curinga dentro dos argumentos de um comando. Ele permite um curinga no nome de ficheiro do comando, "" para indicar que não existem argumentos e um único * como argumento final. Uma regra como /usr/bin/systemctl restart app-* coloca um padrão no meio de um argumento. Por isso, não concede permissões e o comando é recusado. Execute sudo -l -U deploy como root para ver as permissões efetivas da conta. Depois, substitua a regra pelos comandos exatos ou por um script wrapper pertencente a root.

Como volto ao sudo original no Ubuntu 26.04?

O original está disponível no pacote sudo, cujos binários têm o sufixo .ws. Instale-o com sudo apt install sudo. Depois, aponte a alternativa para ele com sudo update-alternatives --set sudo /usr/bin/sudo.ws. Execute primeiro update-alternatives --config sudo para consultar os caminhos exatos disponibilizados pelo sistema. Mantenha uma segunda sessão SSH aberta enquanto altera esta configuração. Isto não repõe sudo-ldap, que foi removido do 26.04 independentemente da implementação selecionada.

O sudo-rs lê o mesmo ficheiro /etc/sudoers?

Sim. O sudo-rs lê /etc/sudoers e os ficheiros de inclusão em /etc/sudoers.d/, com a mesma sintaxe para utilizadores, grupos, aliases, especificações run-as e a tag NOPASSWD. Implementa um subconjunto da linguagem sudoers. Por isso, as diferenças manifestam-se pela ausência de determinados elementos, e não por comportamentos diferentes. Edite com sudo visudo. Depois, valide com sudo visudo -c antes de fechar a sessão.

O que substitui sudo -E no sudo-rs?

sudo -E não é implementado. Além disso, já era desaconselhado no sudo original, porque fornecer a um processo root um ambiente controlado pelo chamador é uma forma conhecida de alterar o comportamento desse processo. Em vez disso, indique no sudoers as variáveis de que realmente precisa, com uma linha como Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". env_reset está sempre ativo no sudo-rs e não pode ser desativado. Por isso, todas as variáveis que não forem mantidas são removidas.