www-data zu nogroup hinzufügen -> Sicherheitsrisiko?

[lordg2009]

Hi,

Folgendes Problem.
Auf meinem lokalen Linux-Server läuft der Streaming-Server Plex. Auf dessen Datenbank möchte ich mit einem php-Script über apache2 zugreifen und ein paar Sachen aus der Datenbank auslesen, da mir in der Plex-Suchfunktion noch eineige Sachen fehlen. Der Besitzer der Datenbank ist 'plex', Gruppe 'nogroup'. Zugriffe bekomme ich also mit www-data, unter dem alle php-Scripte ausgeführt werden nicht auf die plex Datenbank.

Nun ist ja die 'nogroup' Gruppe eine Gruppe, die auch von vielen Diensten genutzt wird, deshalb meine Frage:
Ist es gefährlich, 'www-data' zur 'nogroup'-Gruppe hinzuzufügen, um so Zugriff auf diese Datenbank zu bekommen?

Das einfachste wäre es ja, wenn ich das php-Script von apache mit den Benutzerrechten von 'plex' ausführen kann, aber da weiß ich nicht, ob das geht.

Vielen Dank

 

[Stype]

Du solltest nicht die nogroup-Gruppe verwenden, sondern eine extra Gruppe dafür erstellen. nogroup passiert auch gerne mal wenn er dich nur als "Gast" registriert und du willst ja nicht das fremde ausversehen mal auf deine Datenbank zugreifen

 

[mensch183]

Der Sinn von nogroup ist, eine Gruppe zu haben, die garantiert keinerlei Privilegien hat. Der Gruppe sollten also weder Files gehören noch irgendwelche anderen Rechte, die über "hier darf sowieso jeder" hinausgehen. "nouser" analog für Nutzer.

Wenn deine Datenbank nogroup gehört, ist das schon mal nicht im Sinne des Erfinders und sollte geändert werden. Dann sogar www-data zum Mitglied von nogroup zu machen, um www-data Zugriffsrechte auf die Datenbank zu verschaffen, pervertiert die Idee von nogroup komplett.

Nun ist ja die 'nogroup' Gruppe eine Gruppe, die auch von vielen Diensten genutzt wird

Dienste setzt man extra auf uid=nouser und gid=nogroup, damit sie - selbst wenn sie buggy sind - möglichst wenig dürfen und damit auch möglichst wenig kaputtmachen können. nouser/nogroup dient nicht um Rechte zu bekommen sondern um Prozessen ganz bewußt maximal viele Rechte zu _entziehen_. Solche Dienste lesen z.B. ihre privaten Konfigfiles BEVOR sie zu nouser/nogroup gemacht werden.

 

[Daaron]

Dienste setzt man extra auf uid=nouser und gid=nogroup, damit sie - selbst wenn sie buggy sind - möglichst wenig dürfen und damit auch möglichst wenig kaputtmachen können.

Da die meisten Dienste irgendwo irgendwas dürfen müssen, kriegen sie eine eigene U/G-Kombo, also z.B. vmail:vmail, und vmail ist der einzige, der jemals was in /var/vmail/ zu schaffen hat.

Was Webserver angeht: Noch rigorosere Trennung. Keine Webseite sollte unter www-data laufen. www-data sollte nur dazu da sein, den Webserver zu forken und für jedes Web-Projekt eine separate Instanz mit separatem User zu starten. Siehe z.B. apache2-mpm-itk

 

[mensch183]

Auch ein nouser/nogroup-Dienst kann sich ggf. noch reichlich betun, denn er nimmt die vorm Drop der Privilegien schon geöffneten Files/Sockets mit. Nur neue Sachen darf er nicht. Brauch er neue Sachen, kommt man mit nouser/nogroup nicht hin.

 

[Daaron]

Wie gesagt, der Standard in allen mir bekannten Distributionen ist: Jedem Dienst sein eigener U/G....

 

[lordg2009]

OK, aber wie kann ich jetzt mit meinem PHP Script auf die Plex Datenbank zugreifen, die mit dem Benutzer plex und der Gruppe nogroup läuft?

Prinzipiell ist es kein Problem, die Gruppe der Datenbank manuell zu ändern, nur wäre das wahrscheinlich nach jedem Update wieder weg, außerdem könnte Plex vlt. selbst dann nicht mehr darauf zugreifen.

 

[Hypfer]

Wenn es sich um einen rein lokalen und nicht aus dem Internet erreichbaren Server (Beachte IPv6!) handelt ists eigentlich relativ wurst was die Gruppen usw angeht.

Spiel bitte nicht an den Berechtigungen der Datenbank selber rum. Das wird doch nichts..

 

[gimmebytes]

Was für eine Datenbank ist das denn? Wenn es z.B. eine MySQL Datenbank ist, solltest du doch ohne Probleme über die MySQL API darauf zugreifen können? Alternativ kannst du natürlich eine neue Gruppe anlegen, die sich - wie hier auch schon beschrieben - Plex und der Apache teilen. Ich denke, auf einem Heimserver sollte dies kein größeres Problem darstellen. Wenn du ganz Faul bist, kannst du auch die Zugriffsrechte der Datenbank so setzen, das andere sie lesen können.

Man sollte sich immer die Frage stellen: Wie groß ist der Aufwand zum Schützen im Verhältnis zur Beute. Ich denke bei ner Anwendung zu Hause ist letzteres eher gering. Vorallem wenn die Kiste nicht direkt übers WWW erreichbar ist.

 

[lordg2009]

Die Datenbank basiert auf sqlite.

Der Server ist über www nicht direkt erreichbar.