Por que os privs precisam ser setgid () para grupos suplementares

Question

As várias chamadas do sistema set*gid() requerem privilégios para alterar grupos, exceto em poucos casos. Alterar o grupo primário para um dos grupos suplementares dos processos não parece ser um deles, o que significa que os comandos newgrp / sg , por exemplo, precisam elevar os privilégios para alternar o grupo principal.

Existe uma razão pela qual setgid() / setegid() / setregid() / setfsgid() não permite a mudança para um grupo suplementar sem privs? Se sim, qual é o motivo?

    

Answer 1

Naturalmente, o quebra-cabeça fundamental aqui é que as verificações de permissão do sistema de arquivos são baseadas na combinação de (o UID efetivo e) o GID efetivo e os GIDs suplementares. Portanto, do ponto de vista das verificações de permissões de arquivo, o GID efetivo é equivalente aos GIDs suplementares, o que leva à pergunta do OP. (De passagem: se estamos falando de Linux, na verdade é o UID / GID do sistema de arquivos que é usado nas verificações de permissões do sistema de arquivos, em vez do UID e GID efetivo, mas os IDs anteriores quase sempre têm os mesmos valores dos últimos IDs. )

Portanto, deve haver alguns casos em que os GIDs reais / efetivos / salvos não são equivalentes aos GIDs suplementares. (Agrupar os GIDs reais / efetivos / salvos em conjunto, porque as regras normais de permissão * gid () definem que um processo sem privilégios pode alterar qualquer um desses GIDs para o mesmo valor que um dos outros dois.)

E, de fato, existem alguns casos desse tipo. access (2) faz suas verificações com base no ID do usuário e no ID do grupo real . Se um usuário não privilegiado foi capaz de alterar o ID do grupo real para ser o mesmo que um dos GIDs suplementares que não é o GID do conjunto efetivo ou salvo, o comportamento do acesso (2) poderia ser manipulado.

Existem outros casos desse tipo. Veja a página do manual mkdir (2) do Linux, por exemplo. Dependendo se o bit de modo set-GID estiver definido no diretório pai, um novo arquivo criado no diretório assumirá a propriedade de grupo do GID efetivo do processo de criação. Novamente, se um processo não privilegiado puder alterar seu GID efetivo para ser o mesmo que um de seus GIDs suplementares, ele poderá manipular a propriedade do grupo de novos arquivos de maneiras inesperadas. Comentários semelhantes aplicam-se ao mknod (2) e ao System V IPC chama semget (2), shmget (2) e msgget (2).

Existem também alguns casos específicos do Linux em que os GIDs reais / efetivos / salvos não são equivalentes aos GIDs suplementares. Veja process_vm_readv (2) e prlimit (2), por exemplo.

    

Answer 2

Acho que o motivo é principalmente histórico. Grupos suplementares não foram adicionados até 4.2BSD (circa 1983). Antes disso, você só adiciona os uids e gids reais e efetivos.

O comportamento do setuid / setgid era completamente simétrico e não tinha motivo para não ser. Você alternaria o usuário com su e agruparia com sg / newgrp todos os executáveis setuid. As informações sobre a associação ao grupo de usuários residiam apenas no banco de dados do usuário, não em atributos de processos.

E a interface setuid / setgid não foi alterada quando foram acrescentados gids suplementares.

Tecnicamente, se você tiver acesso de gravação a um sistema de arquivos (onde a execução e setuid / setgid não estão desabilitados), você ainda pode definir seu ID de usuário efetivo ou real para qualquer um dos seus lances complementares (sem precisar recorrer a sg / newgrp , que só permite mudar para grupos definidos no banco de dados do usuário, o que não é necessariamente o mesmo que a lista de lances suplementares do processo).

cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env

E ao executar env , seu egid alterna para any-sup-group .