¿Cómo funcionan los permisos de Linux cuando un proceso se ejecuta como un grupo específico?

Esto es algo en lo que no he podido encontrar mucha información, por lo que agradecería cualquier ayuda.

Mi entendimiento es así. Toma el siguiente archivo:

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

El usuario philno puede acceder a este archivo:

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

Si philse agrega al admgrupo, puede:

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

Si, sin embargo, un proceso que se inicia al mismo tiempo establecer explícitamente la user:groupque phil:philno puede leer el archivo. El proceso comenzó así:

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

Si el proceso se inicia como phil:adm, puede leer el archivo:

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

Entonces la pregunta realmente es:

¿Qué tiene de especial ejecutar un proceso con un combo de usuario / grupo específico que impide que el proceso pueda acceder a archivos propiedad de grupos suplementarios de ese usuario y hay alguna forma de evitarlo?

Un proceso se ejecuta con un uid ang un gid. Ambos tienen permisos asignados a ellos. Puede llamar a chroot con una especificación de usuario de un usuario y grupo, donde en realidad el usuario no está en ese grupo. El proceso se ejecutaría con los usuarios uid y los grupos dados gid.

Mira un ejemplo. Tengo un usuario llamado user, y él está en el grupo student:

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

Tengo un archivo de la siguiente manera:

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

No puede leerlo:

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

Ahora, puedo ejecutar el catproceso en el contexto del usuario userY el grupo root. Ahora, el proceso cat tiene los permisos necesarios:

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

Es interesante ver lo que iddice:

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

Hm, pero el usuario userno está en ese grupo ( root). ¿De dónde idobtiene su información? Si se llama sin argumento, idusa las llamadas al sistema getuid(), getgid()y getgroups(). Entonces idse imprime el contexto del proceso en sí mismo. Ese contexto con el que nos hemos alterado --userspec.

Cuando se llama con un argumento, idsolo determina las asignaciones de grupo del usuario:

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

A su pregunta:

¿Qué tiene de especial ejecutar un proceso con un combo de usuario / grupo específico que impide que el proceso pueda acceder a archivos propiedad de grupos suplementarios de ese usuario y hay alguna forma de evitarlo?

Puede establecer el contexto del proceso de seguridad que se necesita para resolver cualquier tarea que el proceso necesite hacer. Cada proceso tiene un conjunto de UID y GID bajo el cual se ejecuta. Normalmente, el proceso "toma" a los usuarios que llaman uid y gid como contexto. Con "tomas" me refiero al núcleo, de lo contrario sería un problema de seguridad.

Entonces, en realidad no es el usuario, que no tiene permisos para leer el archivo, son los permisos del proceso ( cat). Pero el proceso se ejecuta con el uid / gid del usuario llamante.

Por lo tanto, no tiene que estar en un grupo específico para que un proceso se ejecute con su uid y el gid de ese grupo.

El uso de la --userspecopción en chrootespecifica el usuario y un solo grupo para usar al ejecutar el chroot. Para definir grupos suplementarios, también debe usar la --groupsopción.

De manera predeterminada, los procesos heredan los grupos primarios y suplementarios del usuario que los ejecuta, pero al usarlos --userspecle indica chmodque anule eso usando el grupo único especificado.

La documentación detallada de los permisos en Linux está disponible en la página de credentials(7)manual.

Cuando inicia sesión en Linux, el proceso de inicio de sesión login, después de verificar que puede iniciar sesión como phil , obtiene el uid de phil y los grupos a los que pertenece, estableciéndolos como un proceso que luego se inicia como su shell. Los grupos uid, gid y suplementarios son propiedad del proceso.

Cualquier programa posterior iniciado después de eso, es un descendiente de ese shell, y simplemente recibe una copia de esas credenciales. * Esto explica por qué cambiar los derechos del usuario no afecta los procesos en ejecución. Sin embargo, los cambios se recogerán en el próximo inicio de sesión.

* La excepción son los programas cuyos bits setuid o setgid están establecidos, que tendrán una identificación de usuario efectiva diferente . Esto se usa, por ejemplo, en su (1) para que pueda ejecutarse con rootprivilegios incluso cuando es ejecutado por phil.

Después de que haya agregado philal admgrupo, él podría ejecutar su phily su, al ejecutarse como root, verificará que realmente proporcione la contraseña de phil y luego lo colocará en un shell con los grupos uid, gid y suplementarios a los que phil pertenece. Y como esto se hace después de agregar al usuario al grupo, ese shell ya estaría en el admgrupo.

No considero que chroot (1) sea el programa más adecuado para ejecutarse como un usuario diferente , pero ciertamente hace el trabajo. El parámetro --userspec phil:philhace que se ejecute con el uid de phily el gid de phil. No se establecen grupos adicionales (para eso proporcionaría --groups). Por lo tanto, el proceso de los niños no está en el admgrupo.

Una forma más normal de ejecutar su proceso como phil sería su phil -c "process". A medida que se sucargan los grupos uid, gid y suplementarios de la información de la base de datos del usuario, processtendrán las mismas credenciales que el usuario tiene actualmente.

¹ Esto puede ser login (1) , sshd, su, gdb u otros programas. Además, es probable que se administre a través de módulos pam.