SUID e SGID no Linux

SUID (Set User ID) e SGID (Set Group ID) são bits especiais de permissão utilizados em sistemas Linux e Unix-like para alterar temporariamente o contexto de execução de arquivos executáveis e diretórios.

Esses mecanismos permitem que processos sejam executados com permissões diferentes das do usuário que iniciou a execução, sendo amplamente utilizados em ferramentas administrativas e controle de compartilhamento de arquivos.

O uso incorreto de SUID e SGID representa risco de escalonamento de privilégios e comprometimento do sistema.

Modelo tradicional de permissões

No Linux, permissões convencionais são divididas em:

• Usuário proprietário (user)
• Grupo proprietário (group)
• Outros usuários (others)

Cada entidade possui permissões de:

• Leitura (r)
• Escrita (w)
• Execução (x)

Exemplo:

-rwxr-xr--

Representação numérica:

754

Onde:

SUID (Set User ID)

Conceito

O bit SUID faz com que um executável seja executado com o UID do proprietário do arquivo, e não com o UID do usuário que iniciou o processo.

Isso permite delegar operações privilegiadas de forma controlada.

Funcionamento

Considere o comando:

passwd

Usuários comuns conseguem alterar a própria senha, embora o arquivo de senhas pertença ao root.

Isso ocorre porque o binário possui SUID:

ls -l /usr/bin/passwd

Saída típica:

-rwsr-xr-x 1 root root ...

O caractere s na posição de execução do proprietário indica SUID ativo.

Durante a execução:

• Usuário real (real UID) permanece o usuário autenticado
• Usuário efetivo (effective UID) torna-se o proprietário do arquivo

Nesse caso:

effective UID = root

Definição de SUID

Via chmod simbólico

chmod u+s arquivo

Via chmod numérico

chmod 4755 arquivo

O número 4 representa SUID.

Exemplo prático

Arquivo:

-rwxr-xr-x script

Aplicando SUID:

chmod 4755 script

Resultado:

-rwsr-xr-x script

SGID (Set Group ID)

Conceito

O SGID altera o GID efetivo do processo para o grupo proprietário do arquivo durante a execução.

Também possui comportamento específico em diretórios.

SGID em executáveis

Quando aplicado em executáveis:

-rwxr-sr-x

O processo assume temporariamente o grupo do arquivo.

Exemplo:

chmod 2755 binario

O número 2 representa SGID.

SGID em diretórios

Em diretórios, SGID possui comportamento diferente:

• Novos arquivos herdam o grupo do diretório
• Subdiretórios também herdam SGID

Isso é útil em ambientes colaborativos.

Exemplo:

chmod 2775 projetos

Arquivos criados dentro de projetos herdarão automaticamente o grupo do diretório.

Representação numérica

Combinação:

chmod 6755 arquivo

Equivale a:

• SUID ativo
• SGID ativo
• Permissões 755

Representação textual

Exemplo incorreto:

-rwSr--r--

O S maiúsculo indica que SUID existe, mas o bit de execução não está presente.

Localização de arquivos SUID e SGID

Arquivos SUID

find / -perm -4000 2>/dev/null

Arquivos SGID

find / -perm -2000 2>/dev/null

Riscos de segurança

SUID e SGID aumentam significativamente a superfície de ataque do sistema.

Problemas comuns:

• Escalonamento de privilégios
• Execução arbitrária como root
• Exploração de buffer overflow
• Abuso de chamadas inseguras
• Execução de shell privilegiado

Binários SUID vulneráveis frequentemente resultam em comprometimento total do sistema.

Boas práticas

Minimizar uso de SUID

Aplicar apenas quando estritamente necessário.

Evitar scripts com SUID

A maioria dos kernels ignora SUID em scripts por questões de segurança.

O uso deve se restringir a binários compilados.

Auditar arquivos privilegiados

Revisar periodicamente:

find / -perm -4000 -o -perm -2000

Restringir permissões

Não conceder escrita para usuários comuns em arquivos ou diretórios relacionados a executáveis SUID/SGID.

Utilizar capabilities quando possível

Linux capabilities permitem granularidade mais fina que SUID.

Exemplo:

setcap cap_net_bind_service=+ep binario

Isso evita execução completa como root.

Diferença entre SUID e sudo

Conclusão

SUID e SGID são mecanismos fundamentais do modelo de permissões Unix para delegação controlada de privilégios.

Apesar de úteis, representam risco elevado quando aplicados incorretamente. O uso deve ser restrito, auditado regularmente e substituído por alternativas mais modernas, como Linux capabilities e políticas controladas via sudo, sempre que possível.