por que o CAP_SYS_ADMIN é necessário para o CLONE_NEWPID?

Question

man 2 unshare nos diz

Use of CLONE_NEWPID requires the CAP_SYS_ADMIN capability

e a leitura sugerida para mais informações man 7 pid_namespaces realmente não discute o risco presumível que torna necessário restringir pid_namespaces para root / CAP_SYS_ADMIN apenas.

Qual seria o risco de CLONE_NEWPID se fosse executado por um usuário não-root?

Em um clone sem CLONE_NEWPID o pid_namespace seria inalterado e, portanto, muito mais amplo e potencialmente mais perigoso do que seria no caso de criar um novo pid_namespace vazio.

Infelizmente, sem algum conceito de namespaces de usuário PID para um usuário não-root, é difícil acompanhar os processos descendentes de maneira confiável no Linux. pid_namespaces seria uma funcionalidade muito útil e, portanto, é incompreensível para mim porque somente CAP_SYS_ADMIN é considerado adequado para executar CLONE_NEWPID . Senti falta de um ponto importante que torna CLONE_NEWPID essa ocupação arriscada?

    

Answer 1

Eu acho que é uma precaução. Usuários não privilegiados não têm permissão para aplicar confinamentos a programas como sudo que são set-user-id (ou possuem recursos de arquivo definidos), caso isso os confunda em ações que eles não pretendiam permitir.

Em alguns casos, isso é imposto impedindo a elevação por set-uid etc. Essa é a abordagem adotada ao filtrar as chamadas do sistema com o seccomp.

No entanto, para namespaces, a intenção era permitir o uso de namespaces em ids de usuários. Os namespaces foram mesclados no mainline Linux em um processo incremental, começando com o mais simples e culminando em namespaces de usuário. Eu suspeito que houve pouco interesse em adicionar o caso especial, para impingir no-new-privs ao entrar em um namespace PID, quando você ainda não tem privilégio completo.

A interação desses espaços de nomes torna-se bastante complicada, por isso é bom não proliferar muitos casos diferentes, se esses casos não estiverem em alta demanda.