FHEM Security

[viegener]

Huch das wird ja immer schneller. Danke für die Anmerkungen.

Version oben (http://forum.fhem.de/index.php/topic,46181.msg380737.html#msg380737) angepasst bei xmllist / jsonlist (war inkonsistent korrekt --> weil nur lesend auf Expert level bei beiden) ausserdem habe ich PERL hinzugefügt und einen Fehler bei setdefaultattr beseitigt

- @justme1968: Ich habe den Gast definiert, weil man vielleicht einem Benutzer ohne Anmeldung auch Rechte einräumen will, das muss dann aber explizit geschehen und Gast wäre der user level bevor jemand angemeldet ist (Die Idee habe ich von anderen Systemen geklaut). Hintergrund es sollte eine explizite Entscheidung sein, wenn ich in einem grundsätzlich über Anmeldung geschützten System auch Dinge sehen kann ohne eine Anmeldung durchzuführen.

- @loredo: Das mit msg war natürlich kein Seitenhieb   Zum HIntergrund, das Problem, das auch bei trigger auftritt, hier geht es nicht um ein Modulspezifisches Recht für msg oder trigger Befehle sondern eigentlich um die Berechtigungen die hinter der einzelnen Definition liegen. Sozusagen ein Meta-Meta-Level... 

- @boris: Ja das mit der zweiten Dimension ist was ich mit der Modul Specific-Spalte einbeziehen will. Wobei es eigentlich mind. 3 Varianten gibt:
Rolle x Device x Befehl (notwendig z.B. für trigger) und in manchen Fällen auch Rolle x Modul x Befehl (z.B. für define) zusätzlich zu Rolle x Befehl

- @herrmannj: Das mit dem attrib verstehe ich nicht (attr ist enthalten) oder steh ich gerade auf der Leitung

Ist es Konsens, dass innerhalb des Ablaufs (auch eines DOIF oder eines AT) die Berechtigungen nicht mehr geprüft werden?
Vorteil: Performance (wg. weniger Prüfungen) und geringerer Aufwand für Realisierung
Nachteil: Risiko (durch ein komisches notify kann man ein Scheunentor öffnen) und Komplexität (Ich muss nicht nur die Devices absichern sondern auch alle Skripte)

Trotz der Nachteile stimme ich dafür.

[Loredo]

- @loredo: Das mit msg war natürlich kein Seitenhieb   Zum HIntergrund, das Problem, das auch bei trigger auftritt, hier geht es nicht um ein Modulspezifisches Recht für msg oder trigger Befehle sondern eigentlich um die Berechtigungen die hinter der einzelnen Definition liegen. Sozusagen ein Meta-Meta-Level... 

Hab ich schon verstanden 
Ich sehe nur immer wieder, dass es hier noch einiger Erklärung bedarf und das liegt an mir (bzw. an meiner bisher fehlenden ausführlichen Dokumentation nebst Wiki-Beitrag).
Hoffe ich konnte erklären, weshalb msg eigentlich kein Spezialfall ist, sondern einfach nur einem Admin/God (bzw. FHEM internen Funktionen und Modulen wie DOIF etc.) vorbehalten sein muss. Für den trigger-Befehl denke ich, dass man dies auch nur als Op oder für Automationen braucht und ein User das nicht ausführt. Für einen Spezialfall brauchts dann halt immer ein Dummy und ein dazugehöriges Notify, um einem User etwas zu erlauben. Das finde ich konsistent.

- @justme1968: Ich habe den Gast definiert, weil man vielleicht einem Benutzer ohne Anmeldung auch Rechte einräumen will, das muss dann aber explizit geschehen und Gast wäre der user level bevor jemand angemeldet ist (Die Idee habe ich von anderen Systemen geklaut). Hintergrund es sollte eine explizite Entscheidung sein, wenn ich in einem grundsätzlich über Anmeldung geschützten System auch Dinge sehen kann ohne eine Anmeldung durchzuführen.

Ja, temporäre Gäste müssen einiges auch ohne Anmeldung steuern können (siehe zB Modul GUEST).

Ist es Konsens, dass innerhalb des Ablaufs (auch eines DOIF oder eines AT) die Berechtigungen nicht mehr geprüft werden?
Vorteil: Performance (wg. weniger Prüfungen) und geringerer Aufwand für Realisierung
Nachteil: Risiko (durch ein komisches notify kann man ein Scheunentor öffnen) und Komplexität (Ich muss nicht nur die Devices absichern sondern auch alle Skripte)

Ja, so stelle ich mir das vor. Innerhalb von FHEM intern braucht es keine Einschränkungen. Die Modulautoren bleiben ohnehin auch weiterhin durch die geteilten Namespaces in der Verantwortung. Sandboxing etc. würde IMHO wirklich ein FHEM2 verlangen, was Rudi ja schon als eher unrealistisch benannt hat.

[justme1968]

die prüfung der rechte für den inhalt eines notify at oder ähnlichem braucht man erst wenn ein user mit eingeschränkten rechten ein solches auch anlegen oder modifizieren darf. also erst mal später .

und dann würde ich es auf modify beschränken und dort nur fhem kommandos erlauben die man dann anhand der user rechte beim modify prüfen kann.

die alternative die jetzt schon geht ist der admin legt notify oder at an und holt die paramtere aus einem dummy den der user setzen darf. natürlich nach prüfung des inhalts. das reicht um z.b. weck zeiten einzustellen.

[Martin Fischer]

Eine moderne REST API mit entsprechenden AuthTokens etc. für die Anbindung anderer GUIs wäre sicherlich wünschenswert. Auch wäre ein Ersatz für BasicAuth durch session basierte User Authentifizierungsmethoden wünschenswert. Man kann derzeit nicht nachvollziehen wer wann was im System eingestellt oder geschaltet hat. Solch eine Audit Trail Funktion fehlt mir da auch, optimalerweise revisionssicher.

Ja, FHEM ist offen, kann man alles selbst reinhacken. Der Punkt ist aber die Architektur sollte bereits darauf ausgelegt sein, von Grund auf. Dafür bedarf es aber auch eines grundsätzlichen Bekenntnis zur Sicherheit seitens der Core Entwickler. Solch umfangreiche Patches Dritter würden ohnehin (verständlicherweise) niemals übernommen werden.

FHEM mag gewachsen sein über die Jahrzehnte. Eine FHEM2 Basisarchitektur, die alte Zöpfe radikal abschneidet und dem 21. Jahrhundert angemessen ist, wäre ein toller Schritt. Allein zu dieser Erkenntnis (ohne die Diskussion "wer macht das", "viel Arbeit", etc.) reicht es wohl leider nicht. Kann ich auch verstehen, für sowas gewinnt man keinen Blumentopf, weil augenscheinlich "geht doch alles". Die Möglichkeiten bei der Automation mit FHEM sind grandios, aber als Architekt habe ich mich mit FHEM nur "arrangiert".

Alsoooo... bin ja nun auch schon seit 'zig Jahren dabei, wenn auch in den letzten zwei Jahren nicht mehr so aktiv am programmieren...

Aber ich gebe Dir, Loredo, vollkommen recht. So sehr ich auch hinter FHEM stehe, kann ich Deine Anmerkungen sehr gut nachvollziehen. In FHEM bestehende Konzepte zu ändern ist sehr, sehr müssig; manchmal auch nicht gewollt.

2008 fing ich an eine neue Oberfläche für FHEM, myHCE, zu entwickeln. Irgendwann habe ich es sein lassen, da die Gemeinschaft der Entwickler einfach nicht dazu zu bewegen war Standards einzuführen. Das Problem zieht sich bis heute durch; ich sage nur als Beispiel: "unterschiedliche Bezeichnungen in Readings für die gleichen darzustellenden Einheiten". Es wurde immer wieder ein Versuch unternommen, so richtig umgesetzt wurde es nie. Würden wir für FHEM eine entsprechende API (so wie es Gang und Gebe ist), entwickeln, dann bin ich mir sicher, dass das für FHEM (und deren Vielfalt) eine Bereicherung wäre.

Auch vertrete ich die Meinung: FHEM sollte nicht nur für Experten sein. Seit jeher predige ich, das "Lieschen Müller" ebenfalls FHEM bedienen (und auch einfache Aufgaben erstellen) können sollte. Viele reden / schreiben hier immer von dem WAF; letztlich muss man aber alles selber machen, damit der WAF überhaupt erreicht wird. Warum läßt man Frau nicht mittels einfacher Assistenten selber machen? Und wenn wir schon dabei sind auch gleich ein entsprechendes Berechtigungskonzept erstellen.

Aber auch solch Themen wie "Update- und Anpassungshinweise" möchte ich nicht im Forum nachlesen müssen. Hier fehlt auch ein entsprechendes Servicekonzept. Und ja, wie haben hier OSS vorliegen, aber das eine schließt das andere nicht aus.

Für mich zeigt die Erfahrung der letzten Jahre:
FHEM wächst und wächst aber "verwächst" dabei immer mehr. Alle Versuche Standars einzuführen sind nicht oder nur bedingt umgesetzt. Warum nicht wirklich einfach den Mut zu FHEM2 haben und von vorn herein eine moderne Architektur inkl. Standardisierung, Berechtigungskonzepte, Sicherheit, u.v.m. entwickeln. Nach und nach die einzelnen Module nachziehen und gut ist.

my 2 cents...

[micomat]

Full ack, Martin

[justme1968]

vermutlich ist es auch sinnvoll use cases zu sammeln. damit kann man die end anwender sicht besser abdecken als mit der reinen zuordnung von kommandos zu usern oder gruppen.

einer an dem ich gerade arbeite wäre: mehrere tablets als info und bedien pannel verteilt in den zimmern. manche zeigen das gleiche an manche etwas anderes, auch die tablets die die gleiche ansicht zeigen haben nicht die gleichen rechte. mache devices lassen sich nur ansehen, andere auch schalten. manche sind nicht zu sehen. auch nicht über umwegen. es ist möglich sich im aktuellen frontend über zusätzliches login/pin eingabe oder ähnliches temporär zusätzliche rechte zu verschaffen. z.b. um eine alarmanlage unscharf zu schalten oder um mal etwas zu konfigurieren ohne den laptop auf zu machen. die tablets sind auf eine bestimmte (httpserv,ftui) url fest konfiguriert und es ist deshalb nicht möglich auf ein anderes frontend zu wechseln. die temporäre autorisierung muss also an der gleichen instanz erfolgen können.

[viegener]

Ich habe heute morgen nochmal ein wenig über ein mögliches Design nachgedacht, dabei habe ich versucht Berechtigungsgruppen zu definieren, damit die Administration nicht allzu grossen Aufwand erzeugt und auch die Überprüfung.
Es geht dabei darum nicht zu fein zu definieren und auch sinnlose Möglichkeiten auszuschliessen:
Beispiel: Wenn das Recht auf Modulebene existiert devices anzulegen, dann sollte man alle Rechte auf devices für das Modul haben um Attribute etc setzen zu können.

Es gibt systemweite Kommandos, Modulspezifische Kommandorechte und Devicespezifische Rechte
(Einzelne Module können dann noch weiter unterscheiden)

Code Auswählen Erweitern


Es ergeben sich erstmal folgende Standardrechte

  admincommands (schliesst alle Rechte unten ein !)
    enthält: apptime, CULflash, configdb, reload, restore, update, usb
   
  operatorcommands (schliesst alle Rechte unten ein !)
    enthält: backup, cancel, cmdalias, fheminfo, include, notice, quit, rereadcfg
              setdefaultattr, shutdown, version, PERL

  modulcommands - Modul spezifische Rechted (enthält für alle devices des Moduls auch alle set- und getcommands)
    enthält: copy, define, defmod, delete, modify, rename

  setcommands - spezifiziert durch eine Kombination aus devspec und optionalem parameterspec
    enthält: attr, deleteattr, deletereading, set, setreading, setstate

  getcommands - spezifiziert durch eine Kombination aus devspec und optionalem parameterspec
    enthält: displayattr, get, getstate
   
  readcommands
    enthält: displayattr, inform, JsonList, JsonList2, list, save, sleep, xmllist


[viegener]

Ich habe die voreschlagenen Standarberechtigungen nochmals etwas übersichtlicher formuliert, siehe oben.

Ausserdem habe ich mal erste Gedanken über das API des Auth-Moduls gemacht, basierend auf den Überlegungen von Boris:

Code Auswählen Erweitern


defineRight( $modulename, $right )
  Definiert eine modulspezifische Berechtigung

assignRight( $role, $namespec, $right, $parameterspec )
  Weist eine Berechtigung einer Rolle zu
    $namespec ist eine devspec (kann auch ein modulname sein) -> Gibt das Probleme weil Modulnamen auch Devicenamen sein können?
    $right ist ein einzelnes Recht
    $parameterspec ist ein regexp oder "" oder undef
   
    Problem: Die Auswertung ob ein Recht existiert kann relativ aufwändig (sprich teuer werden), da u.U. viele devspecs ausgewertet werden müssen

getRights( $role )
setRights( $role, @rights )
  @rights ist ein Array von einzelnen right definitions (tripeln)
  Jedes triple besteht aus $namespec, $right, $parameterspec wie oben
  $role wird implizit angelegt wenn nicht vorhanden
   

setRoles( $role, @roles )
  @roles ist ein Array von Rollennamen, die in $role eingeschlossen sein sollen
  $role wird implizit angelegt wenn nicht vorhanden

setUser( $user, $auth, $role )
  Definiere einen Benutzer mit $auth (Psswort ?) und $role as Rolle

hasUserRight( $name, $right, $parameter )
  $name ist device name or module name
  $right ist entweder eines der vordefinierten oder eine Modulspezifische Berechtigung:
    admincommands
    operatorcommands
    modulcommands on the module belonging to $name
    setcommands on the device $name
    getcommands on the device $name
    readcommands
   
    Jedes höhere Recht schliesst die entsprechenden Rechte darunter mit ein (bei modulcommands nur für die devices in dem modul)

   
  $parameter ist
      z.B. bei Attributen der Name des Attributes
      analog für Readings / set
     
  liefert 1 für ok


Das Konzept der PermissionFn passt natürlich auch, allerdings macht es Sinn, dass diese von fhem.pl aufgerufen wird, oder?

[Amenophis86]

Ich möchte auch mal meinen Senf dazu geben.

Ich habe leider sehr wenig Ahnung von diesen Sachen und musste jeden zweiten Fachausdruck nachlesen. Gerade deswegen wäre ich froh, wenn Leuten, wie mir, eine Hilfe an die Hand gegeben wird. Ich habe in vielen Sachen nur Grundkenntnisse und suche mir den Rest dazu aus dem Wiki etc zusammen. Allerdings wurden wieder hier zB auch viele Sachen genannt, die mir noch gar nicht bekannt waren.

Zu manchen Themen, wozu ich etwas sagen kann, möchte ich folgendes anmerken:
- Anleitung zur Sicherheit finde ich sehr gut. Gerade für neue Leute oder Leute wie mich, die was machen wollen, aber die Möglichkeiten nicht kennen, eine sehr gute Idee.

- User Einstellungen finde ich auch sehr gut. Besonders, weil ich glaube, dass dies beim WAF helfen kann. Ich habe zwar einfach eine zweite Webinstanz gemacht, wo wenig erlaubt ist, aber denke, die oben genannte Sache wäre besser.

- Besonders gut finde ich die Idee, dass Leute sich bei der Installation (oder auch später) durch eine Anleitung/Menü klicken kann und durch gewisse Einstellung geleitet werde mit Erklärung. Gerade für neue Leute sollte dies sehr gut sein. Wie lange hat es zB gebraucht, bis ich durch Zufall auf allowedCommands gekommen bin?

Daher finde ich den Thread hier sehr gut und bin gespannt, wie es weiter geht. Prinzipiell denke ich aber auch, dass in erster Linie das System eine gewisse Sicherheit vorgeben sollte, welche aber abgeschaltet werden kann und es nicht "nur" einen Hinweis bei der Anmeldung geben sollte. Gerade im Hinblick darauf, dass FHEM ja Leute erreichen möchte, die weniger Ahnung von Programmieren haben und "nur" ein System suchen. Gerade durch zB DOIF ergeben sich für "unwissende" einfach Möglichkeiten und ist extrem Userfreundlicher geworden. Daher finde ich auch den Vorschlag, dass ein BasicAuth bei der Installation gesetzt oder nachgefragt wird, sehr gut.

Soviel von meiner Seite zu dem Thema, bzw wozu ich etwas sagen kann.

[dero]

Ich habe nginx rumgewickelt.

[Werner Schäffer]

Ich habe nginx rumgewickelt.

Na das ist mal eine Antwort in meinem Sinne. Auch Rudolf hat mal in diesem Thread sehr schön gesagt: "ich sichere lieber die Haustüre pedantisch als jedes Zimmer extra" (oder so ähnlich).

Warum sollte man das Rad also neu erfinden und Sicherheitsfeatures in fhem einbauen wenn man das duch Firewalls, Webserver und Proxys, die durch das tägliche Dauerfeuer von Attacken bereits gestählt sind, viel besser erreicht?

Bei mir sieht das so aus:
- in meinem Hausnetz einschließlich WLAN ist fhem ohne Passwort und unverschlüsselt erreichbar (telnet nur auf localhost)
- Zugriffe von außerhalb werden von der Fritzbox gefiltert und von einem nginx TSL verschlüsselt und durch einen Key geschützt.

Sollte irgendwo ein AKW mit Fhem gesteuert werden, bin ich bereit meine Meinung zu revidieren, aber mein Gott wir sind ein Haufen Verrückter die mit Fhem mit viel Spass Rolläden, Heizkörper und Teichpumpen steuern. Die Markise habe ich vergessen.

In diesem Sinne