Hallo,

ich betreibe ein Ubuntu-System, das nur eine sehr eingegrenzte Funktion als NoMachine Server ausübt.

Dementsprechend möchte ich User (per likewise authentifiziert) per default extrem eingrenzen - ich Grunde genommen soll sogar nur ein bestimmtes Bash-Skript (mit variablen Parametern) von den Usern aufrufbar sein. Ist es möglich, die Systemumgebung und Rechte von Nutzern derart einzugrenzen?

Danke und Gruß highlife

Du willst deine Benutzer in eine selbst zu bestimmende Gruppe einordnen. Zitat:

Die Hauptgruppe eines Benutzers spielt im Zusammenhang mit den Zugriffsberechtigungen auf Dateien und Verzeichnisse eine Rolle. Jede Datei ist immer Eigentum genau eines Benutzers. Daneben ist den Dateien aber auch eine Gruppe zugeordnet. Wenn ein Benutzer eine Datei erzeugt, dann wird seine Hauptgruppe als Gruppe bei der erzeugten Datei eingetragen.

Damit müsstest du als Erzeuger/Besitzer des genannten Bash-Skriptes alle weiteren Benutzer in die Hauptgruppe eintragen über die du das Skript hinterlegt hast, damit die entsprechenden Rechte ohne viel Aufwand zugewiesen werden können – soweit ich es verstehe. Um die Rechte der weiteren Benutzer einzugrenzen musst du prüfen, welche Funktionalitäten deines "NoMachine-Servers" (was soll das genau bedeuten?) eine bestimmte Gruppenzugehörigkeit erforderlich machen und die Benutzer von vorneherein ausschließlich diesen Gruppen zuweisen. Vermutlich wirst du die Administration über ein Terminal bevorzugen. Wie sollen die weiteren Benutzer sich an dieser Maschine anmelden; d.h. was ist likewise?

Danke für die Antwort. Durch die Authetifizierung der Nutzer mittels likewise-open werden diese automatisch in die Gruppe domain_users eingeordnet. Verstehe ich es richtig, dass man diese Gruppe extrem beschneiden kann? Ich weiß einfach nicht, wie.

Hier noch zur Info: NoMachine

Kannst du präzisieren, was genau erreicht werden soll? Soweit ich nachvollziehen kann, nutzt du NoMachine NX Free Edition; wozu genau?

Für remote-Zugriffe auf andere Systeme, das spielt in diesem Zusammenhang aber keine große Rolle.

Entscheidend an der ganzen Sache ist, dass sich User am System authentizifizeren (über SSH) und ausschließlich ein bestimmtes Skript aufrufen dürfen sollen.

Die halbe Antwort habe ich ja schon: alle User fallen in eine bestimmte Gruppe; jetzt muss ich die Gruppe nur noch entsprechend einschränken können.

highlife schrieb:

Entscheidend an der ganzen Sache ist, dass sich User am System authentizifizeren (über SSH) und ausschließlich ein bestimmtes Skript aufrufen dürfen sollen.

Wenn du schon von SSH sprichst, warum nutzt du es dann nicht? Zitat:

Mit den Direktiven AllowUsers und AllowGroups bzw. DenyUsers und DenyGroups lässt sich noch genauer festlegen, welche Benutzer sich anmelden dürfen und welche nicht. Dies empfiehlt sich besonders bei Servern. AllowGroups admin verbietet bspw. allen Benutzern, die keine Mitglieder der Gruppe admin sind, den Zugriff.

Mir scheint, deine Frage bezieht sich auf die Konfiguration von likewise-open ?
edit: sehe gerade, dass likewise-open als Ubuntu-Paket verfügbar ist

Die Konfiguration von ssh bringt hier nicht. Die Nutzer müssen sich anmelden dürfen, aber gleichzeitig nur zum Ausführen eines bestimmten Skripts in der Lage sein.

Hi, schau dir mal rbash an.

Bei public key auth kann mein in der authorized_keys festlegen, dass sofort ein bestimmtes command ausgeführt wird und sonst nichts, ka obs sowas auch für diene auth methode gibt, da müsste man sich aber für die Paramterübergabe was überlegen.

highlife schrieb:

Die Konfiguration von ssh bringt hier nicht. Die Nutzer müssen sich anmelden dürfen, aber gleichzeitig nur zum Ausführen eines bestimmten Skripts in der Lage sein.

Möglicherweise ist folgendes Vorgehen ausreichend; das von mir allerdings nur unter meiner Xubuntu 10.04-Installation getestet wurde. Vermutlich aber auch für Ubuntu (Gnome) anwendbar.

Zunächst habe ich einen Benutzer angelegt, der über kein eigenes Home-Verzeichnis verfügt:

sudo adduser --no-create-home <benutzer2>

Es muss ein Passwort angegeben werden (ich habe mir welche mit 'pwgen' erzeugen lassen). Dann abgemeldet und <benutzer2> angewählt. Unter Xubuntu 10.04 habe ich auf dem Anmeldebildschirm ein Panel, auf dem eine Sitzungs/Session-Auswahl möglich ist:

• Xubuntu Session

• Xfce-Sitzung

• xterm

Mit dem ohne Home-Verzeichnis angelegten <benutzer2> kann ich nur xterm anwählen und habe dann ausschließlich ein Terminal-Fenster, in dem ich nur sehr eingeschränkt agieren kann. Mit exit verlassen und zum Anmeldebildschirm zurückkehren.

Mit dem Benutzer <administrator> anmelden. Im Terminal kann ich mittels

<administrator>@rechner:~$ su <benutzer2>
Passwort:

zu <benutzer2> wechseln und mittels id mir seine Gruppen anzeigen lassen. Mit exit verlassen.

Ob es wirklich wichtig ist kann ich nicht genau sagen; es scheint mir aber sinnvoll zu sein, für weitere Benutzer und das zu verwendende Skript eine neue Gruppe <sonderrechte> zu erzeugen:

sudo groupadd <sonderrechte>

Bestehenden Benutzer einer bestehenden Gruppe hinzufügen:

sudo usermod -aG <sonderrechte> <benutzer2>

Aktuellen Benutzer <administrator> hinzufügen und Gruppenzugehörigkeit sofort aktivieren:

sudo adduser <administrator> <sonderrechte>
newgrp <sonderrechte>

Anschließend mit id überprüfen.

Ich habe eine Textdatei test.txt mit Inhalt hallo Welt erzeugt, um den Zugriff und die Rechte zu prüfen.

<administrator>@rechner:~$ cat test.txt
hallo Welt

Erstmal an einem Ort hinterlegen, an dem alle Benutzer sie erreichen können:

sudo cp test.txt /test.txt

Damit liegt die Datei im Verzeichnisbaum unter 'root' (/). Dann den Eigentümer auf root und die Gruppe auf <sonderrechte> ändern:

sudo chown root:<sonderrechte> /test.txt

Zuletzt die Rechte ändern und für alle Benutzer les-, schreib- und ausführbar machen:

sudo chmod a+rwx /test.txt

Anzeigen lassen mit:

ls -l /test.txt

Jetzt kann ich als angemeldeter <benutzer2> weitgehend ausschließlich nur diese eine Datei manipulieren:

<benutzer2>@rechner:/home/<administrator>$ nano /test.txt

Könnte sein, dass dieses Vorgehen den Anforderungen an dein Skript genügt; allerdings vermutlich ohne die von mir im Test gesetzten Schreibrechte.

Nachschlagen:
Befehlsreferenz_1
Befehlsreferenz_2
man adduser

@zeTTel

Also das schränkt ja nichtmal geringfügig irgendwas ein.

Du hast nen ganz normalen neuen Benutzer angelegt und den umständlich in ne sinnfreie Zusatzgruppe gesteckt. Dann ein script nach / gelegt was eher in /usr/local/bin gehört (warum gibt man die Datei der gruppe wenn man dann a+rwx macht) und irgendwas mit noch so nem Administrator gemacht wo ich den Sinn nicht verstanden habe.

Der Benutzer benutzer2 ist wie gesagt 0 eingeschränkt, ausser das er kein home hat und deswegen nur in /tmp sachen ablegen kann statt in /home/benutzer2. Er kann alle Programme (nicht nur das script) starten und voll nutzen. kann in alle verszeichnisse wechseln die nicht root vorbehalten sind und dort die Dateien lesen und kopieren. Er kann ausserdem /tmp und den ram zumüllen und die cpu beliebig auslasten und sich ne toolsammlung mit wget nachladen.

Also egal wie mans macht, aber ne normale shell darf man einem Benutzer der eigentlich nur ein einziges script ausführen darf auf garkeinen Fall geben, eigentlich ist auch die von mir vorgeschlagene rbash schon viel zu viel.

salocin schrieb:

Also das schränkt ja nichtmal geringfügig irgendwas ein.

Im Gegenteil habe ich den Eindruck, dass es für die Zwecke von highlife schon zuviel Einschränkung ist, weil mit einem Benutzer ohne Home-Verzeichnis keine Desktop-GUI verfügbar ist.

Du hast nen ganz normalen neuen Benutzer angelegt

Nun, was meint "normal"? Das System will ja irgendwie noch benutzbar sein.

und den umständlich in ne sinnfreie Zusatzgruppe gesteckt.

Bis jetzt ist sie vielleicht sinnfrei; aber sobald likewise-open bzw. die ominöse NoMachine noch ins Spiel kommen sollen wäre das möglicherweise nicht mehr der Fall.

Dann ein script nach / gelegt was eher in /usr/local/bin gehört

Ok? Ich behaupte nicht, dass meine Vorgehensweise voll ausgereift sei.

(warum gibt man die Datei der gruppe wenn man dann a+rwx macht)

Damit weitere Dateien, die möglicherweise in Zusammenhang stehen aber andere Rechte erfordern, noch derselben Gruppe hinzugefügt werden können.

und irgendwas mit noch so nem Administrator gemacht wo ich den Sinn nicht verstanden habe.

Was genau meinst du mit "irgendwas"?

Der Benutzer benutzer2 ist wie gesagt 0 eingeschränkt, ausser das er kein home hat und deswegen nur in /tmp sachen ablegen kann statt in /home/benutzer2. Er kann alle Programme (nicht nur das script) starten und voll nutzen.

Nur Terminal-Programme die ohne sudo verwendbar sind; es kann nichts installiert/deinstalliert werden.

kann in alle verszeichnisse wechseln die nicht root vorbehalten sind

Kann nur und ausschließlich in root-Verzeichnisse wechseln, soweit ich sehen kann.

und dort die Dateien lesen und kopieren. Er kann ausserdem /tmp und den ram zumüllen und die cpu beliebig auslasten und sich ne toolsammlung mit wget nachladen.

Klar kann, wer Dreck machen will, den produzieren. Allerdings kommt der <benutzer2> nach allem was ich mir vorstellen kann nicht in die Lage 'sudo' zu nutzen. Womöglich kannst du mich eines besseren belehren.

Also egal wie mans macht, aber ne normale shell darf man einem Benutzer der eigentlich nur ein einziges script ausführen darf auf garkeinen Fall geben, eigentlich ist auch die von mir vorgeschlagene rbash schon viel zu viel.

Klar ist, dass mit den geforderten Restriktionen eine Spezial-Konfiguration notwendig ist die eigentlich kein Ubuntu-Linux mehr sein kann sondern irgendwas Marke Eigenbau bedeutet.

Um nochmal etwas Licht in die Sache zu bringen: Im Grunde genommen macht der NoMachine Server nichts anderes, als einen Benutzer sich über den SSH-Daemon anmelden zu lassen und dann über ein Skript (nämlich genau das einzig zu erlaubende) dafür zu sorgen, dass der Nutzer ein X-Display bekommt.

Aber diese Details möchte ich eigentlich ausblenden, weil sie keine Rolle spielen. Der Login über SSH muss möglich sein, aber das anschließende Ausführen beliebiger Programme (z.B. eines xterms) eben nicht. Und genau auf diesen Mechanismus habe ich keinen Einfluss..

Wenn es irgendwie die Möglichkeit gäbe, den Aufruf eines Users (egal welchen) an ein Skript zu binden, hätte ich ja schon gewonnen. So eine Art "Standard-Alias" für alle Aufrufe, der eine Prüfung durchführt und anschließend den Original-Aufruf absetzt (oder eben nicht).

Im Grunde willst du ein 'Wohnzimmer mit vielen Schaltern, Fenstern und Türen' zu einem 'fensterlosen Raum mit einer Tür und einem einzigen Schalter in der Mitte' umbauen. Da würde ich mir doch eher noch überlegen, wen ich mir so nach Hause einlade.

ist "public key auth only" eine denkbare Option? klar würde das umstellung bedeuten, aber evtl ist diese Hürde einfacher zu nehmen.

Dann kann sehr einfach ein script angegeben werden das automatisch gestartet wird und beim beenden des scripts bricht die Verbindung ab (so nutze ich das im Büro).

Ansonsten fällt mit nur chroot ein, allerdings hab ich das mit dem NoMachine Server dahingehend nicht ganz verstanden. Soll dieser nicht gerade den Benutzern ein ganz normales Arbeiten auf dem Server ermöglichen? Oder arbeiten diese in einer Virtuellen umgebung sollen wirklich nichts auf dem Server selber anpacken dürfen?

@zeTTel: sry war evtl was hart formuliert. Aber ich hab das auch grade nochmal getestet, ein so angelegter Benutzer unterscheidet sich über ssh wirklich so gut wie garnicht von einem Benutzer mit home Verzeichnis.

Der Benutzer kann natürlich kein sudo nutzen, ist ja ein normaler Benutzer. Er kann aber halt uname -a, cat /proc/cpuinfo, wget, gcc und so aufrufen und damit natürlich die üblichen privilege escalation Sammlungen laden. Das sich einige Programme am fehlenden Home Verzeichnis stören, kann einfach umgangen werden indem sichd er Nutzer in /tmp eins anlegt und in $HOME einträgt.

Ich denke eine spezielle login shell ist der sinnvollste weg.

salocin schrieb:

Ansonsten fällt mit nur chroot ein, allerdings hab ich das mit dem NoMachine Server dahingehend nicht ganz verstanden. Soll dieser nicht gerade den Benutzern ein ganz normales Arbeiten auf dem Server ermöglichen?

Nein, NoMachine dient in diesem Fall nur als Proxy für RDP und X, auf dem Server selbst soll nicht gearbeitet werden.