Política do sudo em arquivos drop-in em /etc/sudoers.d, verificados com visudo -c

Objetivo

Conceder a uma conta o menor privilégio de sudo possível, na forma de um arquivo fácil de revisar, sem arriscar um arquivo sudoers quebrado que bloqueie o acesso administrativo.

Pré-requisitos

Acesso root ou uma conta com sudo já funcionando; saber exatamente quais comandos a conta de destino precisa executar e com qual usuário.

Passos

1. Nunca edite /etc/sudoers nem arquivos em /etc/sudoers.d/ com um editor comum diretamente no arquivo em uso; passe sempre pelo visudo, que bloqueia o arquivo e valida a sintaxe antes de salvar: visudo -f /etc/sudoers.d/deploy-restart.
2. Escreva a regra mais restrita que atenda à necessidade: um comando específico, argumentos específicos e um usuário de destino específico, não ALL: deploy ALL=(root) /usr/bin/systemctl restart myapp.service Evite NOPASSWD:ALL ou uma lista de comandos sem restrição; ambos permitem que o beneficiário execute qualquer coisa como root, inclusive editar arquivos para conceder a si mesmo mais privilégios, o que anula o propósito de restringir a regra. Se o alvo do sudo for um script, trate-o como o verdadeiro limite de privilégio: tudo o que esse script puder ser induzido a fazer será executado como root.
3. Atenção ao nome do arquivo: o sudo ignora arquivos em /etc/sudoers.d/ cujo nome termina em ~ ou contém um .; assim, deploy.conf é ignorado silenciosamente, enquanto deploy-restart é lido. Mantenha o modo 0440, com root como dono. Valide o arquivo sem aplicá-lo, o que é útil em uma implantação não interativa ou automatizada: visudo -c -f /etc/sudoers.d/deploy-restart faz apenas a verificação de sintaxe e informa os erros sem abrir um editor.
4. Confirme que a regra é respeitada, a partir da conta de destino: sudo -l -U deploy lista o que ela pode executar; sudo -u deploy sudo /usr/bin/systemctl restart myapp.service testa a regra diretamente.
5. Verifique o que o sudo realmente registra: as chamadas do sudo, bem-sucedidas ou não, vão por padrão para o journal/syslog do sistema por meio da facility authpriv/auth; consulte com journalctl -t sudo ou com o log de e-mail/segurança da distribuição.

Resultado esperado

visudo -c não informa erros de sintaxe; sudo -l -U deploy mostra exatamente o comando pretendido e nada mais amplo; o journal tem uma entrada para cada uso.

Limites e base de verificação

Baseado em sudoers(5) e visudo(8). Para desfazer, remova o arquivo drop-in (rm /etc/sudoers.d/deploy-restart); nunca remova o próprio arquivo base /etc/sudoers. Como o visudo bloqueia o arquivo e o valida, um erro cometido nele não pode corromper a política em uso; essa mesma proteção não vale para um arquivo editado fora do visudo e só verificado depois. Por isso, crie ou edite sempre o conteúdo do sudoers com visudo -f, e não com um editor separado seguido de uma verificação com visudo -c.