usando o bit SUID para descartar privilégios

Question

Esta é uma descrição do sistema em que estou trabalhando:

• um processo "gerenciador" gera todos os outros aplicativos.
• O aplicativo gerenciador é executado como root user.
• agora, qualquer processo gerado também herda os privilégios de usuário root .

O terceiro ponto faz claramente da minha aplicação (vamos chamá-la 'player') um risco de segurança, então uma solução seria criar um usuário e grupo separados, digamos 'worker' e depois gerar o processo 'player' como aquele usuário .

A implementação específica é a seguinte:

• chown o binário (player.out) para o usuário worker e grupo chown worker:worker player.out
• defina o bit SUID com chmod a+s player.out .
  • isso garante que o processo seja iniciado com (pelo menos) seu EUID definido como 'worker'.

• dentro do uso principal do aplicativo setregid() e setreuid para definir o RUID com o mesmo valor do EUID:

  if(setregid(getegid(), getegid()) != 0) {}
  if(setreuid(geteuid(), geteuid()) != 0) {}
  

Minha pergunta é em duas partes:

1. Os processos com o conjunto de bits SUID geralmente são de propriedade de root e são chamados de aplicativos setuid para denotar (possivelmente) que suas permissões sejam elevadas para o usuário raiz, independentemente de qual usuário invocou o programa.
   • há algum nome especial para binários que usam o bit SUID para automaticamente eliminar privilégios?
2. Existe alguma outra maneira melhor de garantir que o aplicativo "player" derrube privilégios?

Editar : devo esclarecer que não tenho controle sobre o processo "gerente" que gera os outros processos. Eu só tenho controle sobre o meu aplicativo player .

    

Answer 1

1. Ao definir corretamente um bit SUID, define o ID de usuário efetivo do novo processo para o proprietário do arquivo de programa que está sendo executado. Não há conceito de aumento ou redução de privilégios. Muitas vezes o usuário qual "suid" é a raiz, mas pode ser legitimamente qualquer outro, e realmente não muda o conceito de SUID, quando você escolher outro, além de alguns usuários terem acesso a Recursos. No entanto, o usuário root é um pouco especial e a página man do setuid explica as sutis diferenças. Eu não acho que há um nome especial para mudar para um usuário não-root, e eu nunca associei suid significado subindo em privilégio, apenas mudando o usuário.

2. Como você mesmo está desenvolvendo o mestre que é executado como root pode setuid para qualquer usuário depois de forking mas antes de executar o novo processo, eu não vejo que o bit suid tem que ser usado em executável em tudo, e incidentemente se você não fizer isso, então se qualquer usuário antigo correu o jogador, já que o executável não é suid, eles não seriam capazes de executar corretamente, pois o setuid falhará se eles não forem root. Para mim isso parece melhor segurança, do que usar suid bits em arquivos executáveis.

--- editar 1

Assim, seu gerente (executando como real e efetivo uid = 0) inicia o jogador e você codifica / controla o jogador (não o gerenciador). Se você não fizer nada de especial, então o jogador rodará com uid real + efetivo = 0 e você quer evitar isso.

Você pode simplesmente trocar de player, sem SUID no player, sem necessidade.

    

Answer 2

A maneira usual é que o processo mestre se bifurca, elimina recursos ou altera seu ID de usuário e, em seguida, executa o novo processo.