arquivos em / proc / $ PID (por exemplo, ssh-agent, Chrome) não são de propriedade do usuário, mas por raiz

Question

Estou apenas respondendo a outra pergunta aqui :-) e, portanto, dei uma olhada - queria para ver /proc/$PID/fd de ssh-agent para descobrir qual soquete ele usa. Mas eu não posso. Fico surpreso ao notar que a maioria dos arquivos e diretórios pertencem ao root. ssh-agent é executado como meu usuário (assim como seu processo pai) e não é instalado SUID root. Não consegui descobrir exatamente onde o KDE inicia. Estou curioso; alguém pode dizer o que está acontecendo aqui?

Ou não é sobre o usuário, os processos podem usar alguma mágica do kernel para esconder (a maioria) suas /proc info do público (e até mesmo outros processos do mesmo usuário)?

Acabei de verificar o /proc/$PID/fd de todos os meus processos e observei que ssh-agent não é o único processo com esse atributo estranho. Os outros são o grupo de processos do Chrome e kdesud (nenhum binário de raiz SUID).

    

Answer 1

[O texto a seguir foi adaptado do texto Eu estou apenas no processo de adicionar ao proc (5) página de manual, que responde a esta pergunta.]

Os arquivos em /proc/PID são normalmente de propriedade do usuário efetivo e do ID do grupo efetivo do processo. No entanto, como uma medida de segurança, a propriedade é feita root:root se o atributo "dumpable" do processo estiver configurado para um valor diferente de 1. [O valor padrão deste atributo é 1. Configurar esse atributo como 0 faz com que um processo não seja produzir core dumps, pois eles podem conter informações confidenciais. Da mesma forma, certos arquivos em /proc/PID podem fornecer acesso a informações confidenciais.]

Este atributo pode ser alterado pelos seguintes motivos:

1. O atributo foi definido explicitamente por meio da operação prctl(2) PR_SET_DUMPABLE .
2. O atributo foi redefinido para o valor no arquivo /proc/sys/fs/suid_dumpable .

O valor padrão em /proc/sys/fs/suid_dumpable é 0. As razões pelas quais o atributo dumpable pode ser redefinido para o valor no arquivo suid_dumpable são descritas no página de manual do prctl (2) :

• O ID do usuário ou grupo efetivo do processo foi alterado.
• O ID do usuário ou grupo do sistema de arquivos do processo é alterado.
• O processo executa um programa set-user-ID ou set-group-ID ou um programa com recursos.

Answer 2

Para o chrome, o motivo é que chrome-sandbox tem o bit suid, portanto ele é executado com privilégios de root.

Em relação ao seu problema com ssh-agent , não tenho certeza se, no meu caso, /usr/bin/ssh-agent tem um bit suid definido, ou seja, as entradas raiz fazem sentido. Eu não sei como o kde lida com o ssh-agent, mas tenho certeza que existe um auxiliar suid envolvido.

Em geral, não há coisas mágicas, normalmente um programa precisa ter um bit suid, especificar explicitamente o CAPABILITIES ou utilizar algum tipo de auxiliar externo, seja através da execução direta ou algo como polkit .

Como esses programas são executados como root, mas perdem seus privilégios, você os vê executando como usuário em ps , mas os arquivos ainda são de propriedade do proprietário do bit suid.

    

Answer 3

Seu gerenciador de exibição (lightdm, openbox, etc.) é um filho do init que é de propriedade do root. O init não é set-uid porque é um processo muito especial e acabou de ser iniciado com 0. O comando ps -eaH fornece uma visão estruturada de parentage, os bits relevantes são:

r    1 ?        00:00:00 init
r 1521 ?        00:00:00   lightdm
r 1531 tty7     00:00:12     Xorg
m 2035 ?        00:00:00     lightdm
m 2177 ?        00:00:00       gnome-session
m 2225 ?        00:00:00         ssh-agent

Onde preenchei o proprietário (Root ou Me) do processo. Lembre-se que o / proc não é um sistema de arquivos real, mas fornece acesso semelhante a um arquivo nas estruturas internas do kernel e o kernel pode definir quaisquer permissões consideradas apropriadas. Mesmo que 2035 tenha um UID real e efetivo de mim, as entradas em / proc / 2035 são de propriedade de root e / proc / 2035 / fd tem permissões 0700 (-r-x ------). Não é até chegarmos a 2177 que eu possuo os pseudo-arquivos em proc porque o PPID de 2177 não era raiz de UID.

Por quê? Porque se eu fosse gerado por um programa de raiz, alguns dos meus arquivos podem permitir que eu aproveite a segurança do sistema. Isso costumava ser diferente como as notas do proc (5) man em / proc / sys / fs / protected_hardlinks :

The default value in this file is 0. Setting the value to 1 prevents a longstanding class of security issues caused by hard- link-based time-of-check, time-of-use races, most commonly seen in world-writable directories such as /tmp. The common method of exploiting this flaw is to cross privilege boundaries when following a given hard link (i.e., a root process follows a hard link created by another user). Additionally, on systems without separated partitions, this stops unauthorized users from "pinning" vulnerable set-user-ID and set-group-ID files against being upgraded by the administrator, or linking to special files.

Embora esta nota não fale exatamente sobre o motivo pelo qual o vetor de ataque / proc / fd pode ser explorado, ele dá a sensação de alguns milhares de linhas de código do kernel / fs / proc.

    

Answer 4

/ proc é um pseudo sistema de arquivos especial. De proc(5) ( man 5 proc ):

   The proc file system is a pseudo-file system which is used as an inter-
   face to kernel data structures.  It is commonly mounted at /proc.  Most
   of  it  is  read-only,  but  some  files  allow  kernel variables to be
   changed.

Eu recomendo ler a man page completa para uma explicação.