2 Instanzen von Apache - geht das, wenn ja - wie?

[Hans-Dietrich Kirmse]

Hallo Enrico,

ersteinmal danke für deine Antwort. Allerdings muss ich zugeben, dass
ich das nicht alles raffe (was aber für einen reinen Anwender auch
nicht zwingend ist).

Enrico Weigelt schrieb:
> * Hans-Dietrich Kirmse <hd.kirmse at gmx.de> schrieb:
> 
> moin,
> 
>> das es nicht sauber gelöst ist, das leuchtet mir schon ein, weil in der
>> PHP-FAQ angegeben ist, dass die Lösung unsicher ist, also (irgendwie?)
>> ausgehebelt werden kann. Allerdings sehe ich noch keinen Ansatz dafür.
> 
> Mit safe_mode muß _jede_ einzelne API-Routine - einschließlich
> _aller_ extensions separat auf potentielle Ausbruchsmöglichkeiten
> überprüft und ggf. speziell angepaßt werden.

das hattest du schonmal geschrieben. Allerdings ist das keine Begründung
(schon gar keine verständliche Begründung), sondern nur die wiederholte
Feststellung, was du m.E. schonmal zum Ausdruck gebracht hast.

> Der klassische Unix-Ansatz hingegen ist, jeden User unter seiner
> eigenen UID laufen zu lassen (dh. auch entsprechend strikt getrennte
> Prozesse) und alles über die Filesystem-Permissions (und ggf. 
> auch capabilities) zu lösen.

Das ist mir ja bekannt. Und mir ist auch klar, dass diese Lösung sicher
ist. Aber es geht nicht um einen Webserver mit vielen Nutzern, der im
Internet steht, sondern es geht "nur" um einen Schulserver, dabei um die
public_html-Verzeichnisse - die übliche Nutzerzahl liegt um die 500.

>>> a) _alle_ extensions müssen ihn entsprechend berücksichtigen
>>>   (sonst wird er schnell wirkungslos)
>> verstehe ich nicht. nehmen wir an, es kommen 5 solcher Extensions zum
>> Tragen. Es ist doch letztlich völlig egal, an welcher Stelle diese
>> Extension (safe-mode) zur Wirkung kommt egal ob an 1. 2. ... 5. Stelle.
> 
> Nein. Jede einzelne extension-Routine, die ggf. auf abzuschirmende
> Resourcen (Filesystem, Prozesse, etc, etc) zugreift, muß entsprechend 
> angepaßt werden. 

Weshalb?

> Außerdem lassen sich dann auch eventuelle local-
> exploits innerhalb einer extension, die bei separaten UIDs/Prozessen
> nur den angreifenden User selbst betreffen könnten, dann gleich auch
> alle anderen User angreifen.
> 
> Im Massenhosting damit völlig unbrauchbar.

darum geht es *NICHT*. wie gesagt, es geht nur um einen Schulserver.
Ich bilde mir ein, du warst am Albert-Schweitzer-Gymnasium in Erfurt.
auch da haben doch die Schüler ein Homeverzeichnis mit PHP (also Modul
im Apache). Und wenn ich richtig liege mit meiner Vermutung, sprich
Spezi Erfurt, dass Angriffspotential ist doch deutlich größer als an
einer normalen Schule. Trotzdem ist das meines Wissens auch an der
Schule immer noch so. (da beißt sich was - oder?)

>> Wenn die Datei nicht unter der UID des Nutzers ist, dann wird diese
>> PHP-Datei nicht mehr ausgeführt - sprich abgebrochen. Gerade bei dieser
>> Sache verstehe ich nicht, wie das berücksichtigt werden muss.
> 
> Dieses "Feature" ist ziemlich sinnlos. Es schützt allenfalls vor
> dem spezifischen Fall, daß es einem angreifenden User gelingt, 
> scripte in fremden User-Verzeichnissen einzuschleusen. Gegen 
> Manipulation von data files (die nicht als script ausgeführt
> werden) oder bereits existierenden Scripts hilft das nicht.

diese Antwort ist mir zu pauschal. natürlich ist der "safe-mode" allein
kein Allheilmittel, aber den jetzt einfach als ziemlos nutzlos abzutun,
ist mir viel zu schnell. Es gibt ja auch noch weitere Einstellungen für
PHP, z.B. auf welche Verzeichnisse es zugreifen kann und wo es seine
Bibliotheken her holen soll ... . Im Zusammenhang betrachtet bekommt man
da m.E. schon eine hohe Sicherheit hin.

>>> b) wichtige features, zB. exec() gehen nicht mehr.
>> wieso nicht? safe-mode heißt doch (so wie ich das verstanden habe), dass
>> nur Dateien gelesen bzw. bearbeitet werden können, die den gleichen
>> Owner haben, wie die PHP-Datei, die gerade ausgeführt wird. Wieso kann
>> dann ein Script per exec() nicht ausgeführt werden, wenn es als Owner
>> eben den User hat, der auch der Owner der PHP-Datei ist und das per exec
>> aufzurufende Script z.B. für alle ausführbar ist.
> 
> exec() dient dazu, _beliebige_ (idR. binäre) Programme 
> auszuführen, und zwar als eigenständige Prozesse - nicht
> innerhalb des PHP-Interpreters. In dem Falle kann dann der
> safe_mode (innerhalb des sub-Prozesses) nicht mehr greifen.

leuchtet mir nicht ein. der safe-mode gibt doch an, welche Prozesse
ausgeführt werden können (mit exec). Insofern kann er mit exec dann eben
nur auf seine (binären) Dateien zugreifen. das ist doch gut und macht
doch durchaus Sinn!

> Ergo: entweder man verbietet exec() komplett, oder der safe_mode
> ist wirkungslos.

für mich völlig unlogisch. :(

> Die einzig sinnvolle Lösung ist, alles über separate Prozesse
> unter eigenen UIDs abzubilden und alles weitere wie gewohnt den
> Kernel erledigen zu lassen (dafür ist er ja schließlich da).
> An der Stelle kann man dann auch noch feiner granuliertere
> Abschirmungen via Containers machen (zB. um fremde Prozesse
> unsichtbar zu machen, Netzwerkverkehr regeln, etc, etc)

Das will ich alles nicht bestreiten. Mir geht es um die Schwachstellen
des safe-modes. Dazu kam leider nichts Substanzielles - sorry. Genau das
würde mich aber (immernoch) interessieren.

Mit freundlichen Grüßen
Hans-Dietrich