Como as permissões do Linux funcionam quando um processo está sendo executado como um grupo específico?

Question

Isso é algo que eu não consegui encontrar muita informação, então qualquer ajuda seria apreciada.

Meu entendimento é assim. Pegue o seguinte arquivo:

-rw-r-----  1 root        adm   69524 May 21 17:31 debug.1

O usuário phil não pode acessar este arquivo:

phil@server:/var/log$ head -n 1 debug.1
cat: debug.1: Permission denied

Se phil for adicionado ao grupo adm , ele poderá:

root@server:~# adduser phil adm
Adding user 'phil' to group 'adm' ...
Adding user phil to group adm
Done.
phil@server:/var/log$ head -n 1 debug.1
May 21 11:23:15 server kernel: [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014

Se, no entanto, um processo for iniciado enquanto estiver explicitamente configurando o user:group para phil:phil , ele não poderá ler o arquivo. Processo iniciado assim:

nice -n 19 chroot --userspec phil:phil / sh -c "process"

Se o processo for iniciado como phil:adm , ele poderá ler o arquivo:

nice -n 19 chroot --userspec phil:adm / sh -c "process"

Então a questão realmente é:

O que é especial sobre a execução de um processo com uma combinação específica de usuário / grupo que impede que o processo possa acessar arquivos pertencentes a grupos suplementares desse usuário e existe alguma maneira de contornar isso?

    

Answer 1

Um processo é executado com um uid ang um gid. Ambos têm permissões atribuídas a eles. Você poderia chamar o chroot com um userspec de um usuário e grupo, onde, na verdade, o usuário não está nesse grupo. O processo seria então executado com os usuários uid e os grupos fornecidos gid.

Veja um exemplo. Eu tenho um usuário chamado user e ele está no grupo student :

root@host:~$ id user
uid=10298(user) gid=20002(student) groups=20002(student)

Eu tenho um arquivo da seguinte forma:

root@host:~$ ls -l file
-rw-r----- 1 root root 9 Mai 29 13:39 file

Ele não pode lê-lo:

user@host:~$ cat file
cat: file: Permission denied 

Agora, posso execte o processo cat no contexto do usuário user AND do grupo root . Agora, o processo do gato tem as permissões necessárias:

root@host:~$ chroot --userspec user:root / sh -c "cat file"
file contents

É interessante ver o que id diz:

root@host:~$ chroot --userspec user:root / sh -c "id"
uid=10298(user) gid=0(root) groups=20002(student),0(root)

Hm, mas o usuário user não está nesse grupo ( root ). De onde id obtém suas informações? Se chamado sem argumento, id usa as chamadas do sistema, getuid() , getgid() e getgroups() . Portanto, o contexto do processo de id é impresso. Esse contexto nós alteramos com --userspec .

Quando chamado com um argumento, id apenas determina as atribuições de grupo do usuário:

root@host:~$ chroot --userspec user:root / sh -c "id user"
uid=10298(user) gid=20002(student) groups=20002(student)

Para sua pergunta:

What is special about running a process with a specific user/group combo that prevents the process being able to access files owned by supplementary groups of that user and is there any way around this?

Você pode definir o contexto do processo de segurança necessário para resolver qualquer tarefa que o processo precise fazer. Todo processo tem um conjunto uid e gid sob o qual ele é executado. Normalmente, o processo "pega" os usuários chamadores como seu contexto. Com "takes", o kernel faz, caso contrário, seria um problema de segurança.

Portanto, na verdade não é o usuário, que não tem permissões para ler o arquivo, é a permissão do processo ( cat ). Mas o processo é executado com o uid / gid do usuário chamador.

Assim, você não precisa estar em um grupo específico para executar um processo com seu uid e o gid desse grupo.

    

Answer 2

O uso da opção --userspec em chroot especifica o usuário e um único grupo a ser usado ao executar o chroot . Para definir grupos suplementares, você também precisa usar a opção --groups .

Por padrão, os processos herdam os grupos principal e suplementar do usuário que os executa, mas usando --userspec , você está dizendo a chmod para substituir isso usando o único grupo especificado.

A documentação detalhada das permissões no Linux está disponível na credentials(7) página de manual.

    

Answer 3

Quando você se conecta ao Linux, o processo de login - depois de verificar, você pode logar como phil - obtém o uid de phil e os grupos aos quais ele pertence, configurando-os como um processo que é iniciado como seu shell. Os grupos uid, gid e suplementar são uma propriedade do processo.

Qualquer programa posterior iniciado depois disso, é um descendente desse shell e simplesmente recebe uma cópia dessas credenciais. * Isso explica por que a alteração dos direitos do usuário não afeta os processos em execução. As alterações serão selecionadas no próximo login, no entanto.

* A exceção são programas cujos bits setuid ou setgid são definidos, que terão um id de usuário efetivo diferente. Isso é usado, por exemplo, em su (1) para que ele possa ser executado com root privilégios, mesmo quando executados por phil .

Depois de adicionar phil ao grupo adm , ele pode executar su phil e su irá executar como root. Verifique se ele realmente fornece a senha de phil e, em seguida, insira-o em um shell com o uid , gid e grupos suplementares phil pertence a. E como isso é feito depois de adicionar o usuário ao grupo, esse shell já estaria no grupo adm .

Eu não considero o chroot (1) o programa mais adequado para rodar como um usuário diferente , mas certamente o trabalho é feito. O parâmetro --userspec phil:phil faz com que ele seja executado com o uid de phil e o gid de phil . Nenhum grupo adicional está definido (para isso, você deve fornecer --groups ). Assim, o processo filho não está no grupo adm .

Uma maneira mais normal de executar seu processo como phil seria su phil -c "process" . Como su carrega os grupos uid, gid e suplementar das informações do banco de dados do usuário, process terá as mesmas credenciais que o usuário possui atualmente.

¹ Isso pode ser login (1) , sshd, su, gdb ou outros programas. Além disso, provavelmente está sendo gerenciado por meio de módulos pam.