Execução com privilégios mínimos e disciplina no sudo

A maioria das violações de segurança em automações acontece não por causa de explorações exóticas, mas porque os scripts são executados com mais privilégios do que precisam. Um trabalho do cron executado como root que só precisa alternar um arquivo de registro é um acidente prestes a acontecer.

O princípio do menor privilégio afirma: todo processo deve operar usando somente as permissões necessárias para realizar sua tarefa — e nada além disso. Em scripts Bash, isso significa:

• Executar como um usuário sem privilégios sempre que possível
• Elevar para root somente nos comandos específicos que exigem isso
• Remover os privilégios assim que o trabalho elevado terminar
• Nunca armazenar nem herdar credenciais além do seu escopo

Esta lição apresenta as técnicas concretas: delimitação de sudo, remoção de privilégios com su, proteções de validação de UID e reforço do sudoers — construindo um modelo disciplinado de privilégios para scripts de produção.

Antes de qualquer bloco de código que realmente exija root, seu script deve verificar se está sendo executado com o UID efetivo esperado. Nunca presuma; sempre faça uma asserção.

$EUID é uma variável especial do Bash que contém o ID de usuário efetivo do processo atual. Root sempre tem EUID 0. Verificá-lo no início de um script — ou ao redor de um bloco privilegiado — impede a execução acidental sob a identidade errada.

Use este padrão de proteção:

Alguns scripts precisam legitimamente de root. Nesse caso, a proteção é invertida: falhe imediatamente se root estiver ausente, em vez de deixar o script chegar a uma chamada de sistema privilegiada e produzir um erro de permissão confuso no meio da execução.

Combinar a saída antecipada com uma mensagem de uso útil torna os scripts autoexplicativos:

O erro mais comum é colocar sudo no início de um script e então executar tudo como root. Em vez disso, aplique sudo somente ao comando exato que precisa dele — todo o restante é executado como seu usuário normal.

Isso limita o alcance do dano: se um invasor injetar código no seu script, ele só poderá executar com permissões de root as partes que não têm sudo à frente.

Compare os dois padrões abaixo. O segundo é muito mais seguro:

Chamar sudo somecommand em um script só funciona com segurança se o arquivo sudoers estiver configurado para permitir exatamente esse comando — e nada mais. Evite regras como ALL=(ALL) NOPASSWD: ALL para contas de serviço.

Em vez disso, restrinja as regras a comandos específicos com argumentos específicos, usando a sintaxe segura para visudo. Campos importantes em uma regra do sudoers:

• Usuário — quem pode invocar o sudo
• Host — em qual máquina (use ALL para portabilidade)
• RunAs — qual identidade assumir (quase sempre root)
• Comando — caminho absoluto completo, opcionalmente com argumentos literais

Exemplos de regras rigorosas para uma conta de serviço de implantação (deployer):

Quando um script começa como root (por exemplo, iniciado por um sistema de inicialização ou pelo cron executado como root), mas a maior parte do trabalho deve ocorrer como um usuário sem privilégios, remova os privilégios explicitamente em vez de executar o script inteiro como root.

Duas ferramentas para isso:

• su -s /bin/bash -c 'command' username — inicia um shell como username e executa o comando
• runuser -u username -- command args — preferível no Linux para alternar dentro de scripts pertencentes ao root; é mais limpo que su

O padrão abaixo mostra um encapsulador de implantação pertencente ao root que muda para o usuário app para executar a lógica real da aplicação:

Nem sempre é necessário mudar para uma sessão completa de shell. sudo -u username command executa um único comando como o usuário especificado e depois retorna à identidade que fez a chamada. Isso é útil para manipular arquivos pertencentes a uma conta de serviço sem conceder a essa conta qualquer acesso interativo.

Combine isso com uma regra do sudoers que permita exatamente essa combinação de usuário e comando:

Uma superfície de ataque sutil são as variáveis de ambiente herdadas por uma sessão do sudo. Por padrão, o sudo redefine o ambiente, mas substituições env_keep ou env_reset configuradas incorretamente podem passar variáveis controladas pelo invasor, como LD_PRELOAD, PATH ou PYTHONPATH, para comandos privilegiados.

Boas práticas:

• Sempre use caminhos absolutos em scripts executados sob sudo — nunca dependa de $PATH
• Passe somente as variáveis de que você precisa explicitamente: sudo env VAR=value /path/to/cmd
• No sudoers, evite env_keep += PATH ou env_keep += LD_*
• Use sudo -E somente quando você controlar e confiar completamente no ambiente que faz a chamada

Mesmo quando uma regra do sudoers permite um script específico, argumentos arbitrários ainda podem ser passados a esse script, a menos que a regra também os restrinja. Uma armadilha comum:

deployer ALL=(root) NOPASSWD: /opt/scripts/manage.sh

Isso permite sudo /opt/scripts/manage.sh restart — mas também sudo /opt/scripts/manage.sh --arbitrary-flag. Se manage.sh passar argumentos cegamente para subprocessos privilegiados, você terá um problema.

Faça uma defesa em profundidade: valide os argumentos dentro do script privilegiado e também no sudoers:

Quando um script precisa manter temporariamente um arquivo, uma credencial ou um recurso privilegiado, use o trap do Bash para garantir que a limpeza ocorra mesmo em caso de erro ou sinal. Isso evita o vazamento de privilégios — por exemplo, um binário setuid temporário ou um soquete pertencente ao root que permaneça no sistema se o script falhar.

O padrão abaixo cria um arquivo temporário como root, usa-o e depois o remove — algo garantido por uma armadilha em EXIT:

O princípio do menor privilégio é mais fácil de aplicar quando cada evento de elevação é registrado com contexto: quem executou o quê, quando e por quê. Combine duas camadas:

1. o próprio sudo — /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL) registra automaticamente cada chamada de sudo
2. registro de auditoria no nível do script — grave uma entrada estruturada no início de cada função privilegiada para que a intenção seja registrada junto com o registro do sistema

Usar uma função simples para registros estruturados mantém as trilhas de auditoria consistentes e fáceis de pesquisar com grep:

Teste sua compreensão sobre a execução com menor privilégio em scripts Bash.

Nesta lição, você aprendeu as técnicas para executar scripts Bash com o privilégio mínimo necessário em cada etapa. Veja um resumo conciso dos princípios fundamentais:

• Proteja com $EUID — falhe rapidamente se o script estiver sendo executado com a identidade incorreta, seja por precisar recusar o root, seja por exigir essa identidade
• Limite o escopo do sudo a comandos individuais — nunca eleve um script inteiro; aplique sudo somente às linhas que realmente precisam dele
• Escreva regras sudoers restritas — especifique caminhos absolutos completos e argumentos literais; evite curingas e ALL
• Abandone privilégios com runuser ou sudo -u — quando um script iniciado como root precisar transferir o controle para um usuário sem privilégios, use a ferramenta adequada em vez de executar tudo como root
• Use caminhos absolutos — nunca dependa de $PATH dentro de código privilegiado; defina os caminhos dos binários para evitar sequestros
• Valide os argumentos dentro dos scripts privilegiados — as regras sudoers são a primeira linha de defesa, não a única; use listas de permissões
• Crie armadilhas e faça a limpeza — use trap cleanup EXIT para garantir que recursos privilegiados temporários sejam destruídos mesmo em caso de erro
• Registre cada elevação — entradas de auditoria estruturadas, combinadas ao syslog integrado do sudo, oferecem rastreabilidade para cada ação privilegiada

Aplicadas de forma consistente, essas práticas reduzem a superfície de ataque da sua automação de root o tempo todo para root somente onde for comprovadamente necessário — uma característica marcante de um Bash robusto e adequado para produção.