sudo Standardverhalten wiederherstellen

[christianTF]

Da die meisten Anleitungen für den Pi im Internet mit sudo arbeiten, sollte das sudo-Standardverhalten von Raspbian wiederhergestellt werden.
Die LoxBerry-spezifischen Erweiterungen braucht man, aber nicht LoxBerry-spezifische Einschränkungen.

[mschlenstedt]

Ich hatte das mal drin, weil ich im Hinterkopf hatte, dass der LoxBerry auch mal von extern erreichbar sein könnte (z. B. als VPN-Server). Da wollte ich ein sauberes Sicherheitskonzept. Außerdem war der Grundgedanke, das niemand außerhalb von Plugins am LoxBerry "herumfummelt" :-)

Aber generell sollten wir die Beschränkungen wieder aufheben. Viele scheinen doch auch eigene Dinge auf dem LoxBerry installieren zu wollen.

Ich schlage folgendes vor:

1. Nach der Erstinstallation wird der SSH-Zugang nur noch per Key/Zertifikat erlaubt. Damit wäre es selbst mit Ausspähen des LoxBerry-Passworts über HTTP nicht mehr möglich auf das System zu kommen. Wir packen eine eigene Anleitung für Putty, Linux-SSH und WinSCP dazu ins Wiki.

2. Das Root-Passwort ist gleich dem LoxBerry-Passwort. (siehe auch unter 4.)

3. Das Samba-Share wird ReadOnly und nur für bestimmte Ordner schreibbar (z. B. nur für .../plugins/data). Damit könnte ich auch per Samba und nachdem ich das Passwort per HTTP ausgespäht habe keine eigenen (kompromittierten) Skripte auf den LoxBerry bringen.

4. Sudo wird wieder freigegeben. Damit wäre der LoxBerry-User quasi gleich root. Daher auch die zusätzliche Absicherung des SSH-Logins über Zertifikate.

5. Die Plugin-Installation läuft komplett mit Root-Rechten - und zwar ohne zusätzliche Abfrage irgendeines Passworts. Damit gäbe es eine potentielle Lücke über "bösartige" Plugins, die ist aber heute über das Daemon-Skript auch schon da. Und man braucht diese Verrenkungen über das Daemon-Skript nicht mehr zu machen.

Meinungen?

[Woersty]

👍

[andweber]

zwei Anmerkungen dazu:

1. Wenn ich Http-Zugang habe, habe ich auch Zugang zum System, da ich Pluginarchive installieren kann und ich mir in dem Installskript auch den SSH-Zugang wieder freigegeben kann. Erfolgt die Plugininstallation mit root-Rechten vereinfacht dies das sogar erheblich.
   Der Daemonskriptweg erzwingt derzeit einen Neustart - also Zeit oder physischen Zugriff auf die Stromversorgung.
2. ich halte die Trennung von HTTP Passwort und Root-Zugang für einen sinnvollen Schutzmechanismus. Das Http-Kennwort ist tendenziell weit gestreut, bzw. aus bequemlichkeit bewußt einfach gehalten. Selbst mit einem SSH-Zugang oder einem anderen Exploit führe ich Code "nur" als lokaler user aus.

ganz neben bei: die lokale Installation zwingt derzeit Plugin lokal zu schreiben und ermöglicht damit eine Trennung bzw. einen gleichen Versionsstand des Basissystems. Erfolgt die Plugin-Installation mit root-Rechten, besitzt jedes Plugin sehr große Freiheiten und die Gefahr von Inkompatibilitäten zwischen den Plugin steigt.

[mschlenstedt]

sudo Standardverhalten habe ich im Image für 0.3.0 wieder hergestellt (loxberry ist jetzt in der Gruppe "sudo"). DDer Rest (siehe oben) ist noch offen.

[christianTF]

Zu 3.
Den Samba-Share möchte ich keinesfalls Read-Only haben.
Das verkompliziert das Entwickeln, Testen und Troubleshooten mit Anwendern.

lg, Christian

[christianTF]

Meinung:

1. Nach der Erstinstallation wird der SSH-Zugang nur noch per Key/Zertifikat erlaubt.

Möglich, ich finde es aber zu kompliziert.

2. Das Root-Passwort ist gleich dem LoxBerry-Passwort. (siehe auch unter 4.)

Finde ich NICHT gut - der Root sollte mit einem generierten PW bleiben. Wem das nicht gefällt, kann das root-PW leicht ändern.

3. Das Samba-Share wird ReadOnly und nur für bestimmte Ordner schreibbar

Finde ich NICHT gut - wie schon gesagt ist das auch für die Fehleranalyse praktisch.

4. Sudo wird wieder freigegeben. Damit wäre der LoxBerry-User quasi gleich root. Daher auch die zusätzliche Absicherung des SSH-Logins über Zertifikate.

Eh schon umgesetzt, und gut, um selbst was installieren zu können.

5. Die Plugin-Installation läuft komplett mit Root-Rechten - und zwar ohne zusätzliche Abfrage irgendeines Passworts.

Das wiederum finde ich NICHT gut. Die Plugin-Installation kann als root laufen, aber jede Plugin-Installation soll das root-Passwort abfragen. Das ist über Port 80 die einzig (bekannte) Sicherheitslücke, dass der loxberry-User sich übers Web seinen root-Zugang per Plugin installieren kann. Die Abfrage dort schließt aus, dass das jemand anderer als der LB-Betreiber macht.

[mschlenstedt]

HIer mal meine "Hintergedanken" zu dem Vorschlag:

1. SSH-Zugang
   Wenn sudo für den loxberry-Nutzer freigegeben wird und jemand späht das (unverschlüsselte) loxberry-Passwort aus dem Webif aus, hat er damit quasi root-Rechte auf dem System, da er sich mit dem loxberry-Passwort per SSH einoggen kann und mit sudo zu root wird. Absicherung würde meiner Meinung nach nur funktionieren, wenn ich mit dem Webif-Passwort nicht per SSH auf den LoxBerry komme.

2. Root-Passwort
   Wenn wir sudo für den loxberry-Benutzer freigeben, dann hat das generische Root-Passwort keinerlei Vorteile mehr. Mit "sudo passwd" kann ich es sowieso neu setzen, sobald ich als loxberry auf dem System bin.

3. Samba-Share
   Ich kann per Samba-Share ohne Probleme Skripte auf dem LoxBerry austauschen. Z. B. ganze Config-Dateien im System einfach austauschen, da ich per Skript auch zu root werden kann (über sudo). Ich könnte z. B. ~/sbin/loxberryinit.sh austauschen und mir so SSH wieder freischalten, dass Root-Passwort setzen etc. pp. Ich halte das für SEHR riskant.

4. Plugin-Installation vs. Root
   Einverstanden, aber eher als "Installationspasswort".

[christianTF]

Du kennst dich bei Linux-Sicherheit besser aus als ich.
Also mach alles dicht wie geplant.

Im Developertools-Plugin kann ich dann immer noch Sachen hineinnehmen, die für Entwicklungs-LBs praktisch sind, und damit ist das Produktivsystem sicher, und jeder, der das Entwickler-Plugin installiert, macht alles auf eigenes Risiko.

[mschlenstedt]

Je länger ich darüber nachdenke und je mehr ich mich damit beschäftige, komme ich immer mehr zu dem Schluss, dass das Standard-sudo-Verhalten wieder herzustellen eine GANZ schlechte Idee ist...

Der Unterschied zwischen LoxBerry und einem "normalen" Rasbian ist, dass auf einem Rasbian der Webserver als User "www-data" läuft. Auf dem LoxBerry läuft er aber als User "loxberry". Mit sudo hat er damit quasi root-Rechte - als Webserver! Ich halte das für eine sehr, sehr schlechte Idee.

Es stimmt schon: Alle Standardanleitungen für den Raspi verwenden sudo. Aber: so what? Der LoxBerry ist gemacht, um die Kommandozeile unnötig zu machen. Und wer auf seinem System "herumfummeln" will und noch nicht einmal weiß was sudo ist und wie es benutzt wird - sorry, aber der sollte die Finger davon lassen.

Geht man den Weg, wie ihn @christianTF in einem anderen Thread beschrieben hat, über ein sudoers file, so hat man wenigstens die Hürde der Plugininstallation. Und man kann trotzdem Dinge über das Plugin als root ausführen.

[Woersty]

Ich finde auch so einige andere Dinge noch zu gefährlich. Ich selbst habe mir schon mein root PW über eine Plugin Installation zurückgesetzt - und das ging problemlos. Das müssen wir zwingend unterbinden. Zumal alles HTTP und Klartext ist.

[mschlenstedt]

Tja, wenn wir wollen, dass Plugins auch Dinge als root ausführen können sollen, wirst Du das glaube ich nicht verhindern können.

Aber für mich gilt: Das System muss möglichst sicher sein. Dem Plugin-Autor muss ich vertrauen. Ein "böses" Plugin kann mein System kompromittieren (schon heute über das Daemonscript, in Zukunft gleich während der Installation). Aber da ist immer noch die Hürde dazwischen, dass ich das Plugin installieren muss. Und da finde ich @christianTF Vorschlag nicht schlecht, die Installation über ein zusätzliches Passwort (nicht root!) abzusichern. Ist unbequem, aber bringt Sicherheit.

Eine andere Sache ist es, wenn das System prinzipiell (also ohne die Installationshürde) schon unsicher und offen ist. Da grummelts bei mir.

[christianTF]

Wenn nicht das root-PW, dann vielleicht sowas wie eine PIN.
Das Wort "PIN" ist dann klarer wie "Kennwort", dass eh alle durcheinander bringen.
Ich bin dabei - wir pfeifen auf "Standard", und wer mehr will, muss in die Shell und mit root installieren.

[mschlenstedt]

Irgendwie bin ich mit mir da noch nicht "im Reinen". Wir haben auch an anderer Stelle gravierende Lücken:

• crontab
• sudoers
• daemon

Alle 3 Dateien gehören dem user "loxberry". In allen 3 Dateien kann ich zur Laufzeit Dinge ergänzen und somit ganz einfach neue Befehle/Scripte (die der Pluginentwickler gar nicht implementiert hat) per Root ausführen. Sobald ich es schaffe als user loxberry auf das System zu kommen bin ich damit quasi wieder root.

Das gefällt mir alles nicht. Ich muss da noch ein bisschen drüber nachdenken... Ich sehe ein, dass Plugins auch einige Dinge als Root durchführen müssen, aber ich möchte das System nicht derart unsicher machen.

[mschlenstedt]

Vielleicht ist das ein Weg:

1. Wir sind uns einig, dass man dem Pluginentwickler vertrauen muss. Fertig - daran führt kein Weg vorbei.
2. Wir schützen die Installation von Plugins mit einer PIN
3. Die crontabs-Dateien gehören root und sind nur über ein Wrapper-Skript änderbar. Das setzt den ausführenden Nutzer im crontab immer fest auf "loxberry"
4. Es gibt das sudoers-File, aber es ist nach der Plugin-Installation nicht mehr änderbar
5. Samba wird readonly, aber es gibt ein writable share, sodass man trotzdem einfach Dateien auf den LoxBerry schieben kann.
6. SSH nur noch per Zertifikat, damit ich mit dem loxberry-Passwort erst einmal nichts anfangen kann.

[mschlenstedt]

Ach so, das gleiche wie mit dem sudoers auch mit dem Daemon-Skript: Läuft als root, ist aber nach der Installation vom user loxberry nicht mehr änderbar.

[christianTF]

Hört sich vernünftig an.

Kompatibilität:
Ich glaube nicht, dass derzeit in bestehenden Plugins irgendwer das Daemon-Script nachträglich ändert --> Sollte passen.
crontab ist sowieso neu --> passt.
Sudoers ist neu --> passt.
SSH Zertifikate --> Routine zum Erstellen muss wahrscheinlich auch ins changehostname.sh

[mschlenstedt]

Ich baue das erstmal so in die Pluginschnittstelle ein. Um ssh kümmern wir uns später.

[mschlenstedt]

Ich habe da nochmal drüber nachgedacht: SSH und Zertifikate ist wirklich zu kompliziert, glaube ich.

Eine einigermaßen gleichwertige Sicherheit würde man bekommen, wenn man einfach das LoxBerry-Passwort für Terminal und Samba ungleich dem Webzugang macht.

Man könnte es z. B. einfach zusammensetzen aus Webpasswort+PIN. Wer will kann es dann ja auf der Console ändern.

[mschlenstedt]

Erledigt mit Pluginschnittstelle V2 und Image 0.3.2