Diskrepanz der admin Beutzerrechte zwischen ssh und DSM

[Micha81]

Logge ich mich als admin über das Web Frontend ein, dann kann ich in allen Benutzerkonten tun und lassen was ich will. Das ist auch so gedacht.
Per ssh Terminal sieht das aber völlig anders aus. Ich kann jetzt als admin die Benutzerkonten sehen aber ein cd user_x führt zu der Fehlermeldung can't cd to user_x

Schaue ich mir die Benutzerrechte an dann ist das formal auch in Ordnung denn der admin hat für das home Verzeichnis user_x die Rechte drwx------
Bleibt die Frage woher die Diskrepanz kommt und was sich in der Filestation abspielt ?? Warum hat der admin dort offensichtlich andere Rechte ?

 

[cyorps]

der admin hat für das home Verzeichnis user_x die Rechte drwx------

Erkläre mal in Worten, welche Rechte dir hier angezeigt werden und sage einmal, wer der Eigentümer dieses Verzeichnisses ist.

 

[Fusion]

Wenn das Home-Verzeichnis von user_x die Rechte "drwx------" hat, dann heißt das:
Besitzer: rwx
Gruppe: ---
Other: ---

Demnach hat nur der Besitzer vollen Zugriff.

Habe gleich mal einen Blick bei mir auf DSM und ssh geworfen.

Bei mir ist Admin Mitglied in "administrators" und "users" und hat "Lesen/Schreiben" für "homes".
Ebenso hat "user_x" bei mir rwx,r-x,r-x auf seinem Home-Verzeichnis und damit darf der admin zumindest lesend auf die Ordner zugreifen.

Ich würde mal für admin und user_x die Benutzergruppen und Privilegieneinstellungen in der Systemsteuerung kontrollieren.

 

[Micha81]

Wenn das Home-Verzeichnis von user_x die Rechte "drwx------" hat, dann heißt das:
Besitzer: rwx
Gruppe: ---
Other: ---

Demnach hat nur der Besitzer vollen Zugriff.

Ist bei mir genauso und so verhält sich der ssh Terminal ja auch. Ist nach meinem Verständnis also korrekt.

Habe gleich mal einen Blick bei mir auf DSM und ssh geworfen.

Bei mir ist Admin Mitglied in "administrators" und "users" und hat "Lesen/Schreiben" für "homes".
Ebenso hat "user_x" bei mir rwx,r-x,r-x auf seinem Home-Verzeichnis und damit darf der admin zumindest lesend auf die Ordner zugreifen.

Ich würde mal für admin und user_x die Benutzergruppen und Privilegieneinstellungen in der Systemsteuerung kontrollieren.

Der "user_x" hat bei mir rwx,---,--- auf seinem Home-Verzeichnis. Das soll auch so sein. Bei rwx,r-x,r-x hätten ja alle Benutzer zumindest Leserechte und das ist nicht gewünscht.

Nur die File Station kümmert sich nicht um die Rechte. Hier hat der Admin volle Zugriffsrechte auf ALLE Benutzer-Home Verzeichnisse und kann dort auch munter löschen usw. Somit verhält sich die File Station bezüglich der Rechte völlig anders als der ssh Terminal. Es sieht für mich so aus als wäre der admin in der File Station mit root Rechten unterwegs.

 

[Fusion]

Hallo Micha,

ich konnte dein Problem jetzt nachvollziehen.

Es sieht so aus, als ob die Einträge die ich via "Systemsteuerung - Gemeinsame Ordner" tätige Vorrang bekommen würden.
In der Liste mit gemeinsamen Ordners ist bei mir auch "homes" aufgeführt. Die Privilegieneinstellungen für diese Freigabe listen bei mir auch admin mit Lesen/Schreiben. Wenn ich hier den Zugriff auf Lesen reduziere kann ich als Admin in der Filestation keine Datei mehr anlegen, wenn ich den Zugriff hier komplett entferne (kein Häkchen gesetzt für homes (auch nicht "kein Zugriff")), dann sehe ich die Freigabe homes in der Filestation als Admin gar nicht mehr.

Die Filesystem ACLs die ich mir per ssh ansehe sind von den Änderungen nicht betroffen und verbleiben bei mir als rwx,r-x,r-x.
Hat also den Anschein als würde da mit 2 verschiedenen Layern gearbeitet. Nicht gerade intuitiv ...

 

[Trolli]

Die File Station läuft auf den System-Webserver der DS mit root-Rechten und kennt keine Beschränkungen auf Ebene des Dateisystems. Alle Berechtigungen bekommt die File Station aus den im Berechtigungskonzept der DS hinterlegten Privilegieneinstellungen.

 

[Micha81]

Im Grunde ist also der Benutzer root in der DSM unterwegs und nicht der angemeldetet Benutzer admin. Das habe ich mir zwar schon so gedacht aber danke für die Bestätigung. Ich halte das ehrlich gesagt für ein etwas fragwürdiges Konzept die Rechtevergabe des Dateisystems auf diese Weise auszuhebeln.

 

[süno42]

Hallo,

und täglich grüßt das Murmeltier… Viel Spaß beim Lesen

Grüße,
Süno42

 

[Trolli]

Naja - mit welchen Rechten soll der DSM denn sonst laufen? Es kann ja nicht für jeden User ein eigener Webserver gestartet werden!?!

 

[Micha81]

und täglich grüßt das Murmeltier… Viel Spaß beim Lesen

Die Dinge liegen hier ein klein wenig anders obwohl sie wahrscheinlich die selbe Ursache haben. Dass der DSM mit root Rechten unterwegs ist erscheint mir zumindest teilweise naheliegend. Dass ein an den DSM angemeldeter Administrator aber automatisch diese Rechte übernimmmt obwohl seine Dateisystemrechte das gar nicht hergeben ist einfach eine völlig fragwürdige Implementierung. Ist mir auch so in der Linux/Unix Welt nocht nicht untergekommmen.

Es müssen ja gewisse programmiertechnische Anstrengungungen unternommen worden sein das Rechtesystem auszuhebeln. Es sei denn der Benutzer Admin wird innerhalb des DSM nur vorgegaukelt. Möglicherweise ist das auch der Grund warum admin und root immer automatisch das selbe Passwort haben.

Wie auch immer, es scheint von diesem Mechanismus nur der adminn betroffen zu sein. Von daher kann ich damit leben. In der Konsole melde ich mich daher einfach auch als root an und alles ist gut. Aber natürlich sehe ich seitens Synology hier auch handlungsbedarf.

 

[Trolli]

Auch ein admin kann nicht immer alle Ordner auf der DS über die File Station einsehen, wenn ihm die dazugehörigen Rechte im DSM nicht vorliegen. Allerdings kann der admin sich diese Rechte dann natürlich selber zuteilen.
Aber das ist doch eigentlich immer so bei einem admin - oder etwa nicht? Dass das Rechtesystem hier bewusst ausgehebelt wird, sehe ich ehrlich gesagt nicht. Die Berechtigungen auf Dateisystemebene sind zwar durchaus vorhanden, gesteuert werden die Berechtigungen für den Datenzugriff aber eigentlich über die Rechtevergabe im DSM.

Diese beiden Rechtesysteme kollidieren allerdings an einigen Ecken - das stimmt schon. Allerdings nie in der Weise, dass ein Benutzer Zugriff auf Daten bekommt, den er laut den Einstellungen im DSM nicht haben darf.

 

[Micha81]

Welche Rechte der Benutzer admin haben sollte kann man anhand des Linux Dateisystems sehr leicht nachsehen. Im DSM hat der Benutzer weit darüber hinausgehende Rechte da er offensichtlich mit root Rechten ausgestattet wird. Das ist weder logisch noch korrekt implementiert. Ob man es nun aushebeln oder erweitern oder wie auch iimmer nennen möchte ist letztendlich unerheblich. Im Grunde führt es das Linux Rechtesystem ad absurdum.

Schlimmmer finde ich die Diskrepanz die entsteht sobald ich andere front-ends wie beispielsweise einen Terminal verwende. Aber wie schon gesagt kann ich damit leben aber sauber implementiert geht anders.

 

[süno42]

Die Dinge liegen hier ein klein wenig anders obwohl sie wahrscheinlich die selbe Ursache haben. Dass der DSM mit root Rechten unterwegs ist erscheint mir zumindest teilweise naheliegend. Dass ein an den DSM angemeldeter Administrator aber automatisch diese Rechte übernimmmt obwohl seine Dateisystemrechte das gar nicht hergeben ist einfach eine völlig fragwürdige Implementierung. Ist mir auch so in der Linux/Unix Welt nocht nicht untergekommmen.

Ohne hier jetzt eine Grundsatzdiskussion auszulösen, im Kern sind Analogien vorhanden. Synology macht es sich teilweise zu einfach und zu wenig Gedanken über Sicherheit (jetzt bitte nicht als Wertung für Rechteadaption verstehen).


Viele Grüße
Süno42

 

[Trolli]

Ist das jetzt einfach so dahingesagt? Mir würden da ehrlich gesagt keine Beispiele einfallen. Zumindest nicht für Gedankenlosigkeit. Dass z.B. einige Anwendungen nicht mit den aktuellsten Programmversionen laufen liegt beispielsweise ja nicht daran, dass das den Leuten bei Synology einfach egal ist, sondern solche Sachen müssen eben auch immer ausgiebig getestet werden. Und bekannt gewordene Sicherheitslücken wurden bisher meines Wissens nach immer zügig gefixt...

Und diese Rechtesache - klar geht man da auch einen Kompromisse zugunsten der einfachen Bedienbarkeit ein. Einen vernachlässigten Sicherheitsaspekt sehe ich darin allerdings nicht.

 

[jahlives]

@Michi
der DSM läuft halt einfach unter einem Apache mit root Rechten. Damit hat automatisch der User, der sich als admin anmelden kann auch root Rechte. Denn seine Aktionen laufen in einem Apache Prozess unter root. Drum kannst du via Filestation bzw DSM als admin an allen Homes rumfummeln. Auch wenn das Filesystem an sich admin keinen Zugriff erlauben würde. Via SSH bist du aber wirklich als admin unterwegs, denn ssh Prozesse laufen unter dem User der sich an ssh anmeldet. Dann fehlen dir die Rechte für die Homes.

Wir haben hier schon lange Diskussionen darüber geführt, aber letztlich ist es einfach so, dass man zur Administrierung eines Linux Systems für fast alles root Rechte braucht (z.B. setzen einer Route). Nur schon das pingen eines anderen Hosts erfordert effektiv root Rechte. Denn nur root darf einen icmp Socket öffnet. Klar könnte Synology etwas basteln und für bestimmte Operationen welche kein root brauchen einen unprivilegierten User nutzen. Nur ändert es nichts am Grundproblem: zumindest der erste Prozess auf den der User trifft (beim DSM der Loginprozess) MUSS als root laufen. Dies da es nur root erlaubt ist zu einem anderen User zu wechseln ohne nach einem Passwort gefragt zu werden (su). Es müsste zudem immer einen Master Prozess unter root geben, der dann von den unprivilegierten Prozessen Kommandos, welche root Rechte zur Ausführung brauchen, entgegennimmt. Ob das sicherer ist als schlicht alle Prozesse unter root laufen zu lassen weiss ich ned ;-)

 

[süno42]

Ist das jetzt einfach so dahingesagt? (...) Und bekannt gewordene Sicherheitslücken wurden bisher meines Wissens nach immer zügig gefixt...

Ich werfe mal zwei Stichworte ohne weitere Kommentierung in den Ring "openssl", "mplayer"

Und diese Rechtesache - klar geht man da auch einen Kompromisse zugunsten der einfachen Bedienbarkeit ein. Einen vernachlässigten Sicherheitsaspekt sehe ich darin allerdings nicht.

Alles eine Frage der Systemarchitektur. Alle privilegierten Aktionen können normalerweise über einen minimalen privilegiertern Prozeß (Dienst) laufen, der ganze Webkram darf nicht mit Root-Rechten laufen, da er eine viel zu große Angriffsfläche bietet. Der Sicherheitsgewinn wäre enorm. Bei den Prozessen, die bei der Synology unnötigerweise mit Root-Rechten laufen (u.a. "mplayer" der Audio-Station und "wget" der Download-Station), würden Systemarchitekten schlaflose Nächte bekommen. Für eine ausführliche Beschreibung bitte die Sufu des Forums benutzen.


Viele Grüße
Süno42

 

[Trolli]

Der normale Webserver läuft als nobody, nur der System-Webserver für den DSM als root. Wüsste aber auch nicht, wie man damit sonst administrieren sollte...

 

[Micha81]

Aus dieser Diskussion werde ich mich ausklinken, das wird dann sehr schnell sehr theoretisch. Nur noch etwas, wie ich finde, Lustiges. Wenn ich mich als root via ssh im Terminal einlogge, dann behauptet der DSM 4.2 der admin sei eingeloggt.

 

[jahlives]

Wenn ich mich als root via ssh im Terminal einlogge, dann behauptet der DSM 4.2 der admin sei eingeloggt. [/COLOR]

du wirst ja am DSM als admin angemeldet sein um das zu sehen, oder? ;-)

 

[Micha81]

du wirst ja am DSM als admin angemeldet sein um das zu sehen, oder? ;-)

Nicht notwendigerweise. Es gibt Log files. Ausserdem ist der admin dann über http(s) angmeldet und nicht über ssh wie der DSM meldet. Ist aber nur eine kleine Anekdote am Rand.