RESTful serverseitiges filesystem absichern

[Erich (Gast)]

Hallo Web-Programmierer,
eine Frage zur Sicherheit eines online-Editors, welcher den angemeldeten 
Usern ein Server-seitiges Filesystem im Browser über eine RESTful API 
zugänglich macht:

Auf dem Linux-Server liegen unter /home/<user1>, /home/<user2>, ... die 
persönlichen Verzeichnisse der registrierten User. Nach dem Einloggen 
als <userxyz> soll dieser User unter http://server/files/path/to/file 
auf seine Datei /home/<userxyz>/path/to/file zugreifen können.

So weit, so gut. Es funktioniert, indem ich den Anfangsteil der URL 
abschneide und durch /home/<userid> ersetze, wobei die <userid> aus der 
Authentifizierung kommt, und den Dateiinhalt ausliefere. Sämtliche 
Dateien unter /home habe ich momentan für den Prozess, unter dem der 
Webserver läuft, les- und schreibbar gemacht.

Ich habe auch einen ersten Schritt zur verbesserten Sicherheit 
eingebaut, indem ich Pfade wie abc/../def verbiete, um zu vermeiden, 
dass jemand unter http://server/files/../../home/<otheruser>; auf Dateien 
zugreift, die ihn nichts angehen.

Ich vermute, es gibt noch viel mehr Einfallstore. Woran muss ich da 
denken?

Sicherer wäre es meiner Meinung nach, wenn ich sämtliche 
Dateioperationen mit den Benutzerrechten des jeweils eingeloggten Users 
ausführen kann. Ist dies möglich, dass der Webserver (Apache Tomcat) 
bestimmte Operationen mit anderen Rechten ausführt? Der Server läuft 
unter Linux.

Danke Euch schon mal für hoffentlich hilfreiche Tips,
Erich

[Daniel A. (daniel-a)]

Ich hoffe das nur du Benutzer erstellen und dessen Berechtibungen 
einstelen kanst, sonst gibt es einige Spezialfälle an die man denken 
muss.
Überprüffe dass dein server backslaschs statt slashs in pfaden nicht 
akzeptiert, dass dieser mit nullbytes keine probleme hat und dass ../ 
urlescaped in verschiedenen codierungen ordnungsgemäss erkannt wird.

Erich schrieb:
> Sicherer wäre es meiner Meinung nach, wenn ich sämtliche
> Dateioperationen mit den Benutzerrechten des jeweils eingeloggten Users
> ausführen kann. Ist dies möglich, dass der Webserver (Apache Tomcat)
> bestimmte Operationen mit anderen Rechten ausführt? Der Server läuft
> unter Linux.

Apache Tomcat ist java, oder? In java ist dies nicht möglich. Du kannst 
in java aber libraries einbinden. Schreibe also einfach eine lib in c 
die dass kann und binde diese ein.

Falls die nutzer jemals auf die idee kommen könnten dateien für andere 
freigeben zu wollen musst du das konzept eventuell nochmal überdenken.

[avr (Gast)]

http://superuser.com/questions/632618/best-practice-for-access-permission-to-users-for-apache-tomcat

Einfach die entspr. user in eine gesonderte Gruppe stecken, evt. Rechte 
nochmal einschränken.

[Noch einer (Gast)]

Soweit ich weiß, kann man innerhalb des Tomcat den Benutzer nicht 
wechseln.

Eine Möglichkeit wäre, du verbietest in der catalina.policy erst mal 
alles, was der Tomcat nicht unbedingt braucht. Dann startest du für jede 
Session einen zusätzlichen Prozess, der zuerst chroot und setuid macht 
und dann Kommandos für Dateizugriffe ausführt.

[Gerd E. (robberknight)]

Noch einer schrieb:
> Dann startest du für jede
> Session einen zusätzlichen Prozess, der zuerst chroot und setuid macht
> und dann Kommandos für Dateizugriffe ausführt.

Ich weiß nicht ob das so ne gute Idee ist: um setuid ausführen zu können 
musst Du root sein. Ich würde den Tomcat nicht als root laufen lassen 
wollen.

Außerdem hast Du dann für jeden einzelnen Zugriff nen fork() & exec(). 
Das kann den Server sehr schnell in die Knie zwingen.

Leider habe ich keine Lösung vorzuschlagen: auf diese Weise auf Dateien 
zuzugreifen ist nicht ganz so einfach. Früher bei FTP war das gang & 
gebe, mit der Folge daß der ftpd als root laufen musste und alle paar 
Wochen ein neuer fieser Exploit für irgendeine Implementation bekannt 
wurde.

[Noch einer (Gast)]

Zumindest das root-Problem ließe sich entschärfen. Tomcat läuft ohne 
Rechte, startet ein kleines Programm mit s-bit auf root, was als erstes 
chroot und setuid aufruft.

Oder falls setuid ohne chroot ausreicht; der Benutzer meldet sich mit 
seinem Linux-Passwort beim Tomcat an und Tomcat benutzt damit das sudo.

fork() & exec() bei jedem Zugriff - eigentlich nicht so wild, CGI macht 
das auch. Muss aber nicht sein. fork() & exec() beim Login sollte 
ausreichen.

[Noch einer (Gast)]

Ftp... das was das Stichwort...

Die Benutzer melden sich mit dem Linux Passwort beim Tomcat an. Mit 
einer der FTPClient Libraries mach der Tomcat eine Verbindung zum Ftpd 
auf localhost auf. Ftpd sicher konfigurieren - da gibt es ja einige 
Erfahrungen.