Comment les autorisations Linux fonctionnent-elles lorsqu'un processus s'exécute en tant que groupe spécifique?

C'est quelque chose sur lequel je n'ai pas pu trouver beaucoup d'informations, donc toute aide serait appréciée.

Ma compréhension est ainsi. Prenez le fichier suivant:

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

L'utilisateur philne peut pas accéder à ce fichier:

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

Si philest ajouté au admgroupe, il peut:

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

Cependant, si un processus est démarré alors qu'il est défini explicitement user:groupsur, phil:philil ne peut pas lire le fichier. Le processus a commencé comme ceci:

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

Si le processus est démarré en tant que phil:adm, il peut lire le fichier:

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

La question est donc vraiment:

Quelle est la particularité d'exécuter un processus avec un combo utilisateur / groupe spécifique qui empêche le processus d'accéder aux fichiers appartenant à des groupes supplémentaires de cet utilisateur et existe-t-il un moyen de contourner cela?

Un processus est exécuté avec un uid et un gid. Les deux ont des autorisations qui leur sont attribuées. Vous pouvez appeler chroot avec une spécification utilisateur d'un utilisateur et d'un groupe, alors qu'en réalité l'utilisateur n'est pas dans ce groupe. Le processus serait alors exécuté avec les utilisateurs uid et les groupes donnés gid.

Voir un exemple. J'ai un utilisateur appelé user, et il est dans le groupe student:

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

J'ai un dossier comme suit:

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

Il ne peut pas le lire:

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

Maintenant, je peux exécuter le catprocessus dans le contexte de l'utilisateur userET du groupe root. Maintenant, le processus cat dispose des autorisations nécessaires:

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

C'est intéressant de voir ce qui iddit:

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

Hm, mais l'utilisateur usern'est pas dans ce groupe ( root). D'où idobtient ses informations? Appelée sans argument idutilise les appels système, getuid(), getgid()et getgroups(). Le contexte du processus idest donc imprimé. Ce contexte avec lequel nous avons changé --userspec.

Lorsqu'il est appelé avec un argument, iddétermine simplement les affectations de groupe de l'utilisateur:

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

À votre question:

Quelle est la particularité d'exécuter un processus avec un combo utilisateur / groupe spécifique qui empêche le processus d'accéder aux fichiers appartenant à des groupes supplémentaires de cet utilisateur et existe-t-il un moyen de contourner cela?

Vous pouvez définir le contexte du processus de sécurité nécessaire pour résoudre toutes les tâches que le processus doit effectuer. Chaque processus a un ensemble uid et gid sous lequel il s'exécute. Normalement, le processus "prend" les utilisateurs appelants uid et gid comme contexte. Avec "prend", je veux dire que le noyau le fait, sinon ce serait un problème de sécurité.

Donc, ce n'est en fait pas l'utilisateur, qui n'a pas l'autorisation de lire le fichier, ce sont les autorisations du processus ( cat). Mais le processus s'exécute avec l'uid / gid de l'utilisateur appelant.

Vous n'avez donc pas besoin d'être dans un groupe spécifique pour qu'un processus s'exécute avec votre uid et le gid de ce groupe.

L'utilisation de l' --userspecoption on chrootspécifie l'utilisateur et un seul groupe à utiliser lors de l'exécution de chroot. Pour définir des groupes supplémentaires, vous devez également utiliser l' --groupsoption.

Par défaut, les processus héritent des groupes principaux et supplémentaires de l'utilisateur qui les exécute, mais en utilisant, --userspecvous dites chmodde remplacer cela en utilisant le seul groupe spécifié.

Une documentation détaillée des autorisations sous Linux est disponible dans la credentials(7)page de manuel.

Lorsque vous vous connectez à Linux, le processus de connexion¹ - après avoir vérifié que vous pouvez vous connecter en tant que phil - obtient l'uid de phil et les groupes auxquels il appartient, en les définissant comme un processus qui est ensuite démarré comme votre shell. Les groupes uid, gid et supplemental sont une propriété du processus.

Tout programme ultérieur démarré par la suite est un descendant de ce shell et reçoit simplement une copie de ces informations d'identification. * Cela explique pourquoi la modification des droits de l'utilisateur n'affecte pas les processus en cours d'exécution. Cependant, les modifications seront prises en compte lors de la prochaine connexion.

* L'exception concerne les programmes dont les bits setuid ou setgid sont définis, qui auront un ID utilisateur effectif différent . Ceci est utilisé par exemple dans su (1) afin qu'il puisse fonctionner avec des rootprivilèges même lorsqu'il est exécuté par phil.

Une fois que vous avez ajouté philau admgroupe, il peut s'exécuter su philet su, en tant que root, vérifiera qu'il fournit bien le mot de passe de phil, puis l'atterrira dans un shell avec les groupes uid, gid et supplémentaires auxquels phil appartient. Et comme cela se fait après l'ajout de l'utilisateur au groupe, ce shell serait déjà dans le admgroupe.

Je ne considère pas chroot (1) le programme le plus adapté pour fonctionner en tant qu'utilisateur différent , mais il fait certainement le travail. Le paramètre le --userspec phil:philfait fonctionner avec l'uid de philet le gid de phil. Aucun groupe supplémentaire n'est défini (pour cela vous fourniriez --groups). Ainsi, le processus des enfants n'est pas dans le admgroupe.

Une façon plus normale d'exécuter votre processus comme le ferait phil su phil -c "process". Lors du suchargement, les groupes uid, gid et supplémentaires des informations de la base de données utilisateur processauront les mêmes informations d'identification que l'utilisateur possède actuellement.

¹ Il peut s'agir de login (1) , sshd, su, gdb ou d'autres programmes. En outre, il est probablement géré via des modules pam.