Em quais cenários eu gostaria de definir um bit SUID?

Question

Estou lutando para entender o conceito de bits SUID e por que eles seriam úteis.

Por exemplo, digamos que eu tenha um programa:

-rwsr-xr-x 1 root root 12364 Jan 12 2013 /usr/bin/foo

Meu entendimento é que o sbit de execução para o proprietário do usuário significa essencialmente que o arquivo pode ser executado por outros usuários com a autoridade do proprietário do arquivo.

Por que eu iria querer algo assim? Por que não apenas alterar o grupo do arquivo para que funcione para um grupo ao qual todos os usuários pertencem?

Answer 1

Setuid e setgid (e setcap onde existe) são as únicas maneiras de elevar privilégios. Exceto através deste mecanismo, um processo pode abrir mão de privilégios, mas nunca obtê-los. Portanto, você não poderá fazer nada que exija privilégios adicionais.

Por exemplo, os programas sue sudoprecisam ser capazes de executar comandos como qualquer usuário. Portanto, eles precisam ser executados como root, não importa qual usuário os tenha chamado.

Outro exemplo é ping. Os soquetes TCP e UDP são acessíveis a qualquer usuário, pois esses protocolos possuem noção de portas, e um processo pode assumir o controle de uma porta (o que é chamado de ligação), para que o kernel saiba para onde enviar os pacotes. O ICMP não tem essa noção, portanto, apenas programas executados como root (ou com a capacidade apropriada) podem solicitar que pacotes ICMP sejam despachados para eles. Para que qualquer usuário possa executar ping, o pingprograma precisa ter um privilégio adicional, por isso é setuid root (ou setcap).

Para obter um exemplo de privilégios de grupo, considere um jogo que armazena pontuações mais altas locais em um arquivo. Como apenas as pontuações mais altas alcançadas pelos usuários devem ser armazenadas no arquivo de pontuação, o arquivo de pontuação não deve ser gravável pelos jogadores. Somente o programa do jogo deve ter permissão para gravar no arquivo de pontuação. Portanto, o programa do jogo é definido como setgid gamese o arquivo de pontuação pode ser gravado pelo grupo, gamesmas não pelos jogadores.

Existe uma abordagem alternativa para elevar permissões, que é iniciar programas que exigem privilégios adicionais de um programa inicializador privilegiado. Quando um usuário deseja executar uma tarefa que requer privilégios adicionais, ele executa um programa front-end que utiliza alguma forma de comunicação entre processos para executar a ação privilegiada. Isso funciona bem para alguns casos de uso, como ping(um pingprograma para analisar opções e relatar o progresso e um ping-backendserviço que envia e recebe pacotes), mas não para outros casos de uso, como o arquivo de pontuação mais alta do jogo.

Answer 2

O motivo mais comum é que um executável possa ser executado como root. Por exemplo:

find /bin/ -type f \( -perm -4000 -o -perm -2000 \) -ls  | awk '{print $3,$NF}'
-rwsr-xr-x /bin/su
-rwsr-xr-x /bin/mount
-rwsr-xr-- /bin/fusermount
-rwsr-xr-x /bin/ping6
-rwsr-xr-x /bin/ping
-rwsr-xr-x /bin/umount

Todos esses são comandos que podem ser executados por usuários regulares, mas precisam de privilégios elevados. mounté um exemplo perfeito, você pode montar qualquer disco que tenha a useropção ou similar definida, /etc/fstabmas a montagem precisa rootde privilégios para que o bit SUID seja definido.

Answer 3

O bit suid (ou sgid) faz com que um executável seja executado como um usuário/grupo diferente do usuário que o invoca.

Se a única razão para isso for acessar um arquivo específico, sim, você pode usar outros mecanismos para tornar esse arquivo gravável. No entanto, então o usuário poderia fazerqualquer coisaao arquivo - em vez de apenas coisas que seu programa permite.

Você poderia, por exemplo, fazer com que seu programa permitisse apenas anexar uma linha a um arquivo e apenas em um determinado formato. Mas se você apenas usasse permissões do sistema de arquivos, o usuário também poderia excluir linhas do arquivo. Ou coloque linhas mal formatadas.

Basicamente, um programa suid pode impor políticas arbitrárias. As permissões do sistema de arquivos não podem. Por exemplo, seu sistema possui um programa suid /bin/su. Ele fornece um shell de root (por exemplo), mas somente se você atender a uma política primeiro – normalmente, digite a senha de root. Não há como fazer isso apenas com permissões.

Answer 4

Para mim, o exemplo mais simples é o comando passwd. Este comando permite que qualquer usuário altere sua própria senha sem a necessidade de privilégios de root. No entanto, o arquivo no qual todas as senhas estão armazenadas só pode ser gravado pelo root.

Poderíamos simplesmente definir os direitos do shadow para 666 para que qualquer pessoa pudesse alterar o conteúdo, mas isso seria uma terrível falha de segurança. Daí a necessidade do SUID. Isso torna possível conceder privilégios elevados a qualquer usuário de maneira controlada, pois eles só podem alterar o arquivo Shadow através do script passwd. O próprio script garante que o usuário não possa alterar a senha de outra pessoa.

É claro que o passwd deve ser protegido contra gravação. Caso contrário, o usuário poderá alterar este arquivo e usá-lo para executar scripts com privilégios de root.