Ich mach mich gern unsichtbar.

Ich habe auch mal davon gelesen, habe allerdings kein System gefunden, auf dem das tatsaechlich funktioniert. Welche Unix-Variante hast Du denn genau? Edit: Solaris 8, wie Du oben ueberlesenerweise schriebst.

Die in dem Zitat angesprochene Race-Condition ist folgende: Wenn ein Set-UID-Script gestartet wird, muesste der Kernel zunächst den Interpreter privilegiert starten (Der Schritt vom Script zum Interpreter (ueber das Shebang)) und ihm als Parameter den Scriptnamen geben. Der Interpreter wird dann das Script oeffnen (das ist der Schritt wieder zurueck: vom Interpreter zum Script). Das koennte jetzt inzwischen aber ein anderes Script sein, welches gar nicht mehr das sid-Bit gesetzt hat.

Man koennte nun meinen, dass dieses Problem nicht nur fuer Setuid-Scripte gilt. Doch sollte man sich folgendes Szenario vor Augen halten: Ich lege in meinem Home-Verzeichnis einen Hardlink auf ein Setuid-Root-Script an, starte es ueber "./script" und sofort danach ersetze ich es durch ein beliebig böswilliges Script meiner Wahl. Mit diesem Mittel kann ich mein beliebiges Script mit Root-Rechten ausfuehren.

Die Loesung dafuer ist simpel: Der Interpreter muss das Script nicht selbst ueber einen vertrauensunwuerdigen Dateinamen oeffnen. Stattdessen wird die Datei kernelintern geoeffnet (z. B. als Deskriptor 4), und der Interpreter bekommt den Dateinamen "/dev/fd/4" als Parameter, womit es auf diesen Dateideskriptor zugreifen kann. Zwischen dem Oeffnen der Datei und dem privilegierten Ausfuehren des Interpreters kann nun ohne Race-Condition die Richtigkeit des Setuid-Bits ueberprueft werden.

/dev/fd ist unter Linux normalerweise ein Symlink auf /proc/self/fd, wobei /proc/self ein Symlink auf das aktuelle Prozess-Verzeichnis in /proc ist, z. B. /proc/43134. In dem fd-Verzeichnis ist fuer jeden offenen Dateideskriptor ein etwas magischer Symlink. Wenn man ihn oeffnet, passiert wohl ungefaehr so etwas wie bei dem dup-Systemcall (siehe dup(2)).\n\n

<!--EDIT|betterworld|1149980351-->

@betterworld

Danke für die ausführliche Beschreibung!

Wenn man's weiss, leuchtet das auch ein. Wenn man's nicht weiss, kann man sich über $0 schon wundern ;o)

Gruß, Doc

An dieser Abhilfe fuer die Race-Condition ist nur unguenstig, dass man nicht mehr ueber den 0. Kommandozeilenparameter und den Pfad die Lage der eigenen Programmdatei ermitteln kann. Leider schliesst das dann die Verwendung des FindBin Modules aus.

[quote=murphy,12.June.2006, 18:00]An dieser Abhilfe fuer die Race-Condition ist nur unguenstig, dass man nicht mehr ueber den 0. Kommandozeilenparameter und den Pfad die Lage der eigenen Programmdatei ermitteln kann. Leider schliesst das dann die Verwendung des FindBin Modules aus.[/quote]
Das wäre schade!

Gibt es denn keine Möglich, mit einem File-Descriptor an Pfad+Dateinamen ranzukommen? Über den I-Node vielleicht (jedenfalls unter UNIX)?

Gruß, Doc

[quote=murphy,12.06.2006, 18:00]An dieser Abhilfe fuer die Race-Condition ist nur unguenstig, dass man nicht mehr ueber den 0. Kommandozeilenparameter und den Pfad die Lage der eigenen Programmdatei ermitteln kann. Leider schliesst das dann die Verwendung des FindBin Modules aus.[/quote]
Unter Umständen nicht. Im FindBin-Modul gibt es die $RealBin-Variable, welche Symlinks aufloest. Zumindest bei Linux sind die Eintrage in /dev/fd immer Symlinks auf die tatsaechlichen Dateien. docsnyder kann ja mal probieren, ob das bei seinem System auch so ist und ob da $RealBin funktioniert.

@betterworld: Ich habe vor meinem letzten Beitrag auf einer Sun-Kiste getestet und festgestellt, dass bei Verwendung von FindBin so ein setuid Skript gleich beim Kompilieren abschmiert:

Hmm, ich habe ja leider nicht die Gelegenheit, legitim an mehrere Benutzer eines Sun-Systemes zu kommen, sodass ich mit setuid spielen kann, aber mit meinem einzelnen Benutzer habe ich gerade festgestellt, dass dort die Verzeichnisse /proc/self/fd und /dev/fd ganz anders aussehen als bei Linux und gar nicht mal dieselben sind. Naja, jedem das Seine...

@betterworld
@murphy

Quote

docsnyder kann ja mal probieren, ob das bei seinem System auch so ist und ob da $RealBin funktioniert.

Hab's probiert und bei mir passiert das gleiche wie bei murphy: compilation failed!

Sobald ich FindBin rausnehme funktioniert es wieder (allerdings eben mit /dev/fd/4 als Ausgabe).

So etwas bin ich von Perl garnicht gewohnt, daß ein Standard-Modul beim compilieren abraucht.

Gruß, Doc

[quote=docsnyder,13.06.2006, 08:42]So etwas bin ich von Perl garnicht gewohnt, daß ein Standard-Modul beim compilieren abraucht.

Gruß, Doc[/quote]
Beim Kompilieren heißt wohl eher "in BEGIN" bzw in "use". Wenn das Standardmodul nicht funktionieren kann, ist es verstaendlich, dass das einbindende Script auch nicht ausgefuehrt werden kann.