A auditoria de permissões é uma das atividades mais críticas para manter a integridade e a segurança de um ambiente Linux. Embora a configuração inicial dos serviços seja cuidadosa, o ciclo de vida do software é dinâmico: pacotes são atualizados, usuários são removidos e scripts são criados por desenvolvedores apressados. Nesse processo, permissões especiais como SUID (Set User ID) e SGID (Set Group ID) podem ser atribuídas inadvertidamente a arquivos que não as necessitam, criando vetores de ataque potenciais.
Arquivos com bit SUID executam o binário como se fossem o dono do arquivo (geralmente root). Já os com SGID executam como o grupo proprietário. Quando esses arquivos ficam "órfãos" — ou seja, quando o usuário ou grupo proprietário foi removido do sistema, mas o bit de permissão especial permanece — eles representam um risco significativo. Um atacante pode explorar esses binários para elevar privilégios ou executar código arbitrário com direitos elevados, mesmo que a conta original não exista mais.
Neste tutorial, você aprenderá a identificar, analisar e remediar arquivos SUID/SGID órfãos em sistemas Linux. Vamos utilizar comandos nativos do find e técnicas de validação para garantir que sua infraestrutura esteja em conformidade com as melhores práticas de hardening.
1. Entendendo o Risco dos Bits SUID e SGID
Antes de iniciar a auditoria, é fundamental compreender por que esses bits são perigosos em arquivos não essenciais. O bit SUID permite que um usuário comum execute um programa com os privilégios do proprietário (geralmente root). Isso é necessário para comandos como passwd ou sudo, que precisam modificar arquivos protegidos.
No entanto, se um administrador criar um script personalizado ou copiar um binário sem verificar as permissões, ele pode acabar com o bit SUID ativo. Se o dono desse arquivo for excluído do sistema (por exemplo, uma conta de serviço desativada), o arquivo torna-se órfão. O sistema ainda tentará executar o binário com os privilégios do UID original, mas como esse UID não mapeia para nenhum usuário válido, a gestão de logs e auditoria fica comprometida.
O bit SGID funciona de forma similar, mas afeta o grupo. Em diretórios, ele garante que novos arquivos criados herdem o grupo do diretório. Em binários, permite execução com os privilégios do grupo proprietário. Arquivos SGID órfãos podem permitir que usuários autenticados executem código pertencente a um grupo inexistente, potencialmente contornando controles de acesso baseados em grupos.
2. Preparação do Ambiente e Verificação Prévia
A auditoria deve ser realizada com cautela. Embora os comandos de busca sejam seguros por si só, a remoção ou alteração de permissões requer validação prévia para evitar a quebra de serviços críticos.
Primeiro, certifique-se de ter acesso root ou privilégios sudo suficientes. Execute os seguintes passos para verificar o estado atual do sistema:
- Faça um backup das configurações de permissões atuais (opcional, mas recomendado):
find / -type f \( -perm -4000 -o -perm -2000 \) > /tmp/suid_sgid_backup.txt 2>/dev/nullEste comando gera uma lista completa de todos os arquivos SUID e SGID no sistema. Salve este arquivo em um local seguro para comparação futura.
- Verifique se há usuários ou grupos órfãos no sistema:
awk -F: '($3 == 0) {print $1}' /etc/passwdO comando acima lista usuários com UID 0 (root). Em seguida, verifique se há arquivos apontando para UIDs ou GIDs que não existem mais no /etc/passwd ou /etc/group.
3. Identificando Arquivos SUID/SGID Órfãos
A ferramenta principal para essa tarefa é o comando find. Ele permite buscar arquivos com base em permissões específicas e cruzar esses dados com a existência dos proprietários.
3.1. Encontrando Arquivos SUID sem Dono Válido
Para encontrar arquivos com o bit SUID definido, mas cujo dono não existe mais no sistema, utilize a seguinte abordagem:
find / -xdev -type f -perm -4000 2>/dev/null | while read file; do
owner=$(stat -c '%u' "$file")
if ! getent passwd "$owner" &>/dev/null; then
echo "SUID Órfão: $file (UID: $owner)"
fi
doneExplicação dos componentes:
-xdev: Impede que ofinddesça em outros sistemas de arquivos (como /proc, /sys ou partições montadas externamente), evitando erros de permissão e melhorando a performance.-type f: Busca apenas arquivos regulares, ignorando diretórios.-perm -4000: Seleciona arquivos com o bit SUID ativo.stat -c '%u': Obtém o UID numérico do arquivo.getent passwd "$owner": Verifica se esse UID corresponde a um usuário existente no sistema.
3.2. Encontrando Arquivos SGID sem Grupo Válido
O processo para arquivos SGID é análogo, mas utiliza o GID e o banco de dados de grupos:
find / -xdev -type f -perm -2000 2>/dev/null | while read file; do
group=$(stat -c '%g' "$file")
if ! getent group "$group" &>/dev/null; then
echo "SGID Órfão: $file (GID: $group)"
fi
doneEsses scripts podem levar algum tempo em sistemas com muitos discos. Se você precisar de uma solução mais rápida para um diretório específico, remova o / e especifique o caminho, como /usr/bin.
4. Análise Manual dos Resultados
Após executar as buscas, você provavelmente obterá uma lista de arquivos. Não remova ou altere permissões imediatamente. A etapa seguinte é a análise crítica.
Verifique se o arquivo é essencial:
file /caminho/para/o/arquivo
ls -l /caminho/para/o/arquivoMuitas vezes, arquivos SUID/SGID são partes legítimas de pacotes do sistema (como sudo, ping, mount) ou aplicativos instalados via repositórios confiáveis. Se o arquivo pertencer a um pacote conhecido e o UID/GID órfão for resultado de uma migração de sistema mal gerenciada, a prioridade é corrigir a propriedade, não remover o bit.
Identifique scripts personalizados:
Se o arquivo for um script (bash, python, perl) ou um binário localizado em diretórios incomuns (como /home ou /tmp), o risco é alto. Scripts com SUID são particularmente perigosos, pois permitem injeção de variáveis de ambiente e manipulação de caminhos PATH.
Confira a origem do arquivo:
rpm -qf /caminho/para/o/arquivo # No Debian/Ubuntu, use: dpkg -S /caminho/para/o/arquivoSe o comando retornar "não é um arquivo de pacote", significa que o arquivo foi criado manualmente ou copiado. Nesse caso, a remoção do bit SUID/SGID é quase sempre a ação correta.
5. Remediação e Hardening
Com base na análise, aplique as correções. O objetivo é garantir que apenas binários estritamente necessários mantenham os bits especiais, e que todos eles tenham donos válidos.
5.1. Removendo Bits SUID/SGID de Arquivos Não Essenciais
Para remover o bit SUID de um arquivo identificado como desnecessário:
chmod u-s /caminho/para/o/arquivoPara remover o bit SGID:
chmod g-s /caminho/para/o/arquivoSe você quiser remover ambos os bits simultaneamente de todos os arquivos em um diretório específico (com cuidado):
find /diretorio/seguro -type f \( -perm -4000 -o -perm -2000 \) -exec chmod u-s,g-s {} \;5.2. Corrigindo Propriedade de Arquivos Órfãos
Se um arquivo SUID/SGID for essencial, mas o dono foi removido, você deve reatribuir a propriedade para um usuário ou grupo válido:
chown root:root /caminho/para/o/arquivoIsso garante que o bit SUID execute o binário como root (ou o novo dono), e que os logs de auditoria registrem corretamente a atividade.
5.3. Implementando Controles Preventivos
Para evitar que novos arquivos órfãos apareçam, considere as seguintes práticas:
- Auditoria Automatizada: Agende um script
cronsemanal para rodar a busca de arquivos SUID/SGID e envie os resultados por e-mail. - Selinux/AppArmor: Ative mecanismos de controle de acesso obrigatório (MAC). Eles restringem o que mesmo binários com SUID podem fazer, mitigando danos caso uma vulnerabilidade seja explorada.
- Gestão de Configuração: Use ferramentas como Ansible, Puppet ou SaltStack para garantir que as permissões sejam definidas declarativamente e corrigidas automaticamente se desviarem do padrão.
6. Validação Pós-Correção
Após aplicar as correções, execute novamente os comandos de busca para garantir que nenhum arquivo órfão permaneça:
find / -xdev -type f \( -perm -4000 -o -perm -2000 \) 2>/dev/null | wc -lCompare o número total de arquivos SUID/SGID com a lista inicial. O número deve ter diminuído ou permanecido estável, dependendo se você apenas corrigiu propriedades ou removeu bits.
Além disso, teste as funcionalidades críticas do sistema que dependiam desses arquivos para garantir que a remoção dos bits não quebrou serviços essenciais. Por exemplo, verifique se o login de usuários e a execução de sudo continuam funcionando normalmente.
Conclusão
A auditoria de permissões SUID/SGID é uma tarefa contínua e essencial para a segurança do Linux. Arquivos órfãos representam uma brecha silenciosa que pode ser explorada para escalonamento de privilégios. Ao seguir os passos descritos — identificar, analisar, remediar e prevenir — você fortalece significativamente a postura de segurança do seu servidor.
Lembre-se: o princípio do menor privilégio deve guiar todas as suas ações. Se um arquivo não precisa executar com privilégios elevados, remova o bit SUID/SGID imediatamente. Em caso de dúvida, consulte a documentação do pacote ou entre em contato com os desenvolvedores responsáveis pela aplicação.
Manter seu sistema limpo dessas configurações residuais não apenas atende a requisitos de conformidade (como PCI-DSS e ISO 27001), mas também reduz drasticamente a superfície de ataque disponível para ameaças internas e externas.