Melhores Práticas para Proteger Sistemas de Arquivos Linux com Permissões Especiais

As permissões especiais são um daqueles recursos do Linux que parecem pequenos em ls -l e importam muito em produção. Um s extra em um binário de propriedade do root pode permitir que usuários comuns executem uma tarefa privilegiada restrita. Um t ausente em um diretório de upload compartilhado pode permitir que usuários excluam arquivos uns dos outros. Um bit SGID em um diretório de projeto pode evitar uma enxurrada constante de problemas de propriedade de grupo.

O objetivo não é espalhar bits especiais por toda parte. O objetivo é saber quando SUID, SGID e o sticky bit resolvem um problema real de acesso e quando criam um caminho de privilégio que você lamentará depois.

Compreendendo a Recapitulação das Permissões Padrão

Antes de explorar as permissões especiais, é essencial lembrar a notação tripla padrão (rwx para proprietário, grupo e outros). Essas permissões são representadas numericamente usando valores octais (por exemplo, 755 ou 644).

r (Leitura) = 4
w (Escrita) = 2
x (Execução) = 1

As permissões especiais modificam esse comportamento básico e são representadas por um quarto dígito octal à esquerda (4, 2 ou 1).

As Permissões Especiais: SUID, SGID e o Sticky Bit

As permissões especiais adicionam funcionalidades além do controle de acesso padrão. Elas são geralmente indicadas na saída da listagem longa (ls -l) por um s ou t substituindo o sinalizador x padrão.

Permissão	Valor Octal	Efeito
SUID (Set User ID)	4	O arquivo é executado com as permissões do proprietário do arquivo (não do usuário que o executa).
SGID (Set Group ID)	2	O arquivo é executado com as permissões do grupo do arquivo, ou novos arquivos herdam o ID de grupo do diretório pai.
Sticky Bit	1	Impede que usuários excluam ou renomeiem arquivos de propriedade de outros usuários em um diretório compartilhado, mesmo que tenham permissão de escrita no diretório.

1. Set User ID (SUID)

O bit SUID é poderoso e potencialmente perigoso se mal utilizado. Quando definido em um arquivo executável, qualquer usuário que execute esse arquivo executa o processo com as permissões do proprietário.

Caso de Uso Prático: Utilitários que exigem privilégios de root para executar uma tarefa específica, mas não devem conceder acesso geral de root ao usuário.

Exemplo: SUID em `/usr/bin/passwd`

O comando /usr/bin/passwd normalmente requer acesso root para modificar o arquivo seguro /etc/shadow. Ele tem o bit SUID definido, permitindo que um usuário padrão ganhe temporariamente os privilégios do proprietário (root) apenas durante a execução do passwd para alterar sua própria senha.

Visualizando SUID: Observe o s no slot de execução do proprietário:

ls -l /usr/bin/passwd
# Exemplo de saída: -rwsr-xr-x 1 root root ... /usr/bin/passwd

Definindo SUID: Use o valor octal 4 combinado com permissões padrão (por exemplo, 755 torna-se 4755):

# Supondo que 'my_script' seja de propriedade de 'appuser'
chmod 4755 /caminho/para/meu_script

Aviso de Segurança para SUID: Nunca defina o bit SUID em shells de uso geral (como /bin/bash) ou scripts de manutenção amplos que interpretam entrada externa. Se um script precisar de privilégio, uma regra sudoers restrita, um pequeno auxiliar revisado ou uma API de serviço geralmente é mais seguro.

Ao auditar um host, os arquivos SUID merecem atenção porque são cruzamentos intencionais de privilégio:

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

-xdev mantém a varredura no sistema de arquivos atual, o que é útil quando /proc, backups montados ou sistemas de arquivos de rede tornariam o resultado ruidoso. Em servidores com montagens separadas, verifique cada sistema de arquivos real intencionalmente.

2. Set Group ID (SGID)

O bit SGID tem duas funções principais, dependendo se é aplicado a um arquivo ou a um diretório.

A. SGID em Arquivos Executáveis

Quando definido em um arquivo executável, o processo é executado com as permissões associadas à propriedade de grupo do arquivo, não ao grupo primário do usuário.

B. SGID em Diretórios (Crucial para Ambientes Compartilhados)

Quando definido em um diretório, qualquer novo arquivo ou subdiretório criado dentro dele herda automaticamente a propriedade de grupo do diretório pai, em vez do grupo primário do usuário que criou o novo arquivo.

Caso de Uso Prático: Pastas de projeto compartilhadas onde todos os contribuidores devem ter acesso de grupo unificado para colaboração.

Definindo SGID em um Diretório: Use o valor octal 2 combinado com permissões padrão (por exemplo, 775 torna-se 2775):

# Define a propriedade de grupo como 'developers' e ativa SGID
chgrp developers /srv/projeto_compartilhado
chmod 2775 /srv/projeto_compartilhado

Isso lida com a herança de grupo, mas não garante que todo novo arquivo seja gravável pelo grupo. O umask de um usuário ainda importa. Se os contribuidores criarem arquivos com um umask restritivo como 077, os arquivos podem herdar o grupo developers, mas ainda serem ilegíveis ou não graváveis pelo grupo. Para diretórios compartilhados, verifique o umask esperado, ACLs padrão ou configurações de criação de arquivo em nível de aplicação:

getfacl /srv/projeto_compartilhado
setfacl -d -m g:developers:rwx /srv/projeto_compartilhado

As ACLs padrão são frequentemente a peça que falta em diretórios colaborativos porque aplicam permissões a novos arquivos e diretórios criados abaixo do caminho.

3. O Sticky Bit

O Sticky Bit (ou Atributo de Texto Salvo) é usado quase exclusivamente em diretórios compartilhados para controlar a exclusão de arquivos.

Quando o Sticky Bit está definido em um diretório, apenas o proprietário de um arquivo dentro desse diretório, ou o usuário root, pode excluir ou renomear esse arquivo, mesmo que o próprio diretório permita acesso de escrita para 'outros' (o+w).

Caso de Uso Prático: Diretórios compartilhados públicos como /tmp ou pastas de upload departamentais onde os usuários devem ser capazes de gerenciar apenas os arquivos que criaram.

Exemplo: O Diretório `/tmp`

O diretório /tmp geralmente tem permissões como 1777. O 1 indica que o Sticky Bit está ativo.

ls -ld /tmp
# Exemplo de saída: drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp

O t no final confirma que o sticky bit está definido. Sem ele, qualquer usuário poderia excluir arquivos criados por outros usuários em /tmp.

Definindo o Sticky Bit: Use o valor octal 1 combinado com permissões padrão (por exemplo, 777 torna-se 1777):

chmod 1777 /var/public_uploads

Gerenciamento Abrangente: Combinando Permissões Especiais

As permissões especiais são frequentemente combinadas. O quarto dígito à esquerda é a soma dos bits especiais desejados (4+2+1 = 7).

Permissões Desejadas	Valor Octal
Padrão `rwxr-xr-x` (755)	`755`
SUID + `rwxr-xr-x`	`4755`
SGID + `rwxr-xr-x`	`2755`
Sticky Bit + `rwxrwxrwx`	`1777`
SUID + SGID + Sticky Bit + `rwx` (Raramente necessário)	`7777`

Exemplo Combinando SGID e Sticky Bit para Pastas Compartilhadas:

Para criar um diretório de colaboração compartilhado e seguro, onde todos os usuários fazem parte do grupo 'equipe', novos arquivos herdam o grupo 'equipe' e os usuários não podem excluir os arquivos uns dos outros:

Definir propriedade do grupo: chgrp equipe /dados/projetoX
Aplicar SGID (2) + rwx padrão (7) + Sticky Bit (1) $\rightarrow 2+1 = 3$ para os bits especiais.
- Usando a soma explícita: SGID (2) + Sticky Bit (1) = 3. Permissões padrão 775.
- Comando total: chmod 3775 /dados/projetoX

Ao visualizar isso com ls -ld, você deve ver tanto s na posição de execução do grupo quanto t na posição de execução de outros:

drwxrwsr-t 2 root equipe 4096 Mar 10 11:30 /dados/projetoX

Se o bit de execução estiver ausente, a exibição usa S ou T maiúsculos. Isso geralmente é um sinal de alerta em diretórios, porque a permissão de execução controla se os usuários podem percorrer o diretório.

Erros Comuns que Causam Incidentes Reais

O erro mais perigoso é usar SUID para evitar projetar autorização adequada. Se um script de manutenção precisa girar um arquivo de propriedade da aplicação, não torne todo o script efetivamente root para cada usuário. Dê à aplicação um comando de serviço controlado, use uma regra sudoers restrita ou altere a propriedade para que a conta de serviço possa executar a tarefa sem root.

Outro erro comum é tornar diretórios compartilhados graváveis por todos sem o sticky bit:

chmod 777 /srv/uploads

Isso parece conveniente durante os testes. Em produção, qualquer usuário local que possa acessar o diretório pode ser capaz de renomear ou excluir arquivos de outro usuário. Se o diretório realmente precisa ser gravável por muitos usuários não relacionados, 1777 geralmente é a linha de base mais segura:

chmod 1777 /srv/uploads

Para diretórios de propriedade da equipe, 2775 mais um grupo real geralmente é melhor do que gravação mundial. Adicione o sticky bit apenas se os membros da equipe não devem excluir os arquivos uns dos outros. Algumas equipes desejam direitos de limpeza compartilhados; outras não. O modelo de permissão deve corresponder a esse fluxo de trabalho.

Backups e implantações também podem quebrar permissões especiais. Algumas ferramentas de arquivamento e cópia preservam modos por padrão; outras não, a menos que você passe os sinalizadores corretos. Após restaurar um sistema ou implantar um pacote binário, verifique os bits especiais explicitamente:

stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/projeto_compartilhado

Se /tmp retornar como 0777 em vez de 1777, isso não é uma diferença cosmética. Os usuários podem interferir nos arquivos uns dos outros. Se um bit SUID necessário estiver ausente em um utilitário do sistema, os usuários comuns podem perder repentinamente o comportamento esperado. Se um bit SUID inesperado aparecer em um arquivo em /home, /tmp ou um caminho de upload de aplicação, trate-o como suspeito até prova em contrário.

Auditoria sem se Afogar em Saída

Uma varredura completa do sistema de arquivos pode ser ruidosa, especialmente em máquinas de build e estações de trabalho de desenvolvedores. Comece com as áreas que mais importam:

sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

O primeiro comando revisa locais normais de executáveis. O segundo verifica áreas de rascunho graváveis onde um executável privilegiado seria muito mais preocupante. Em um servidor limpo, arquivos SUID personalizados em caminhos graváveis por todos devem ser raros. Se você encontrar um, verifique a propriedade, a origem do pacote, o horário de modificação e se ele aparece no seu gerenciamento de configuração.

Para diretórios, procure caminhos graváveis por todos sem o sticky bit:

sudo find / -xdev -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null

Isso não significa que todo resultado seja uma violação. Significa que todo resultado merece uma razão. Alguns diretórios de aplicação são intencionalmente graváveis por um grupo de serviço, mas diretórios públicos graváveis sem proteção sticky são uma armadilha comum.

Melhores Práticas para Segurança de Permissões Especiais

Devido aos privilégios elevados que SUID e SGID concedem, eles devem ser gerenciados com extrema cautela.

Limite o Escopo do SUID: Defina SUID apenas em executáveis binários compilados que são necessários para operações padrão (como passwd, ping). Nunca aplique SUID a scripts interpretados (Shell, Python, Perl) a menos que eles sejam encapsulados em um executável wrapper seguro que valide a entrada.

Audite Regularmente: Varra periodicamente o sistema de arquivos em busca de arquivos SUID/SGID incomuns usando o comando find:

# Encontre todos os arquivos com SUID definido
find / -perm /4000 2>/dev/null
# Encontre todos os arquivos com SGID definido
find / -perm /2000 2>/dev/null

Use SGID para Consistência de Grupo: Prefira SGID em vez de gerenciar manualmente a propriedade de grupo de arquivos em estruturas de dados compartilhadas; ele automatiza a herança de grupo.
Sticky Bit para Áreas Graváveis Públicas: O Sticky Bit é essencial para qualquer diretório destinado ao uso geral do usuário onde a exclusão por não proprietários deve ser restrita (por exemplo, /tmp, /var/tmp).
Combine SGID com ACLs quando a colaboração for importante: SGID lida com a propriedade do grupo; ACLs padrão lidam com as permissões que novos arquivos recebem.
Rastreie exceções personalizadas: Se sua organização aprovar um binário SUID ou SGID personalizado, registre o propósito, proprietário, caminho esperado e fonte de implantação. Privilégio misterioso é a parte que dói depois.

As permissões especiais são úteis porque são precisas. Mantenha-as assim. Use SUID para transições estreitas de privilégio, SGID para propriedade compartilhada e o sticky bit para diretórios compartilhados onde os direitos de exclusão precisam de proteções.