Wie funktionieren Linux-Berechtigungen, wenn ein Prozess als bestimmte Gruppe ausgeführt wird?

Dies ist etwas, über das ich nicht viele Informationen finden konnte, daher wäre jede Hilfe dankbar.

Mein Verständnis ist also. Nehmen Sie die folgende Datei:

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

Der Benutzer philkann nicht auf diese Datei zugreifen:

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

Wenn philes der admGruppe hinzugefügt wird , kann es:

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

Wenn jedoch ein Prozess gestartet wird, während das explizit user:groupauf gesetzt ist phil:phil, kann die Datei nicht gelesen werden. Der Prozess begann folgendermaßen:

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

Wenn der Prozess als gestartet wird phil:adm, kann er die Datei lesen:

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

Die Frage ist also wirklich:

Was ist das Besondere daran, einen Prozess mit einer bestimmten Benutzer- / Gruppenkombination auszuführen, die verhindert, dass der Prozess auf Dateien zugreifen kann, die zusätzlichen Gruppen dieses Benutzers gehören, und gibt es eine Möglichkeit, dies zu umgehen?

Ein Prozess wird mit einer UID und einer GID ausgeführt. Beiden sind Berechtigungen zugewiesen. Sie können chroot mit einer Benutzerspezifikation eines Benutzers und einer Gruppe aufrufen, wobei sich der Benutzer tatsächlich nicht in dieser Gruppe befindet. Der Prozess würde dann mit der Benutzer-UID und der angegebenen Gruppen-GID ausgeführt.

Siehe ein Beispiel. Ich habe einen Benutzer namens userund er ist in der Gruppe student:

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

Ich habe eine Datei wie folgt:

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

Er kann es nicht lesen:

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

Jetzt kann ich den catProzess im Kontext des Benutzers userUND der Gruppe ausführen root. Jetzt verfügt der Cat-Prozess über die erforderlichen Berechtigungen:

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

Es ist interessant zu sehen, was idsagt:

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

Hm, aber der Benutzer userist nicht in dieser Gruppe ( root). Woher idkommen die Informationen? Wenn ohne Argument aufgerufen, idverwendet die Systemaufrufe getuid(), getgid()und getgroups(). So wird der Prozesskontext von idselbst gedruckt. Diesen Kontext haben wir geändert --userspec.

Wenn mit einem Argument aufgerufen, werden idnur die Gruppenzuweisungen des Benutzers bestimmt:

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

Zu Ihrer Frage:

Was ist das Besondere daran, einen Prozess mit einer bestimmten Benutzer- / Gruppenkombination auszuführen, die verhindert, dass der Prozess auf Dateien zugreifen kann, die zusätzlichen Gruppen dieses Benutzers gehören, und gibt es eine Möglichkeit, dies zu umgehen?

Sie können den Sicherheitsprozesskontext festlegen, der zur Lösung der Aufgaben erforderlich ist, die der Prozess ausführen muss. Jeder Prozess hat eine UID und ein GID-Set, unter denen er ausgeführt wird. Normalerweise "nimmt" der Prozess die aufrufenden Benutzer uid und gid als seinen Kontext. Mit "Takes" meine ich, dass der Kernel dies tut, sonst wäre es ein Sicherheitsproblem.

Es ist also eigentlich nicht der Benutzer, der keine Berechtigungen zum Lesen der Datei hat, sondern die Berechtigungen des Prozesses ( cat). Der Prozess wird jedoch mit der UID / GID des aufrufenden Benutzers ausgeführt.

Sie müssen sich also nicht in einer bestimmten Gruppe befinden, damit ein Prozess mit Ihrer UID und der GID dieser Gruppe ausgeführt werden kann.

Wenn Sie die --userspecOption ein verwenden, chrootwerden der Benutzer und eine einzelne Gruppe angegeben, die beim Ausführen von verwendet werden sollen chroot. Um zusätzliche Gruppen zu definieren, müssen Sie auch die --groupsOption verwenden.

Standardmäßig erben Prozesse die primären und zusätzlichen Gruppen des Benutzers, der sie ausführt. Wenn Sie sie jedoch verwenden, müssen --userspecSie chmoddiese mit der angegebenen Einzelgruppe überschreiben.

Eine ausführliche Dokumentation der Berechtigungen unter Linux finden Sie in der credentials(7)Manpage.

Wenn Sie sich bei Linux anmelden, erhält der Anmeldevorgang¹ - nachdem Sie überprüft haben, dass Sie sich als phil anmelden können - die UID von phil und den Gruppen, zu denen er gehört, und legt diese als Prozess fest, der dann als Ihre Shell gestartet wird. Die Gruppen uid, gid und supplemental sind eine Eigenschaft des Prozesses.

Jedes spätere Programm, das danach gestartet wird, ist ein Nachkomme dieser Shell und erhält einfach eine Kopie dieser Anmeldeinformationen. * Dies erklärt, warum das Ändern der Rechte des Benutzers keine Auswirkungen auf die ausgeführten Prozesse hat. Die Änderungen werden jedoch beim nächsten Login übernommen.

* Die Ausnahme bilden Programme, deren setuid- oder setgid-Bits gesetzt sind und die eine andere effektive Benutzer-ID haben . Dies wird beispielsweise in su (1) verwendet, damit es rootauch bei Ausführung mit ausgeführt werden kann phil.

Nachdem Sie philder admGruppe hinzugefügt haben , kann er ausgeführt su philwerden und suwird - als Root ausgeführt - überprüfen, ob er tatsächlich Phils Passwort bereitstellt, und ihn dann in einer Shell mit den UID-, GID- und Zusatzgruppen landen, zu denen Phil gehört. Und da dies nach dem Hinzufügen des Benutzers zur Gruppe erfolgt, befindet sich diese Shell bereits in der admGruppe.

Ich halte chroot (1) nicht für das am besten geeignete Programm, um als anderer Benutzer ausgeführt zu werden , aber es erledigt die Arbeit auf jeden Fall. Der Parameter --userspec phil:phillässt es mit der UID von philund der GID von laufen phil. Es sind keine zusätzlichen Gruppen festgelegt (für die Sie angeben würden --groups). Somit ist der Kinderprozess nicht in der admGruppe.

Ein normaler Weg, um Ihren Prozess so auszuführen, wie es phil wäre su phil -c "process". Beim suLaden der UID-, GID- und Zusatzgruppen aus den Benutzerdatenbankinformationen processwerden dieselben Anmeldeinformationen verwendet , über die der Benutzer derzeit verfügt.

¹ Dies können Login (1) , sshd, su, gdb oder andere Programme sein. Außerdem wird es wahrscheinlich über Pam-Module verwaltet.