Loxberry Rechte/Sicherheit

[hismastersvoice]

Da ich die letzte Zeit ein paar Plug-Ins gemacht habe und auch noch ein paar andere Projekte auf dem Tisch liegen habe ich mir folgende Frage gestellt.

Generell darf der User loxberry ja keine Root-Befehle (sudo) ausführen, was ich verstehe.
Das ich die Rechte für Skripte über den daemon setzten kann ist ja so weit OK.

Würde es nicht Sinn machen das der User loxberry generell die Rechte hat services zu starten und zu stoppen?
Das würde bei einigen Dingen das ganze stark vereinfachen.

Würde das die Sicherheit gefährden?

[Christian Fenzl]

Hi!

Ich hab sowas im Kopf, dass die LB-Basis zukünftig systemd für eigene Plugin-Daemons verwendet.
So wie das jetzt ist, ist es etwas unglücklich. Das ist auch auf meiner „Easy-Plugins“ ToDo-Liste.

Ich weiß nur noch nicht, wie man für den Entwickler möglichst einfach auch mehrere Services machen können soll.

Es soll jedenfalls so werden, dass sich das Plugin selbst nicht um Rechte kümmern muss.

Bezüglich Sicherheit:
Die Prämissen werden sein müssen:
Der User vertraut den Plugins, die er installiert.
Das loxberry-Passwort ist sicher.

Anders wird es nicht gehen, dass man über das CGI Services verwalten kann.

[hismastersvoice]

Hört sich ja schon mal richtig an...

Bin der Meinung das ein Plugin generell Services starten/stoppen können sollte.
Da es unter umständen ja sein kann das ich unterschiedliche Services habe.
Beispiel:
LMS und dazu mein eigner Service der etwas steuert. So könnte man jeden einzeln steuern und nicht nur den eigenen.
Ich kann das Skript natürlich wieder so bauen das ich den LMS über meinen Service steure, aber das wird wieder viel zu aufwendig.

Wenn man wirklich sicher sein will...
Müssen die Plugin-Daemons vom Loxberry generiert werden, den sobald ich ein File selber schreibe und es nur aus der ZIP kopiert wird kann es korrumpiert werden.
Ich denke das schwierige wird bei solchen Dingen das du ja Abwärtskompatibel sein solltest.

Aber das ist es wie immer... Sicherheit oder Komfort

Dann warte ich mal ab und freu mich wenn es einfacher wird

[Christian Fenzl]

Noch was zur Ergänzung:

Womit ich mich in der letzten Woche beschäftigt habe ( unser Prof.Mobilux hat es schon mitbekommen bei den Issues und Commits), ist das Abstrahieren von allem, was ein Plugin so machen soll/muss/will, weg aus dem Plugin und hinein ins LB-System. Nur so lässt sich noch eine gewisse Sicherheit wahren, wenn auch über's CGI Systemeinstellungen gemacht werden können sollen.

Voraussetzungen dafür werden sein,

• dass die Abstrahierungsfunktionen in einer Systemkomponente vorhanden sind. Gerade habe ich die PHP-Variante von Perl LoxBerry::System (fast) fertig.
• dass die Plugins dann diese Abstrahierungsfunktionen nutzen, sonst bekommen sie keine Rechte.

In Bezug auf die Daemons/Services (aber auch allgemein) heißt das:

• Es muss ein genau definiertes Set an Funktionen geben, die das Plugin aufrufen kann.
• Im Modul wird dann eine Wrapper-Funktion (z.B. ein Script) aufgerufen, das im Basissystem in den sudoers enthalten ist, also mit root-Rechten läuft und die Änderungen durchführt.

Und das zu programmieren ist einigermaßen aufwändig, und es wird auch das "Eigene Images erstellen" wesentlich verkomplizieren.

Es ist die Frage, ob das dafür steht, oder man das mal einfacher implementiert.

Es wird jedenfalls in die Richtung gehen, dass man in einem Plugin viel mehr über bereitgestellte Modulfunktionen arbeiten muss, als selbst im System zu "operieren". Das wird auch die Update-Fähigkeit von LB verbessern. Das Multilanguage-Template-System wird in LB0.3 eingeführt, und das zentrale Logging. Services - schauma mal.

hismastersvoice Contribute? :-)

[Christian Fenzl]

LB0.3/0.4 soll soweit es geht, Plugin-kompatibel mit 0.23er-Plugins sein. Michael sagte aber, mit LB0.5 könnte es da einen Schnitt geben, wo Plugins gewisse Funktionen nutzen müssen. Aber mal sehen, wie sich das entwickelt.

[hismastersvoice]

Contribute...
Ja, nur wann

Ich habe die 1.0 des MS4L noch bei weitem nicht so weit wie ich will...
dort muss ich gegen meine Absicht noch einen zwischen Update 0.5 bringen

...Es stehen noch ein paar andere Plugin-Aufgaben an die ich aufgrund der einfacheren Doku bauen will...
...und nebenbei muss ich durch eine Firmenübernahme in den USA dort den Verkauf aufbauen und unterstützen...
...ach ja eine Frau habe ich ja auch noch

Zurück zum Thema:
Muss dazu sagen das Sicherheit zwar für mich ein Thema ist, aber wir sollten das nicht so hoch ansetzten das keiner mehr ein Plugin schreiben will wenn es zu kompliziert ist.
Es sollte die Möglichkeit bestehen "einfach" ein Plug-In zu erstellen. Wenn ich immer auf Beschränkungen treffen beim Proggen verliert man schnell die Lust.

Ich bin schon mal froh zu lesen das in Zukunft PHP nativ geht, ich muss gestehen das ich Perl nicht mag und es deswegen auch nicht anfangen wollte.
Aber es klappt ja inzwischen ganz gut.

LB0.3/0.4 soll soweit es geht, Plugin-kompatibel mit 0.23er-Plugins sein. Michael sagte aber, mit LB0.5 könnte es da einen Schnitt geben, wo Plugins gewisse Funktionen nutzen müssen. Aber mal sehen, wie sich das entwickelt.

Das wäre meiner Meinung nach ein Katastrophe.
Würde bedeuten das die Entwickler von Plugins zwei Version pflegen müssen, das ist irgendwann nicht mehr zu Händeln.
Aber warten wir es ab.

[Christian Fenzl]

Es soll dann eher so sein, dass sie es nutzen *wollen*. Da wollen wir hin :-)

[Prof.Mobilux]

Über die Sicherheit haben wir ja schon viel diskutiert. Ich hatte damals (und im aktuellen Loxberry ist es auch noch so) z. B. sudo deaktiviert. Das hat aber nur dazu geführt, dass alle ihre Dinge, die sie unbedingt als root machen müssen, ins Init-Skript gepackt haben. Und damit muss fast jedes Plugin den Loxberry nach der Installation neu booten - wie bei Win98... Und ein Sicherheitsgewinn ist es auch nicht. Im Plugin-Initskript kann ich als böser Bube auch ein "rm -rf /" ausführen.

Fakt ist: ich muss dem Plugin vertrauen, welches ich installiere. Ich möchte das auch nicht zu sehr einschränken, das würde nur viele Plugins verhindern. Bei mir z. B. das Homematic-Plugin, wo vermutlich sogar irgendwelche Kerneklmodule nachinstalliert werden müssen und die cmdline.txt abgeändert werden muss.

Im Moment tendiere ich daher zu dem Konzept, welches ich hier im 2. Post schon mal beschrieben hatte: https://github.com/mschlenstedt/Loxberry/issues/188

Mit dem Konzept hat man recht viele Freiheiten als Pluginentwickler und gleichzeitig ist der LoxBerry ziemlich sicher, so dass ich selbst mit ausgespähtem Webpasswort nicht auf das System komme. Die einzige Lücke, die offen wäre: Wenn ich das Webpasswort ausgespäht habe, könnte ich ein bösartiges Plugin installieren was z. B. den ssh-Zugang freischaltet. Dagegen könnte ich mir vorstellen, dass ein Plugin nur installiert werden kann, wenn der Zugriff auf den LoxBerry aus dem eigenen Subnetz kommt. Das ist natürlich auch umgehbar, aber ich denke, dass die Hürden dann hoch genug sind.

[orli]

Die einzige Lücke, die offen wäre: Wenn ich das Webpasswort ausgespäht habe, könnte ich ein bösartiges Plugin installieren was z. B. den ssh-Zugang freischaltet. Dagegen könnte ich mir vorstellen, dass ein Plugin nur installiert werden kann, wenn der Zugriff auf den LoxBerry aus dem eigenen Subnetz kommt. Das ist natürlich auch umgehbar, aber ich denke, dass die Hürden dann hoch genug sind.

Hm, damit sperrst du User wie mich, die Clients und Server per VLAN getrennt haben aber direkt aus, zumindest wenn ich dich richtig verstehe und du das so umsetzten willst, das der Clientzugriff per Browser nur aus dem Subnetz des Loxberries kommen darf.

[tholle]

Waere es eine Idee, Plugins in Sandboxes oder virtual Spaces laufen zu lassen? Damit sind diese ausreichend geschuetzt gegenueber des Hostsystems und man muss sich nur um die Verwaltung der Sandboxes als solches kuemmern. Quasi eine sichere Schnittstelle zwischen Plugins und Hostsystem.
z.B. chroot-jail, oder Aehnlichem.

In den Sandboxes koennen die Plugins dann ja tun und lassen was sie wollen.

Gruss,
tholle

[Christian Fenzl]

Mit cheroot-jail wird’s nicht gehen, dafür machen die Plugins zu viel Mögliches und Unmögliches.

Dem Plugin selbst könnte man ohne weiteres alle Rechte einräumen.

Die Gefahr besteht im Großen und Ganzen im Apache, wo man als Plugin unter reduzierten Rechten dem Benutzer die Möglichkeit gibt, Dinge einzustellen, die eigentlich nur Root dürfte.

Die „Kunst“ ist es jetzt, im Plugin beim Setup die Rechte im System so zu modifizieren, dass der eingeschränkte Apache genau die Sachen als Root darf, die das Plugin braucht, aber nicht zu viel. Und da kommen die ganzen Stolpersteine.

Hauptrisiko für einen Angriff ist aber der Apache bzw. das loxberry-Passwort.

[Christian Fenzl]

Prof.Mobilux Könnte man das Root-Passwort nicht sicher (komplex) lassen, und für die Plugin-Installation im UI das Root-PW abfragen? Nicht um die Installation selbst privilegiert auszuführen, sondern nur, um überhaupt den Installationsdialog zu sperren.