Follow-up: Warum sind Shebang-Dateien nicht geeignet?

423
ivo Welch

Folgefrage an https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts . Es gibt eine sehr gute Antwort von Gilles. leider verstehe ich es nicht. Nichts, was dort beschrieben wird, scheint sich zwischen ausführbaren und interpretierbaren Elementen grundsätzlich zu unterscheiden.

  • Skripts hatten eine Race-Datei-Ersetzungsbedingung, jedoch ist keine Unix-Sperre erforderlich, um dies zu beheben. Jede ausführbare C-Datei wird zuerst gelesen und dann ausgeführt. Dies ist mit dem interpretierbaren Code genauso einfach wie mit ausführbarem Code. Die meisten (Shell-) Skripts sind auch nicht länger als die meisten ausführbaren C-Dateien, sodass beide zuerst geladen werden können. Die Tatsache, dass frühere Implementierungen zuerst eine Zeile lesen, dann die Datei schließen und dann wieder öffnen (und diese Race-Bedingung dadurch erlitten hat), ist nicht wesentlich. es war einfach eine uralte Umsetzung. Ist dies nicht einfach in allen Unix-Implementierungen durch das Lesen der gesamten interpretierbaren Skriptdatei universell fixierbar?

  • Die zur Ausführung einer bestimmten Funktion erforderliche Laufzeit ist anfällig, dies gilt jedoch sowohl für C-Code als auch für den Interpreter. sagen wir, Shell- oder Python-Skripte fügen anfällige Laufzeiten hinzu?

  • Jede ausführbare (C) -Datei kann andere Shell-Programme auf dieselbe Weise aufrufen wie eine interpretierte Sprache. Programme, die aneinander übergeben wurden, wurden ursprünglich als Unix-Methode bezeichnet, daher sollten wir dies häufig tun.

All dies ist mehr oder weniger in Gilles 'Antwort enthalten, vielleicht mit Ausnahme des expliziten "Alles lesen, zuerst ausführen". Stattdessen werden Implementierungen von / dev / fd / äquivalent beschrieben.

so vermisse ich es immer noch. Was ist eigentlich anders? (das einzige Sicherheitsmerkmal ich denken kann, ist, dass suid Skripte durch das Verbot, wir haben es schwieriger für noobs schreiben alle setuid - Skripten.)

Gab es ein Komitee, das ihre Entscheidung für Ubuntu getroffen und erklärt hat, wo ich die Motivation lesen kann?

/ iaw

0

2 Antworten auf die Frage

0
jjlin

Sicher, es ist möglich, die Implementierung zu ändern, um sicher zu sein, aber in der Praxis erfordert dies die Zusammenarbeit aller Unix-Hersteller und eine große Umschulung der Benutzer. Wenn Sie eine solche Anstrengung koordinieren können, erhalten Sie mehr Leistung. :) Die Alternative (z. B. das Festhalten mit Setuid-Wrapper-Programmen) kann unbequem sein, ist aber nicht untragbar.

Anders ausgedrückt, es gibt gute Gründe, warum wir immer noch nicht richtig buchstabieren erstellen . Der Aufwand, der erforderlich ist, um dies zu beheben, wird nicht als dem Nutzen angemessen bewertet.

thx, aber das entgeht mir auch (Wortspiel?). Jede Unix-Distribution kann dies tun. es muss nicht koordiniert werden. creat muss vermutlich genauso sein wie bei POSIX?! ivo Welch vor 9 Jahren 0
Es muss koordiniert werden. Niemand möchte ein Skript schreiben, das setuid ausführen soll, und dann feststellen, dass einige Benutzer es nicht erfolgreich ausführen können, da das jeweilige Betriebssystem keine Unterstützung hinzugefügt hat. jjlin vor 9 Jahren 0
0
David Paige

Es ist viel einfacher, ein Shellskript zu ändern als eine Binärdatei. Außer einem Editor sind keine speziellen Werkzeuge und Schreibzugriff auf die Datei erforderlich. Sogar sed funktioniert, aber das ist immer noch ein Stream-Editor.

Aus sicherheitstechnischer Sicht ist es jedoch sinnvoll. Sie können ein Skript über sudo oder su bis root ausführen. Sie können jederzeit ein suid-Programm innerhalb eines Skripts ausführen.

Verwandte Probleme