Warum sind privs erforderlich, um zusätzliche Gruppen mit setgid () zu versehen?

Die verschiedenen set*gid()Systemaufrufe erfordern Berechtigungen zum Ändern von Gruppen, außer in wenigen Fällen. Das Ändern der Primärgruppe in eine der zusätzlichen Gruppen des Prozesses scheint keine davon zu sein, was bedeutet, dass die Befehle newgrp/ sgbeispielsweise die Berechtigungen erhöhen müssen, um die Primärgruppe zu wechseln.

Gibt es einen Grund , warum setgid()/ setegid()/ setregid()/ setfsgid()nicht erlauben , ohne privs zu einer zusätzlichen Gruppe zu wechseln? Wenn ja, was ist der Grund?

security group system-calls

— William Hay
quelle

Ich bin mir auch nicht sicher. Beachten Sie, dass Sie eine Datei einer Ihrer zusätzlichen Gruppen zuordnen können. Wenn Sie also Schreibzugriff auf einen Bereich ohne noexec, nosuid, haben, können Sie diese Einschränkung umgehen (indem Sie eine Kopie von /usr/bin/envmit setgid-Berechtigung erstellen ).

— Stéphane Chazelas

Der Befehl newwp erledigt dies bereits für mich AFAICT, aber das Laichen eines externen Programms ist nicht immer das, was man tun möchte.

— William Hay

Beachten Sie, dass newgrp/sgsich dies auf die Kontodatenbank bezieht, nicht auf die zusätzliche Gruppenliste des Prozesses.

— Stéphane Chazelas

Wenn Ihre GID nicht auch in Ihrer Liste der zusätzlichen IDs enthalten ist, setgid()können Sie durch Zulassen die Mitgliedschaft in einer Gruppe verlassen (was ein Sicherheitsrisiko darstellt). Sie können dies jedoch auch mit demselben ausführbaren Trick für setgid wie oben tun. und Ihre GID befindet sich normalerweise auch in Ihrer Zusatzliste ( initgroups(3)nimmt nur dafür ein GID-Argument).

— Stéphane Chazelas

Antworten:

Das grundlegende Rätsel dabei ist natürlich, dass die Berechtigungsprüfungen des Dateisystems auf der Kombination von (der effektiven UID und) der effektiven GID und den zusätzlichen GIDs basieren. Unter dem Gesichtspunkt der Prüfung von Dateiberechtigungen entspricht die effektive GID den zusätzlichen GIDs, was zur Frage des OP führt. (Nebenbei: Wenn es sich um Linux handelt, wird tatsächlich die UID / GID des Dateisystems für die Berechtigungsprüfungen des Dateisystems verwendet und nicht die effektive UID und GID. Die ersteren IDs haben jedoch fast immer dieselben Werte wie die letzteren IDs. )

Es muss also einige Fälle geben, in denen die tatsächlichen / effektiven / gespeicherten GIDs nicht den zusätzlichen GIDs entsprechen. (Ich gruppiere die realen / effektiven / gespeicherten Set-GIDs, da die normalen Berechtigungsregeln für set * gid () besagen, dass ein nicht privilegierter Prozess eine dieser GIDs auf den gleichen Wert wie eine der beiden anderen ändern kann.)

Und tatsächlich gibt es einige solcher Fälle. access (2) führt seine Überprüfungen basierend auf der tatsächlichen Benutzer-ID und Gruppen-ID des Prozesses durch . Wenn ein nicht privilegierter Benutzer die reale Gruppen-ID so ändern konnte, dass sie mit einer der zusätzlichen GIDs übereinstimmt, bei denen es sich nicht um die effektive oder gespeicherte festgelegte GID handelt, kann das Zugriffsverhalten (2) manipuliert werden.

Es gibt andere solche Fälle. Ein Beispiel finden Sie in der Manpage zu Linux mkdir (2) . Abhängig davon, ob das Set-GID-Modusbit im übergeordneten Verzeichnis gesetzt ist, übernimmt eine neue Datei, die im Verzeichnis erstellt wurde, ihren Gruppenbesitz von der effektiven GID des Erstellungsprozesses. Wenn ein nicht privilegierter Prozess seine effektive GID so ändern könnte, dass sie mit einer seiner zusätzlichen GIDs identisch ist, könnte er den Gruppenbesitz neuer Dateien auf unerwartete Weise manipulieren. Ähnliche Kommentare gelten für mknod (2) und die System V IPC-Aufrufe semget (2), shmget (2) und msgget (2).

Es gibt auch einige Linux-spezifische Fälle, in denen die tatsächlichen / effektiven / gespeicherten Set-GIDs nicht den zusätzlichen GIDs entsprechen. Siehe zum Beispiel process_vm_readv (2) und prlimit (2).

— mtk
quelle

Hinweis: @mtk ist der Autor der Linux-Programmierschnittstelle .

— Stéphane Chazelas

Die effektive GID bestimmt den Gruppenbesitz neuer Dateien. Aber dann können Sie diese Gruppe später in eines Ihrer zusätzlichen Gids ändern (und auch das Setgid-Bit angeben, damit Ihr Prozess effektiv ein Setgid () ausführen kann). Es scheint also ein bisschen ein schwacher Grund zu sein.

— Stéphane Chazelas

@ StéphaneChazelas: stimmte zu, es ist ein wenig schwach. Auf OTOH ist das jetzt ein zweistufiger Prozess, der (und ich erreiche hier) das Potenzial für seltsame Rennen hat. Abgesehen von diesem Fall gibt es jedoch die anderen, die ich oben erwähne. Ich weiß nicht, welchen genauen Grund es für diese Designentscheidung gab. Vielleicht war es access (2), da dies ein alter Teil der API ist. Viele der anderen kamen erst später an (oder sind Linux-spezifisch) oder (ich nehme an) waren bei BSD nicht vorhanden, als zusätzliche GIDs hinzugefügt wurden. Oder vielleicht ging es nur darum, historisches Verhalten zu bewahren; Ich sehe, Sie haben diesen Punkt als Antwort hinzugefügt.

— MTK

Ich denke, der Grund ist in erster Linie historisch. Ergänzende Gruppen wurden erst mit 4.2BSD (ca. 1983) hinzugefügt. Vorher hatten Sie nur die echten und effektiven Uids und Gids.

Das Verhalten für setuid / setgid war vollständig symmetrisch und hatte keinen Grund, dies nicht zu tun. Sie würden den Benutzer mit wechseln suund mit sg/ newgrpall den ausführbaren Dateien von setuid gruppieren . Die Informationen zur Benutzergruppenmitgliedschaft befanden sich nur in der Benutzerdatenbank, nicht in Attributen von Prozessen.

Die Schnittstelle setuid / setgid wurde beim Hinzufügen zusätzlicher Gids nicht geändert.

Technisch gesehen können Sie jetzt, wenn Sie Schreibzugriff auf ein Dateisystem haben (in dem Ausführung und setuid / setgid nicht deaktiviert sind), Ihre effektive oder echte Benutzer-ID weiterhin auf eines Ihrer zusätzlichen Gids setzen (ohne auf sg/ newgrpwelches übrigens zurückgreifen zu müssen) erlauben, zu Gruppen zu wechseln, die in der Benutzerdatenbank definiert sind, was nicht unbedingt mit der Liste der zusätzlichen Gids des Prozesses übereinstimmt).

cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env

Und nach der Ausführung envwechselt Ihr egid zu any-sup-group.

— Stéphane Chazelas
quelle