FHEM Forum

Hi there!

Ich bin ein Frischling bzgl. FHEM und setze gerade ein System auf Raspi auf. Mir sind dabei einige Sachen aufgefallen, die aus Security-Sicht ziemlich übel sind und habe deshalb mal ein paar generelle Fragen:

1) Mein erster Eindruck ist, dass Security bei FHEM überhaupt keine Rolle spielt. Sachen wie Code Execution, Cross-Site Scripting und File Disclosure sind fast schon ein Feature und die Latte, um ein System mit FHEM zu übernehmen, liegt meiner Meinung nach richtig niedrig. Gibt es Bestrebungen da mal grundsätzlich was zu verbessern?
2) Meint ihr, den Usern ist bewusst, dass sie sich da eventuell ein riesen Loch in ihre Infrastruktur reißen, wenn sie nicht selbst Maßnahmen ergreifen, um die FHEM Instanz abzusichern/zu isolieren?
3) Wäre es vielleicht eine gute Idee, darauf ein bisschen expliziter hinzuweisen?

Gruß,

Flo

Ich tu mich schwer mit generischen Anschuldigungen, muss immer bis 10 zaehlen, und nicht unhoeflich zu werden. Koenntest du bitte konkret erklaeren, was nicht passt?

Hi!

Ich kann euch gerne ein paar PoCs liefern, aber nicht im public Forum. Soll ich dir das direkt schicken oder wie machen wir das?

Gruß,

Flo

Ein fhemweb / fhem telnet Zugang entspricht einem root Zugang. Also absichern (VPN/Passwort basic Auth).

Nur die Vektoren die dann noch bleiben sind relevant.

vg
joerg

Warum nicht oeffentlich?

Und bevor du loslegst, bitte sicherstellen, dass du die Attribute allowedCommands und CORS passend gesetzt hast.

Arbitrary File Disclosure:
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=/etc/passwd

Cross-Site Scripting:
/fhem/FileLog_logWrapper?dev=Logfile&type=<script>alert(1)</script>&file=/etc/passwd

Code Execution:
/fhem?cmd=%7Bsystem%28%22id+%3E+%2Ftmp%2Ffoo%22%29%7D

Ich bin von der default config ausgegangen. Auf den ersten Blick würde ich sagen, dass die zwei Einstellungen an der Problematik nix verändern würden. Hab ich aber nicht getestet.

Gruß,

Flo!

ZitatEin fhemweb / fhem telnet Zugang entspricht einem root Zugang.

ZitatArbitrary File Disclosure:

cat /etc/passwd funktioniert bei mir direkt über die cmd line, ganz ohne fhem :) Fehler im os ?

vg
joerg

/etc/passwd hat per default auf Unix 644 als Rechte, /etc/shadow 640. Eigentümer root:root.

Zitat von: herrmannj am 25 Dezember 2015, 17:05:07
Ein fhemweb / fhem telnet Zugang entspricht einem root Zugang. Also absichern (VPN/Passwort basic Auth).

Aber warum? Also mein FHEM läuft nicht mit root-Rechten.

Ich versuche es gleichzeitig nochmal so: wenn Du Zugang zur fhemweb / fhem telnet hast dann kannst Du das System konfigurieren inklusive jedem Blödsinn der dazugehört.

Wenn Dein fhem unter root läuft hast Du root Zugang. Den ganzen Mummenschanz oben benötogst Du nicht denn Du kannst direkt in die Kommandozeile Systembefehle eingeben und im Kontext des users ausführen unter dem fhem läuft.

Wenn Du etc/passwd sehen möchtest darfst Du das (!!!) ganz ohne Trick. Du darfst Systembefehle ausführen denn Du hast Zugang !

Das ist auch kein Hack. Ehrlich nicht. DU DARFST DAS !

vg
joerg

Zitat von: vbs am 25 Dezember 2015, 17:34:58
Aber warum? Also mein FHEM läuft nicht mit root-Rechten.

Ja. Schon klar. Meins auch nicht- wäre auch doof. Ich versuche das nur irgendwie klar zumachen das es eben kein Hack whatever ist.

Der Punkt den ich damit, zugegebenermaßen überspitzt, platziere: wenn ein nicht autorisierter user Zugang zu fhemweb oder telnet bekommt ist dort der Fehler.

Und andersherum, der user der Zugang bekommt weil er darf hat eben die Macht !
(und darf sich im Rahmen der user rechte bewegen)

vg
joerg

Kinners,

es geht doch nicht um die passwd sondern darum, dass man damit arbitrary Files lesen kann für die man Berechtigungen hat. Aber ok. Ist offensichtlich n Feature von FHEM.

Was sagt ihr denn zum Rest?

wenn du deinem FHEM nicht verbietest beliebigen perl oder shell code auszuführen ist es ein festure und kein bug tun zu können wozu die berechtigung hast. 

gruss
  andre

:)

Das ausführen von System Befehlen und perl code (im kontext des users fhem) ist dokumentiert! Ein ganz legales verhalten.
Mit einigen attributen kann man das etwas einschränken.

Trotzdem:

(Ich vertrete generell diesen Standpunkt:) wem Du keinen ssh Zugriff geben würdest dem darfst Du auch keinen fhemweb Zugriff geben. Für den Rest gelten und greifen alle üblichen Linux Absicherungsmaßnahmen wie user Rechte beschränken etc.

Fhem ist nun mal keine "webseite" zur Ansicht sondern ein System mit aktiven Komponenten.

Das ist gemacht damit man code eingibt der etwas bewirkt. Dazu hat der code natürlich Zugriff aufs filesystem (uva).

Was soll ein Auto welches nicht fährt ? Und wenn es fährt ist der Fahrer verantwortlich das er die Regeln beachtet und nicht in den Gegenverkehr fährt.

Beschränke (wie beim ssh auf jeden x-beliebigen Server) den Zugriff und sichere ihn ab! Welche "Risiken" bleiben dann - das ist die Frage die relevant ist.

vg
joerg

Hi!

Jetzt werden wir wieder konstruktiv. ;)

Zwei Punkte habe ich noch:

* Secure by Default ist ein erstrebenswerter Zustand, den ich mir für FHEM auch wünschen würde. BASIC auth würde ich mandatory machen. Interesant wäre auch ein hardening guide für FHEM, das macht es den Leuten vielleicht einfacher. Ich bin einfach der Meinung, dass aufgrund der hohen Angriffsfläche den Leuten klarer mit auf den Weg gegeben werden sollte, was das heisst. ;)

* Basic Auth und Kram ändert nix an dem (vermutlich eher den) XSS. Da solltet ihr meiner Meinung nach unbedingt nachziehen, denn das wird im Zweifelsfall mit der Code Exec echt hässlich.

Gruß,

Flo!

Zitat von: herrmannj am 25 Dezember 2015, 18:31:28
(Ich vertrete generell diesen Standpunkt:) wem Du keinen ssh Zugriff geben würdest dem darfst Du auch keinen fhemweb Zugriff geben. Für den Rest gelten und greifen alle üblichen Linux Absicherungsmaßnahmen wie user Rechte beschränken etc.

Ich sehe das ähnlich! Bei vielen von uns ist der FHEM-Benutzer in sudoers enthalten und damit fhemweb quasi root äquivalent.

Es ist für ein Bastelsystem (und das ist fhem wohl) ist es eine Frage ob der Grundsatz "secure by default" oder "Wissen was man tut" besser ist. Es ist sicher sinnvoll weiter abzusichern und konkrete Patches sind auch häufig willkommen, aber ich denke wir können nur sehr begrenzt für sichere Systeme sorgen, denn ich will nicht dass es Anwender gibt, die dann sagen: "Ich kann das System ja über Portforwarding im Internet verfügbar machen, FHEM ist ja sicher"

Zitat"Ich kann das System ja über Portforwarding im Internet verfügbar machen, FHEM ist ja sicher"

Davon gibt es halt schon n paar Dutzend.

Es war auch nur ein Hinweis meinerseits, gehen sie weiter, hier gibt es nichts zu sehen. ;)

Gruß,

Flo!

Zitat von: r0x0r am 25 Dezember 2015, 18:39:52
* Secure by Default ist ein erstrebenswerter Zustand, den ich mir für FHEM auch wünschen würde. BASIC auth würde ich mandatory machen. Interesant wäre auch ein hardening guide für FHEM, das macht es den Leuten vielleicht einfacher. Ich bin einfach der Meinung, dass aufgrund der hohen Angriffsfläche den Leuten klarer mit auf den Weg gegeben werden sollte, was das heisst. ;)

Security ist kein Selbstzweck, ein zentraler Punkt ist dabei immer wer der Angreifer ist, und was der potentielle Schaden ist. Das wird oft übersehen. Mein Fhem ist zB nicht von aussen zugreifbar, und wenn dann könnte man meinen Fernseher einschalten und bissl Licht und Jalousie bedienen...wer das schafft dem vergönne ich die Freude.
Die Idee mit dem hardening guide ist nicht verkehrt, schreib doch einen, sobald dein setup steht...hier darf jeder mitmachen!

Wg. basic auth: Wenn man FHEM installiert, und keine Passwoerter vergibt, dann wird das ueberall (telnet/FHEMWEB) bemaengelt. Wenn man das ignoriert, dann kann ich auch nicht mehr tun.

Was mAn bei einem "default" User z.Zt noch Probleme verursachen kann ist CSRF, weil csrfToken nicht per default aktiviert ist. Sorry, vorhin meinte ich csrfToken und nicht CORS.

Wenn irgendjemand meine FHEM Instanz kontrolliert, dann ist es mir egal, dass er /etc/passwd auslesen kann, mit FHEM kann man deutlich mehr Schaden ausrichten.

Zurueck zu deinem PoCs: wenn du mir zeigst, dass du auf meinem FHEM irgendetwas ausrichten kannst, dann werde ich alles unternehmen, um das zu verhindern. Es reicht mir auch eine theoretische Beschreibung des Vorgangs. Und nein, du kriegst mein FHEM Passwort nicht.

Zitat von: r0x0r am 25 Dezember 2015, 19:01:04
Davon gibt es halt schon n paar Dutzend.

Ja und das halte ich für ein Problem, das wir durch trügerische Sicherheit eher verschärfen. Wie gesagt konkrete Patches/Anmerkungen sind sicher hilfreich, denn auch in meinem Modul TelegramBot öffne ich einen Aussenzugang der leicht problematisch werden kann, wenn man nicht aufpasst und selbst dann sind an manchen Ecken nur Annahmen verfügbar (und ein Protection Profile für Common Criteria werde ich nicht anwenden)

Zitat von: r0x0r am 25 Dezember 2015, 19:01:04
Es war auch nur ein Hinweis meinerseits, gehen sie weiter, hier gibt es nichts zu sehen. ;)

Die Anmerkung verstehe ich nicht.

Zitat von: viegener am 25 Dezember 2015, 18:53:27
Ich sehe das ähnlich! Bei vielen von uns ist der FHEM-Benutzer in sudoers enthalten und damit fhemweb quasi root äquivalent.

Ehrliche Neugier: Wofür braucht ihr das?

Zitat von: vbs am 25 Dezember 2015, 20:53:43
Ehrliche Neugier: Wofür braucht ihr das?

Ich verwende das aus 2 Gründen:
- Ich arbeite per ssh auch häufig unter dem fhem-Benutzer, dann vermeide ich Rechteprobleme im fhem-Verzeichnis
- Manche Operationen (z.B. direkter GPIO-Zugriff) erfordert root-Rechte, also entweder ein setuid-Skript oder sudo

Hallo viegener,

ich arbeite an fhem grundsätzlich als User fhem. Dazu gehören alle Dateien in /opt/fhem diesem User. Wie funktioniert denn sonst bei Dir update?

Zugriffe auf Devices löse ich dadurch, dass der User in derselben Gruppe wie das Device ist und das Device z.B 660-Rechte hat (über udev-Regeln).

fhem ist bei mir nicht in sudoers.

Viele Grüße
Boris

Zitat von: Dr. Boris Neubert am 25 Dezember 2015, 22:18:45
ich arbeite an fhem grundsätzlich als User fhem. Dazu gehören alle Dateien in /opt/fhem diesem User. Wie funktioniert denn sonst bei Dir update?

Ja genau, das meinte ich mit der Vermeidung von Rechteproblemen und dem Arbeiten unter fhem. Ich arbeite als fhem und dann ist es halt relativ einfach "sudo service fhem ..." auszuführen wenn nötig. Man kann das auch als Bequemlichkeit auslegen  ;)

Ich denke, dass man sowohl das eine als auch das andere ohne root bewerkstelligen kann. Spätestens wenn FHEM potentiell als root läuft, dann bekomme ich auch langsam Angst. :)

Zitat von: vbs am 25 Dezember 2015, 23:17:21
Ich denke, dass man sowohl das eine als auch das andere ohne root bewerkstelligen kann. Spätestens wenn FHEM potentiell als root läuft, dann bekomme ich auch langsam Angst. :)

Das lässt sich sicher nicht verallgemeinern, aber aus meiner Sicht ist ein root Zugang auf meinem Homeautomation-System nicht wirklich kritisch.
Ich habe keine Potforwarding oder VPN-Lösung von aussen eingerichtet, mein WLAN ist abgesichert und aussen am Haus bringe ich keine Netzwerkstecker an. Meine Bewertung basiert darauf, dass ein unbefugter Zugang in mein Heim(-netz) vermutlich grössere Risiken als das Verwenden des root Zugangs auf meinem Raspberry hat.

Wie gesagt Fokus ist aus meiner Sicht die Absicherung des Netzes gegen Zugriff von aussen und nicht die Abschottung der Benutzer in meiner Familie-Heimnetz untereinander. Auf dem Raspberry liegen nur Daten die jeder Nutzer meines Heimnetzes auch sehen dürfte.

Moin,

sehr interessantes Thema hier ;-) Gibt ja wie man sieht verschiedene Meinungen, ist auch OK so. Ich kann nur Typen nicht leiden die WhatsApp etc. benutzen und Abends im Kreise der Familie schimpfen, dass die NSA uns belauscht, das ist schon etwas billig und grenzt an Dummheit. Für eins sollte man sich dann schon entscheiden und seine Kurs beibehalten.

Aber davon mal abgesehen, ich finde:

- Ein Hardening Guide wäre eine tolle Sache, und der würde vermutlich nicht zu knapp ausfallen wenn man alles bedenkt. Dazu ist er für Laien auch ein Anreiz mal über Sicherheit oder Neudeutsch Security nachzudenken, wenn auch nur kurz ;-) Andererseits, wer FHEM benutzt und nicht irgend ein System von der Stange sollte das vermutlich gar nicht brauchen, allerdings kommen doch Zweifel auf wenn ich einige Sachen hier lese.
- Security sollte IMMER vor Benutzerfreundlichkeit stehen, da hilft auch kein "Hinweis" das man ein Passwort vergeben sollte oder was auch immer.
- Wer FHEM in ein anderes Netzwerk Segment packt, sei es mit 802.1Q oder physikalisch wird wenig Nöte haben, natürlich auch getrennt vom Internet.
- Falls man von außen an sein System muss, kommt man um ein anständiges VPN mit IPSec nicht rum.
- Mit ESXi, also Virtualisierungen kann man auch einiges machen, für die die FHEM auf einem Server laufen haben wo noch etliche andere Dienste laufen (Webserver, Dateifreigaben etc.). Hier kommen aber dafür andere Probleme hinzu wie memory sharing etc. aber lassen wir mal die Kirche im Dorf ja.
- Paranoiden können auch gerne mal ein Nessus und Codenomicon Scan durchführen, aber die Ergebnisse hier natürlich nicht posten...
- Viele Sicherheitseinstellungen sind auch dem OS (Linux, Windows) zuzuschreiben und müssen dort auch angepasst werden, da hat FHEM eher wenig Aktien dran.

/Daniel

ZitatSecurity sollte IMMER vor Benutzerfreundlichkeit stehen, da hilft auch kein "Hinweis" das man ein Passwort vergeben sollte oder was auch immer.

Bitte keine Allgemeinplaetze, sondern konkrete Vorschlaege.

Zitat von: rudolfkoenig am 27 Dezember 2015, 11:47:16
Bitte keine Allgemeinplaetze, sondern konkrete Vorschlaege.

Also ich fand das eine recht konkrete Antwort auf Dein "Wenn man FHEM installiert, und keine Passwoerter vergibt, dann wird das ueberall (telnet/FHEMWEB) bemaengelt. Wenn man das ignoriert, dann kann ich auch nicht mehr tun."

Aber wenn es konkreter sein soll: Anstatt das fehlen eines Passworts zu bemängeln, sollte FHEM, falls kein Password gesetzt ist, ein zufälliges Passwort generieren und setzen und dem Benutzer beim ersten Zugriff anzeigen. Der Benutzer bestätigt mit OK, dass er dass Passwort zur Kenntnis genommen hat und dann ist das System schon mal mit einem Passwort abgesichert.

Zitatein zufälliges Passwort generieren und setzen und dem Benutzer beim ersten Zugriff anzeigen.

An so eine Loesung habe ich noch nicht gedacht.

Ich wuerde das beim telnet/FHEMWEB global Instanzen anzeigen, und bei einem "ok" fuer alle Instanzen das Passwort gleich setzen. Bei "cancel" wird fuer alle basicAuth/passwort auf none gesetzt, und damit erfolgt keine Warnung und auch keine Passwortabfrage mehr. Bei FHEMWEB waere die Loesung relativ einfach/intuitiv, bei telnet weniger.

Was sagen die anderen dazu? Ich bin nicht wirklich dafuer: Ich sperre lieber meine Haustuer ab (WLAN/Firewall) und nicht alle Zimmer (FHEM) einzeln. Beide abzuschliessen finde ich doof und ueberfluessig, und bin unsicher, ob ich das nun jedem Anfaenger empfehlen soll.

Zitat von: rudolfkoenig am 27 Dezember 2015, 13:15:06
An so eine Loesung habe ich noch nicht gedacht.

Ich wuerde das beim telnet/FHEMWEB global Instanzen anzeigen, und bei einem "ok" fuer alle Instanzen das Passwort gleich setzen. Bei "cancel" wird fuer alle basicAuth/passwort auf none gesetzt, und damit erfolgt keine Warnung und auch keine Passwortabfrage mehr. Bei FHEMWEB waere die Loesung relativ einfach/intuitiv, bei telnet weniger.

Was sagen die anderen dazu? Ich bin nicht wirklich dafuer: Ich sperre lieber meine Haustuer ab (WLAN/Firewall) und nicht alle Zimmer (FHEM) einzeln. Beide abzuschliessen finde ich doof und ueberfluessig, und bin unsicher, ob ich das nun jedem Anfaenger empfehlen soll.

Ich stimme Dir durchaus zu, und baiscAuth mit http setzt ja sowieso die Sicherheit beim Webzugriff nicht sehr hoch.

Wenn man hier etwas machen möchte fände ich es besser ein etwas weitgehenderes Konzept mit einer Art Einrichtungsdialog einzuführen, dort könnten dann
- User/passwort,
- Welche Ports wirklich gebraucht werden (TABLET, PHONE etc)
- später vielleicht auch https/SSL-Cert

aber eben auch nicht-Sicherheitsrelevante Einstellungen gemacht werden, wie z.B.
- Style des UIs
- Einstiegsseite
- ...

Wenn das generisch ist, könnten auch weitere Modulautoren dort etwaige Einstellungen hinterlegen (z.B. Weitere UIs, DBlog-Konfig?, etc). Bei manchen Modulen ist ja eine mehrstufige EInrichtung notwendig, die nicht in einem einzelnen define endet.

Das fände ich gut für die Sicherheit und gut für den Einstieg...

Wäre auch gerne bereit daran mitzuarbeiten

Hi,

bin auch dagegen.

Die "security" Fragen tauchen alle xx Monate mal auf. Gebetsmühlenartig fragt Rudi dann: "gebt mir Beispiele und ich fixe" - und dann kommt keins.

Oft kommt die Frage "Security" von Neulingen (echt nicht böse gemeint) und dort mMn unter falschen Annahmen. Siehe hier. Arbitrary File Disclosure und Code Execution gehören ja durchaus zum pentest Programm für Webdienste.

Nur: fhem ist eben kein webdienst sondern eine Programmierplattform. fhemweb ist ein interface mit dem RECHT SYSTEMBEFEHLE auszuführen.

Da sollte Security mMn über AWARENESS adressiert werden und nicht über (trügerischen) Passwortzwang.

Dafür einen Guide zu erstellen beführworte ich, gute Ansätze (user Management) haben wir ja auch hier im thread.
Darüber hinaus könnte man eine (wie auch immer geartete) Meldemöglichkeit für Security Issues einführen. Die sollte (mMn) so aufgebaut sein:

"xxx sollte unter den gegebenen Umständen yyy eigentlich verboten sein. Wenn man zzz macht ist es aber doch möglich". 

Das würde user die sich mit dem Thema beschäftigen "zwingen" sich mit dem Security Modell von fhem zu beschäftigen. In dem Zusammenhang Danke an den TE - ist ja gut das so etwas stattfindet. Man muss das halt kanalisieren.

vg
joerg

Hi zusammen,

ich denke das setzen von Passwörtern sollte jedem selbst vorbehalten sein. Warum sollte jemand einen Passwortschutz aktiviert haben wollen, wenn sein FHEM nur aus dem eigenen WLAN erreichbar ist und dieses nur von ihm selbst genutzt wird? Und ich bin sicher, dies ist die häufigste und auch die standard Konfiguration der Benutzer. Wer öffnet denn unbeabsichtigt und one es zu wissen einen Port zu dem Gerät wo FHEM installiert ist?
Die Sicherheit für solche Anwendungen muss ohnehin davor erfolgen und nicht in der Anwendung selbst.
Und wenn es striktere Möglichkeiten geben soll, dann bitte nur auf eigenen Wunsch und eigene Aktivierung hin.

Just my 2C.
LG
Martin

Hallo,

was ist denn der typische Anwendungsfall?

Gemäß Statistik sind ca. 98% der Anwender mit FHEM auf Linux und damit zu > 80% auf kleinen Systemen (ARM, MIPS, also wohl Raspberry PI, BBB und Konsorten bzw. Fritzbox).

Gehen wir mal davon aus, dass Ausgangspunkt eine Distribution ist, so dürfte das System sicher (aber nicht hart sicher) sein, bevor der Benutzer anfängt, FHEM zu installieren.

Über Gerätekonfigurationen entstehen erste Schwachstellen, beispielsweise über ECMD, wo ich Rückmeldungen von Geräten in beliebigen Perl-Kode einfüttern kann.

Die typischen Einfallstore wären dann doch das Telnet-Interface und das UI, meist FHEMWEB. Telnet kann man ohne Komfortverlust durch Passwort abdichten.

Das UI lässt sich m.E. ohne Komfortverlust nicht mit Kennwort sichern - es soll ja ggf. die ganze Familie rasch bedienen können, ohne erst ein Passwort zu tippen. Dann braucht man aber schon ein Rechtekonzept (damit Tommi seine Heizung verstellen kann aber die von Annika nicht und nur die Administratorin des Hauses konfigurieren und beliebige Systembefehle aufrufen kann).

Werimmer Zugriff auf FHEM hat, hat alle Rechte und Möglichkeiten, die der Benutzer hat, unter dem FHEM läuft.

Fazit für mich: so wie FHEM derzeit aufgebaut ist, darf ich nur Nutzern Zugriff geben, denen ich soweit vertraue, dass ich ihnen auch einen Shell-Zugriff geben würde. Ich stimme damit Joerg zu, dass Awareness die richtige Antwort auf die Frage nach der Sicherheit ist. Also kein Hardening Guide sondern ein Security Awareness Guide in der commandref, der die typischen Anwendungsfälle beschreibt und Tipps gibt, wie man Fallen vermeidet (Zugriff übers Web, dann ...; setze die Attribute ... und ..., wenn Du ...; ...).

Viele Grüße
Boris

Zitat von: herrmannj am 27 Dezember 2015, 14:09:20
Die "security" Fragen tauchen alle xx Monate mal auf. Gebetsmühlenartig fragt Rudi dann: "gebt mir Beispiele und ich fixe" - und dann kommt keins.

Ich versteh nicht was an nem XSS PoC wegzudiskutieren ist. Schon gar nicht mit "dann kommt keins".

Code Exec ist ein feature von FHEM. Akzeptier ich. Muss so sein. Wenn ich das allerdings via XSS und XSRF triggern kann ist das ne klare Verwundbarkeit und die Zuständigkeit das abzufangen liegt bei der Applikation und nicht beim User, denn der kann daran nix ändern.

Wie viele Fritzbox User habt ihr? Installieren die das normal auf ihrer Core Fritzbox oder schaffen die sich ein zusätzliches Gerät dafür an? Wenn die das auf der Core Fritzbox in ihrem Netzwerk installieren habt ihr für die User ein Riesenproblem, denn dann kann man in vielen Fällen direkt die interne IP raten und hätte damit einen praktikablen Angriff via XSRF und XSS auf die meisten Firtzbox User.

Bei allen anderen müsste man sich drauf verlassen, dass die den Link selbst zu ende bauen und einfach ausprobieren. Das schränkt das Problem etwas ein.

BTW: Wer von euch hat meine PoCs ausprobiert ohne zu wissen was die tun? ;)

In meinen Augen gehören Best Practices für die Programmierung im Bereich Security auch in ein System wenn das "ja doch nur im internen Netzwerk steht". Ich finde da gibt es keine Diskussion. Erst recht wenn man built-in code exec anbietet ...

Gruß,

Flo!

lass gut sein, Flo. Bringt nix die Diskussion...


Gruß
Julian

Zitat von: Loredo am 27 Dezember 2015, 23:06:39
lass gut sein, Flo. Bringt nix die Diskussion...

Warum nicht? Gibt es dafür Gründe?
Als User würde ich gerne mehr wissen. Mir leuchtet bspw. nicht ein, wo ich mich mit FHEM in Gefahr begebe, wenn ich es auf einer Fritzbox betreiben würde und FHEM/Fritzbox nicht von Außen erreichbar ist.
Gruß, Christian

@r0x0r: Ich habe den Eindruck, dass du unsere Antworten nicht liest, und ich frage mich, ob es Sinn hat dir zu antworten. Ich versuche es nochmal:

FritzBox ist zunehmend irrelevant. Es gibt ein paar FHEM-Benutzer, die noch nicht umgestiegen sind, Neulinge schaffen eine Installation nur auf veralteten Systemen, oder wenn sie viel Zeit investieren.
XSRF / CSRF kann man mit csrfToken verhindern
XSS funktioniert nur, wenn jemand mein Passwort hat.
Ich weiss nicht, wer deine "PoCs" ausprobiert hat, die waren alle der Klasse: "tippe im shell cat /etc/passwd ein, und staune".

ZitatIch finde da gibt es keine Diskussion.

Wenn man nicht zuhoeren will, dann wird es wohl dabei bleiben.


@Christian: das geht mit CSRF (https://de.wikipedia.org/wiki/Cross-Site-Request-Forgery), indem man z.Bsp. jemand im fhemwiki folgendes einbaut:
<img src="fritz.box:8083/fhem?cmd=set .* off">
Wenn du im Browser dich bei FHEM angemeldet hast, und die fhemwiki Seite anschaust, dann wird das basicAuth token uebertragen. Schuetzen kann man sich mit dem csrfToken Attribut, allerdings wurde das noch nicht breit getestet, und ist deswegen nicht per default aktiv.

ZitatIch versteh nicht was an nem XSS PoC wegzudiskutieren ist. Schon gar nicht mit "dann kommt keins".

Entschuldigung, das war nicht meine Absicht ignorant zu klingen.

Der Punkt ist das die XSS nur funktioniert wenn entweder kein Passwort gesetzt ist (user fehler!) oder derjenige der den XSS loslässt verfügt über user/pwd. Wenn letzteres der Fall ist macht der XSS keinen Sinn weil man über fhemweb ohnehin "andere Sachen" anstellen kann.

Eine "Lücke" ist (mMn) daher relevant wenn man damit ein System kompromittieren kann das per (unbekannter) user/pwd Kombination gesichert ist. So ist bitte die Frage nach den POC zu verstehen. (Die Beispiele können das mMn nicht, korrekt?)

fhemweb bietet im übrigen weitere Möglichkeiten zur Absicherung an. Der Zugang kann auf bestimmte IP Adressen begrenzt werden und pro fhemweb Instanz können Kommandos erlaubt (unterbunden) werden.

Btw:
ich finde die Security Fragen generell richtig, gut und notwendig. Das bringt nur nix wenn ich (vermeintliche) vulnerability auf einem System melde wenn ich da sowieso mit entsprechenden Rechten eingeloggt bin.

btw2
Bei fronthem gehe ich den Weg das ein device (a) autorisiert sein muss (derzeitig halbherzig ip), das (b) Kommandos pro device auf einer whitelist stehen müssen und das (c) eingehende Befehle von einem Application Proxy interpretiert und neu formuliert werden (converter).

Zu den häufigsten Fragen gehört ob man nicht a-c einfach weglassen kann ;)

vg
joerg

Zitat von: r0x0r am 25 Dezember 2015, 18:39:52
....Interesant wäre auch ein hardening guide für FHEM, das macht es den Leuten vielleicht einfacher. Ich bin einfach der Meinung, dass aufgrund der hohen Angriffsfläche den Leuten klarer mit auf den Weg gegeben werden sollte, was das heisst. ;)

Hallo r0x0r,

finde ich einen super Vorschlag. Wärest Du bereit den hardening guide zu erstellen? Man könnte das direkt in die Wiki aufnehmen.

Ich habe auf Grund der Warnmeldungen wahrgenommen, dass sich in letzter Zeit diesbzgl. bei FHEM viel getan hat. Leider habe ich aber praktisch keinen Überblick, was ich alles tun muss und warum.
Bisher bin ich mit dieser Laxheit gut gefahren, weil FHEM nur ein paar tausend User hat und nicht wirklich wirtschaftliche Vorteile für Angreifer bietet. Aber besser wäre es schon sich zu schützen.

Gruß
tupol

Zitat von: krikan am 27 Dezember 2015, 23:16:57
Warum nicht? Gibt es dafür Gründe?

Weil ich auch schon etliche Diskussionen darüber geführt habe (im Rahmen des Hoanoho Frontend Image Threads) und mir deutlich gemacht wurde, dass man den Grundsatz nicht möchte, dass ein zunächst möglichst gut abgesichertes System "convenient" bereitgestellt wird. Man möchte lieber, dass jeder sich selbst über Sicherheit gedanken machen muss und erwartet eben auch, dass jeder das kann. Wer das nicht kann, hat eben pech gehabt - so die Devise. Man möchte nicht einfach zu handhaben und trotzdem sicher sein. Man möchte gerne besonders bleiben und vornehmlich nur die Leute anlocken, die tiefgreifende technische Kenntnisse haben oder sich erwerben möchten.



Ich denke @r0x0r möchte IMHO darauf hinaus, dass die Sicherheit innerhalb von FHEM nicht granularer z.B. über ein Rollen-Reche-Konzept abgesichert werden kann.


Es ist sicher richtig, dass man vorher auch schon alles mögliche tun soll und muss, um den Zugriff auf FHEM ansich abzusichern. Ein nur lokal erreichbares FHEM mag da attraktiv klingen, verschließt sich aber der Realität, dass es keine wirklichen Insel-Netzwerke (mehr) gibt. Nur weil ich kein Port-Forwarding eingerichtet habe bedeutet das nicht, dass nicht jemand über ein anderes, verwundbares Gerät in meinem Netzwerk sich dann trotzdem frei im Netz bewegen kann. Dafür muss man keine Ports weiterleiten.
Das mag alles höchst unwahrscheinlich klingen, dennoch bleibt ein Angriffspunkt von innen heraus derjenige, der nicht richtig angegangen wird.


CSRF schützt halt nur die FHEM Standard-GUI und ich bin nicht sicher, ob man bei Nutzung anderer GUIs und Apps nicht auf Probleme stößt, wenn man dies aktiviert hat.


Nun kann ich einzelne FHEMWEB Instanzen in ihren Kommandos einschränken. Das hilft allerdings nur sehr bedingt, denn in Modulen werden set und get Kommandos meistens nicht darin unterschieden, ob sie für einen Anwender oder den Systemverwalter gedacht sind. Sie in der Oberfläche auszublenden ist halt nur Kosmetik. In einigen meiner Modulen gibt es deshalb den Support für "set-user" in allowedCommands, was aber ansonsten leider keinen Anklang fand. Ich würde grundsätzlich gerne alle meine User vor Fehlbedienung schützen und auch bedenken wollen, dass z.B. ein Kind im Haushalt sich als Probe-Hacker probieren will nur um den Vater mal zu ärgern (so sind Pubertierende nunmal).
Ich könnte als Vater dann nur den Zugriff zur Haussteuerung komplett abschalten, was in den meisten Fällen dann auch nicht geht, wenn man Haussteuerung denn ernst nehmen will.


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".

ZitatMan möchte gerne besonders bleiben und vornehmlich nur die Leute anlocken, die tiefgreifende technische Kenntnisse haben oder sich erwerben möchten.

Da spricht aber viel Weltschmerz daraus.  FHEM ist mAn nicht das richtige System fuer den Gelegenheitsanwender, sondern fuer den Bastler, der bereit ist Zeit zu investieren. Erinnert mich an Heimwerkermaerkte, ich glaube nicht dass die "besonders" sind, werden trotzdem gebraucht, und sind sicher nicht fuer alle was.

Ein FHEM2 ist (auch wenn ich es mir oefters wuensche) illusorisch, bzw. das muss dann nicht mehr FHEM genannt werden.

Was nicht illusorisch ist, FHEM schrittweise zu erweitern, das hat allowedComands ja auch geschafft. Wenn man die bisherige Pruefung auf $cl->{".allowed"} in ein "AUTH" Modul auslagert, dann muss fhem.pl auch nicht grundlegend umgestaltet werden, und man koennte in diesem "AUTH" ohne Probleme Benutzer/Rechte/Auditing einbauen. Whitelisting/blacklisting von Parametern ist auch moeglich, ohne jedes Modul dafuer umzukrempeln. Es muss nicht von Anfang an perfekt sein, man kann damit aber Erfahrung sammeln.

Aber offensichtlich ist dieses Problem nur fuer wenige relevant, da es bisher nicht in Angriff genommen wurde.

Hallo,

ich versuche mal, der Diskussion ein Ziel zu geben. Ich mag keine Themen, die nur Quasselbuden sind.

Loredo hat richtig bemerkt, dass das System sicher und bequem zugleich sein muss. Joergs fronthem geht den Weg des Security by Design. Bei FHEMWEB sind wir auf dem Stand, dass man es soweit sichern kann, dass nur autorisierte Benutzer darauf zugreifen können (Basic Auth, Verhinderung von XSS und CSRF) - die autorisierten Benutzer dürfen dann alles tun, was der User, unter dem FHEM läuft, auf der Maschine tun darf.

Habe ich das richtig verstanden?

Wovon können wir derzeit überhaupt realistisch ausgehen?
- Derjenige der FHEM konfiguriert (FHEM-Administrator), muss wissen, was er tut. Er hat die Kontrolle und soviel Macht, wie der User, unter dem FHEM läuft. Maßnahmen: 1) Security Awareness Guide. 2) Zugriff über telnet wird nur dem FHEM-Administrator erlaubt.
- Derjenige, der FHEM bedient (FHEM-Bediener): Hier ist es durchaus realistisch, nach und nach den Bediener soweit einzuzäunen, dass er nur das bedienen kann, was er bedienen darf. Maßnahme: Vorschlag von Rudi für Auth.pm.

Viele Grüße
Boris

Hallo,

vielen Dank für das Thema und die bis jetzt geführte Diskussion. Auch ich würde es begrüßen, wenn wir für Fhem ISMS-Regeln (Information Security Management System) aufstellen und einführen würden. Sicherheit in der Heimautomation sollte nicht eben nicht mal so nebenbei erfolgen, sondern schon Ergebnis und Ziel gerichtet. Hierbei ist aber wichtig die Ziele zu definieren und deren Einhaltung einzufordern. Aus der Diskussion habe ich entnommen, dass es mehrere Ziele zu geben scheint:

1. Absichern des Fhem-Systems gegen Komprometierungsversuche von außen.
Dies scheint mir das vorrangige Ziel zu sein, da ein Einbruch in mein Heimnetzwerk mit dem Ziel dieses für kriminelle Zwecke zu nutzen für mich unter Betreiberhaftung und damit in meine Verantwortung fällt.

2. Absichern des Fhem-Systems gegen Fehlbedienungen oder Blödsinn von Bewohnern.
Würde ich mit geringerer Priorität versehen. Viel kann hier schon über die vorhandenen Frontends gemacht werden, bzw. fällt vielleicht unter "Erziehung".

3. Absichern von Fhem-Devices.
Leider benutzen die meisten Devices offene Protokolle, sei es im Funkbereich (433 / 868 MHz) oder im IP-Bereich, wo WLAN-Devices wenig bis gar nicht abgesichert sind. Die Frage ist hier, was steuere ich über diese Devices und welches ist der maximale Schaden der angerichtet werden kann, wenn jemand vor meinem Haus steht. Hier könnte eine Lösung sein, dass wenn Fhem Schaltbefehle erkennt, die es selber nicht ausgelöst hat, Fhem dann eine Warnung ausgibt und den Ursprungszustand wieder herstellt. Meine Alarmanlage läuft jedenfalls nicht über Fhem.

Grüße Jörg

Zitat von: JoWiemann am 28 Dezember 2015, 11:20:12
1. Absichern des Fhem-Systems gegen Komprometierungsversuche von außen.
Dies scheint mir das vorrangige Ziel zu sein, da ein Einbruch in mein Heimnetzwerk mit dem Ziel dieses für kriminelle Zwecke zu nutzen für mich unter Betreiberhaftung und damit in meine Verantwortung fällt.

Welche Maßnahmen ergeben sich daraus? Reicht es, den vorgeschlagenen Security Awareness Guide (welche Angriffsvektoren gibt es und was muss ich tun, um diese zu unterbinden?) in die commandref aufzunehmen?

Gehört habe ich dazu schon: "Will ich!". Es hat sich noch keiner gemeldet, der "Mach ich!" gerufen hat.

Zitat
2. Absichern des Fhem-Systems gegen Fehlbedienungen oder Blödsinn von Bewohnern.
Würde ich mit geringerer Priorität versehen. Viel kann hier schon über die vorhandenen Frontends gemacht werden, bzw. fällt vielleicht unter "Erziehung".

Der OP hat mMn die Sicherheitsrisiken aus der Position des FHEM-Bedieners geschildert.

Die Antwort darauf war: ja, der Bediener darf alles tun, was der User darf, unter dem FHEM auf der Maschine läuft. Dem legitimen FHEM-Bediener Befehle unterzuschieben, z.B. durch CSRF (Klicke einen Link im Forum und alle Lichter gehen zuhause aus) lässt sich verhindern - bisher hat noch keiner das Gegenteil bewiesen.

Alles darüber hinaus wäre eine Erweiterung von FHEM(WEB), nämlich die FHEM-Bediener einzuzäunen. Es gibt dazu Vorschläge (Rudis Auth.pm) aber noch keinen, der gerufen hat: "Will ich!" Oder gar: "Mach ich!"

Zitat
3. Absichern von Fhem-Devices.
Leider benutzen die meisten Devices offene Protokolle, sei es im Funkbereich (433 / 868 MHz) oder im IP-Bereich, wo WLAN-Devices wenig bis gar nicht abgesichert sind. Die Frage ist hier, was steuere ich über diese Devices und welches ist der maximale Schaden der angerichtet werden kann, wenn jemand vor meinem Haus steht. Hier könnte eine Lösung sein, dass wenn Fhem Schaltbefehle erkennt, die es selber nicht ausgelöst hat, Fhem dann eine Warnung ausgibt und den Ursprungszustand wieder herstellt. Meine Alarmanlage läuft jedenfalls nicht über Fhem.

M.E. kein Thema für FHEM, auch wenn es im Kontext von FHEM relevant ist.

Viele Grüße
Boris

ja sicherheit ist wichtig. ja die entwickler müssen das ernst nehmen. ja man muss viele an die hand nehmen und auf risiken hinweisen. ja wir sollten vermeiden das sich jemand aus unwissenheit ein bein stellt.

aber: wie oben schon erwähnt muss man abwägen und schutzwürdikeit und bedrohung mit einbeziehen und den komfort und die bequemlichkeit nicht ausser acht lassen.

jeder der in mein haus kommt kann die heizung von hand verstellen, licht machen oder rollläden und fenster öffnen. ich schraube weder griffe noch schalter oder ventile ab weil ich die haus tür offen lasse sondern mache die haustür zu und sorge dafür das der zutritt von aussen sicher ist.

wenn jemand meint er müsse trotz einschlägiger hinweise auf vpn trotzdem mit portforwarding arbeiten kann man das nicht verbieten.

ich glaube auch nicht das hier jemand unwillig ist konkrete am code etwas zu ändern und zu verbessern wenn es hinweise auf tatsächliche probleme gibt. so unvollkommen allowedCommands ist es ist ein anfang den jeder weiter ausbauen kann der möchte.

fhem lebt vom mit machen. nicht vom drüber reden und es wäre schade wenn gegenargumente oder eine diskussion als unwilligkeit aufgefasst werden. manchmal sind es auch einfach nur mangelnde zeit oder mangelnde ideen.

gruss
  andre

wenn mans genau nehmen wollte, muesste man ein code review auch noch in betracht ziehen um, ggf. schadcode in den modulen zu finden.
das eigene haus mag als "ziel" nicht sonderlich attraktiv sein, eine "armee" von fhem-systemen, die als DDoS bots knechten scheint da schon eher interessant.
oder gezielte schadsoftware-verteilung zur ransomware verbreitung?
oder das ausspaehen von interessanten daten?
oder oder oder...

ich arbeite in dieser branche und seit "assume compromise" durch die etagen der CISOs geistert, sind alle von einer art sicherheitsparanoia befallen. wobei manches davon auch durchaus berechtigt sein mag...

ueber eine art hardening guide oder vergleichbarem wuerde ich mich durchaus freuen :-)

markus

Zitat von: justme1968 am 28 Dezember 2015, 13:13:56
ich glaube auch nicht das hier jemand unwillig ist konkrete am code etwas zu ändern und zu verbessern wenn es hinweise auf tatsächliche probleme gibt. so unvollkommen allowedCommands ist es ist ein anfang den jeder weiter ausbauen kann der möchte.

fhem lebt vom mit machen. nicht vom drüber reden und es wäre schade wenn gegenargumente oder eine diskussion als unwilligkeit aufgefasst werden. manchmal sind es auch einfach nur mangelnde zeit oder mangelnde ideen.

http://forum.fhem.de/index.php/topic,35338.msg276859.html#msg276859 (http://forum.fhem.de/index.php/topic,35338.msg276859.html#msg276859)

Zitat von: Dr. Boris Neubert am 28 Dezember 2015, 12:02:14
Welche Maßnahmen ergeben sich daraus? Reicht es, den vorgeschlagenen Security Awareness Guide (welche Angriffsvektoren gibt es und was muss ich tun, um diese zu unterbinden?) in die commandref aufzunehmen?

Die essentiellen Attribute bei FHEMWEB habe ich, wie es der Zufall will, gerade hier erklärt:
http://forum.fhem.de/index.php/topic,45845.msg380625.html#msg380625 (http://forum.fhem.de/index.php/topic,45845.msg380625.html#msg380625)


Das kann ich gerne noch etwas ausformuliert in einem Wiki Artikel beschreiben.
Auch kann ich anbieten meine Erfahrungen für den Einsatz von HAproxy als generischen HTTP+TCP Proxy und TLS-Offloading (https://github.com/Hoanoho/HSE/tree/develop/lib/cfg/any/stat/etc/haproxy) zu verwenden.
Ein Script zum Härten eines Systems (https://github.com/Hoanoho/HSE/blob/develop/bin/hoanoho-enforce-security.sh) gibt es seit längerem in einer ersten Fassung, welche man recht einfach generisch aufbereiten kann, ebenso generelle Systemkonfigurationen (https://github.com/Hoanoho/HSE/tree/develop/lib/cfg).

Zitat von: Dr. Boris Neubert am 28 Dezember 2015, 12:02:14
Alles darüber hinaus wäre eine Erweiterung von FHEM(WEB), nämlich die FHEM-Bediener einzuzäunen. Es gibt dazu Vorschläge (Rudis Auth.pm) aber noch keinen, der gerufen hat: "Will ich!" Oder gar: "Mach ich!"

Konzeptionell arbeite ich gerne mit, umsetzen sollte das aber jemand, der den FHEM Kern aus dem FF kennt.

Das ganze wird ja durchaus kreativ und konstruktiv!

Ich finde die Idee des Auth-Moduls gut und unterstütze auch das von Loredo beschriebene Szenario, dass set-commands für unterschiedliche Benutzergruppen / neudeutsch Personas gibt. Gut finde ich insbesondere, dass hier ein Nutzen für Sicherheit und zusätzliche Funktionalität gibt!

Ich biete auch gerne an, das Auth-Modul (mit-)zuentwickeln, es erfordert aber vermutlich auch einige Veränderungen an FHEMWeb und fhem.pl. Ein bisschen Design bräuchte man aber auch. Also ein paar Dinge zum Einstieg:

Ein grundlegendes Szenario für unterschiedliche Berechtigungen ist es Benutzergruppen dodoer -Rollen zu schaffen (oder Berechtigungsstufen).
Für Auditing wären dann auch benannte Benutzer erforderlich.
Das wäre für mich der Startpunkt.

Fragen:
Benutzerrollen vordefinieren oder beliebig? - Ich favorisiere vordefinierte Rollen, die erweitert werden können
Mein Vorschlag - (God) / Administrator / Operator / Expert / User / Guest
Wird erstmal nur eine Absicherung vom interaktiven FHEMWeb gemacht, oder wird das ganze auch gleich auf telnet und fhem Kommandos ausgeweitet?


Unter Sicherheitsaspekten treten dabei auch schon verschiedene Fragestellungen auf:
- Die Konfiguration für ein Auth.pm sollte man von der restlichen Konfiguration trennen können (disk und im Speicher)
- Ein "normales" Modul sollte Auth.pm nur lesend / abfragend nutzen dürfen
- Die Erstellung und Ausführung von perl-Befehlen in notfiy/DOIF/etc öffnet die nächste Dimension vonn Problemen

die idee alles was berechtigungen angeht an einer stelle zusammen zu fassen finde ich gut. auch die möglichkeit berechtigungen auf benutzen ebene statt web, telnet oder sonstiger instanz zu vergeben würde die konfiguration einfacher machen.

bis dahin habe ich hier: http://forum.fhem.de/index.php/topic,46302.msg380652.html#msg380652 (http://forum.fhem.de/index.php/topic,46302.msg380652.html#msg380652) einen vorschlag für ein neues attribut allowedDevices gepostet. es funktioniert analog zu allowedCommands.

ich könnte mir vorstellen das man die allowedCommands und allowedDevices attribute als fallback/default verwendet und diese durch benutzer spezifische permissions weiter einschränkt sobald sich ein benutzer authentifiziert hat.

gruss
  andre

ps: die allowed attribute funktionieren für web und telnet. d.h. über eine web oder telnet verbindung abgesetzte kommandos. egal ob durch tippen oder durch klicken.

Zitat- Die Konfiguration für ein Auth.pm sollte man von der restlichen Konfiguration trennen können (disk und im Speicher)

hier müssen automatisch die gleichen mechanismen greifen die Auth.pm bereit stellt. d.h. auch god oder administrator sollten nicht extra out of band arbeiten. wenn man hier rechte entzieht dann sind sie weg.

Zitat- Ein "normales" Modul sollte Auth.pm nur lesend / abfragend nutzen dürfen

siehe oben. wir verwenden ein system das auf einem interpreter basiert. jedes modul hat vollen zugriff auf alles und die möglichkeit coder per eval zu laufzeit auszuführen ist integral und wichtig. wenn sich die sicherheit auch hier auf erstrecken soll sind zusätzliche maßnahmen wie sandboxen und getrennte prozesse die nur über definierte schnittstellen kommunizieren nötig. um das frontend vom backend zu trennen ist das unter umständen einfacher als es ausschaut.

Zitat- Die Erstellung und Ausführung von perl-Befehlen in notfiy/DOIF/etc öffnet die nächste Dimension vonn Problemen

das verstehe ich nicht... notify/DOIF/... müssen alles dürfen (sie laufenden ja im system kontext und nicht als bestimmter benutzer) aber 'normale' nutzen dürfen diese nicht anlegen. d.h. define, modify und defmod gehören nur dem administrator.

gruss
  andre

und noch etwas wichtiges: wir müssen unterscheiden zwischen rechten und möglichkeiten dir ein anwender absichtlich und aus desingn gründen hat und dem unberechtigten 'erschleichen' von nicht beabsichtigten rechten. beides hängt zwar zusammen. es sind aber zwei unterschiedliche dinge.

Zitat von: justme1968 am 28 Dezember 2015, 15:11:13
siehe oben. wir verwenden ein system das auf einem interpreter basiert. jedes modul hat vollen zugriff auf alles und die möglichkeit coder per eval zu laufzeit auszuführen ist integral und wichtig. wenn sich die sicherheit auch hier auf erstrecken soll sind zusätzliche maßnahmen wie sandboxen und getrennte prozesse die nur über definierte schnittstellen kommunizieren nötig. um das frontend vom backend zu trennen ist das unter umständen einfacher als es ausschaut.

Ja das war meine Überlegung: Auth.pm sollte seine Info nicht direkt in den globalen Datenstrukturen (z.B. Devicehash) ablegen, sondern vielleicht als getrennter Prozess laufen. Problem: Welchen Einfluss hat das auf die Geschwindigkeit?

Zitat von: justme1968 am 28 Dezember 2015, 15:11:13
das verstehe ich nicht... notify/DOIF/... müssen alles dürfen (sie laufenden ja im system kontext und nicht als bestimmter benutzer) aber 'normale' nutzen dürfen diese nicht anlegen. d.h. define, modify und defmod gehören nur dem administrator.

Vielleicht war das zu kompliziert gedacht, aber es ging mir um die Möglichkeit einer "perl-code-injection", also z.B. ein notify, das man so aufruft, dass zusätzlicher perl-code übergeben wird der dann innerhalb des notfies mit ausgeführt wird. Wobei das vielleicht wirklich nicht zu den Anfangsproblemen gehört.
Wenn meine Kinder nachts noch eine Lampe zum Lesen brauchen, dann können Sie die einschalten und müssen FHEM dafür nicht kapern  ;)

Zitat von: viegener am 28 Dezember 2015, 14:53:22
Das ganze wird ja durchaus kreativ und konstruktiv!

Danke, ja, finde ich super!

Zitat
Ein grundlegendes Szenario für unterschiedliche Berechtigungen ist es Benutzergruppen dodoer -Rollen zu schaffen (oder Berechtigungsstufen).
Für Auditing wären dann auch benannte Benutzer erforderlich.
Das wäre für mich der Startpunkt.

Ich habe mal vor 10 Jahren ein generisches Berechtigungssystem für die Softwaresuite des Unternehmens konzipiert, für das ich damals arbeitete. Das funktionierte so:

Es gibt Berechtigungen. Jedes Modul bringt Berechtigungen mit und stellt sie in einem zentralen Repository ein.
Es gibt Rollen. Eine Rolle ist eine Menge von Berechtigungen.
Es gibt Gruppen. Jeder Gruppe sind 0..n Rollen zugewiesen.
Jeder Benutzer ist in 1..m Gruppen.
(Man konnte einem Benutzer auch direkt eine Rolle zuordnen ohne Umweg über eine Gruppe.)

Zitat
Benutzerrollen vordefinieren oder beliebig? - Ich favorisiere vordefinierte Rollen, die erweitert werden können
Mein Vorschlag - (God) / Administrator / Operator / Expert / User / Guest
Wird erstmal nur eine Absicherung vom interaktiven FHEMWeb gemacht, oder wird das ganze auch gleich auf telnet und fhem Kommandos ausgeweitet?

Für meine Zwecke bräuchte ich folgende Rollen (im Sinne meiner obigen Definition), schematisch und beispielhaft:

Administrator - hat Berechtigungen zum Konfigurieren
KiZ1Bewohner - hat Berechtigung, alles in Kinderzimmer1 zu schalten
KiZ2Bewohner - hat Berechtigung, alles in Kinderzimmer2 zu schalten
HausBewohner - hat Berechtigung, alle Beleuchtungen in Wohnzimmer, Küche, Bad zu schalten
Hausmeister - hat Berechtigung, alles zu schalten zu verändern

Folgende Gruppen:
- Administratoren mit Rollen Administrator
- Eltern mit Rolle Hausmeister
- Kind1 mit Rollen KiZ1Bewohner, HausBewohner
- Kind2 mit Rollen KiZ2Bewohner, HausBewohner

Benutzer:
- Boris in Gruppen Administratoren, Eltern
- NameMeinerFrau in Gruppe Eltern
- NameVonKind1 in Gruppe Kind1
- NameVonKind2 in Gruppe Kind2

Viele Grüße
Boris

Zitat von: Dr. Boris Neubert am 28 Dezember 2015, 16:08:06
Es gibt Berechtigungen. Jedes Modul bringt Berechtigungen mit und stellt sie in einem zentralen Repository ein.
Es gibt Rollen. Eine Rolle ist eine Menge von Berechtigungen.
Es gibt Gruppen. Jeder Gruppe sind 0..n Rollen zugewiesen.
Jeder Benutzer ist in 1..m Gruppen.
(Man konnte einem Benutzer auch direkt eine Rolle zuordnen ohne Umweg über eine Gruppe.)

Ich würde vorschlagen, dass man über Rollen, die wieder Rollen enthalten die Gruppen überflüssig machen und damit die Komplexität veringern könnte.

Bei den Berechtigungen fände ich es gut, wenn es noch ein generisches Element hereinkommt. Also ein Modul KANN Berechtigungen mitbringen aber vordefiniert ist so etwas wie
- Anlage/Löschen eines Devices von einem Modul
- Verändern eines Devices - sprich attr (auch setreading und Kollegen
- Nutzen eines Devices - sprich set
- Auslesen eines Devices - sprich get und natürlich die entsprechenden Funktionen
Dann ist immer noch die Dimmension Modul (Klasse bzw. alle Instanzen) vs. Device (Instanz)

Das klingt aber auch schon recht kompliziert in der Verwaltung und Anzahl...

Vielleicht sollte man bei den Berechtigungen doch noch einfacher starten und erstmal auf fhem-Kommando-Ebene klassifizieren was zu den Basis-Rollen gehört.

Zitat von: viegener am 28 Dezember 2015, 17:03:39
Vielleicht sollte man bei den Berechtigungen doch noch einfacher starten und erstmal auf fhem-Kommando-Ebene klassifizieren was zu den Basis-Rollen gehört.

Der Ansatz einer Beschreibung der Rollen:

Std Role	Default definition
God	Do everything
Administrator	Hardware and cross-FHEM instance
Operator	Managing one Instance of FHEM (but not the system administration)
Expert	Extended capabilities for specific devices/modules etc
User	Use devices
Guest	Default: No rights but might be overwritten

So könnte die Klassifikation für die Kommandos von FHEM aussehen:

COMMANDS	Module specific	Std Role for ALL	Optional Role	Comment
apptime		Administrator
attr	X	Operator	Expert
backup		Operator
CULflash		Administrator
cancel		Operator	Expert
cmdalias		Operator
configdb		Administrator
copy	X	Operator	Expert
createlog	X	Operator	Expert
define	X	Operator	Expert
defmod	X	Operator	Expert
delete	X	Operator	Expert
deleteattr	X	Operator	Expert
deletereading	X	Operator	Expert
displayattr	X	User
fheminfo		Operator
get	X	Expert	User
getstate	X	Expert	User
?,help		User
IF	X	??
include		Operator
inform		Expert	User
JsonList		Expert	User
JsonList2		Expert	User
list		Expert	User
modify	X	Operator	Expert
msg	X*	Operator	Expert	Könnte  ein Problem wg. Der angestossenen Befehle sein
notice		Operator
quit		Operator
reload		Administrator
rename	X	Operator	Expert
rereadcfg		Operator
restore		Administrator
save		User
set	X	Operator	Expert
setdefaultattr		Operator
setreading	X	Expert	User
setstate	X	Expert	User
shutdown		Operator
sleep		User
trigger	X*	Operator	Expert	Könnte  ein Problem wg. Der angestossenen Befehle sein
update		Administrator
usb		Administrator
version		Operator
xmllist		Expert	User
PERL		Operator

Das X soll bedeuten, dass die Unterscheidung Modul- oder Devicespezifisch sein muss/kann und bei X* kommen noch die darin wiederum verwendeten Module/Devices dazu.

das ist noch nicht ganz konsistent.

xmlslist wird anders behandelt als list und jsonlist und die wieder anders als displayattr. ausserdem ist es sinnvoll hier nicht (nur) das kommando einzuschränken sondern auch das device auf das es angewendet wird zu berücksichtigen. wenn ein user ein device bedienen und sehen und eventuell konfigurieren darf sollte er auch list und andere kommandos darauf anwenden dürfen.

man muss auch noch unterscheiden zwischen kommandos ausführen und devices sehen. ein guest ohne alle rechte (auch ansehen) ist nutzlos.

gruss
  andre

Hallo,

verschachtelte Rollen oder Gruppen läuft am Ende auf dasselbe hinaus, wobei verschachtelte Rollen etwas mehr Flexibilität bieten.

Wenn fhem.pl ein Modul lädt, wird die Aufgabe, die Berechtigungen zu ermitteln, an Auth.pm delegiert:

Wenn es eine PermissionsFn gibt, wird diese benutzt, um die möglichen Berechtigungen zu erhalten.
Sonst werden define, modify, delete, und alle getter (wie get ?) und setter (wie set ?) als Berechtigungen aufgenommen (was Du als generische Rollen beschreibst).

Oh, da kommt noch eine zweite Dimension ins Spiel: die Rollen können ja pro Gerät gesetzt werden (Kind1 darf Heizung1 verstellen aber nicht Heizung2).

Dann müssen die definierten Rollen x Geräte noch persistent gemacht werden, und zwar idealerweise so, dass sie Berechtigungen nicht vergessen, wenn sie mal nicht geladen werden (sonst ist bei jedem kleinen Fehler gleich die Berechtigungssituation zerschossen).

Dann noch eine generische Funktion hasUserRight($hash, "get", "command"). Wer sein Modul Auth-enablen will, muss dann nur require Auth; schreiben und die DefineFn, ModifyFn, ..., SetFn mit hasUserRight() spicken (es sei denn, dass das generisch in fhem.pl geht).

Und der User muss noch authentifiziert sein. Könnte man bei FHEMWEB aus dem BasicAuth nehmen. Wenn nicht gesetzt, dann ist hasUserRight() immer 1.

Das wird schon aufwendig.

Viele Grüße
Boris

Ich bin doch positiv beeindruckt vom Diskussionsverlauf  :)

Zitat von: viegener am 28 Dezember 2015, 17:13:09

msg

X*

Operator

Expert

Könnte  ein Problem wg. Der angestossenen Befehle sein

Das X soll bedeuten, dass die Unterscheidung Modul- oder Devicespezifisch sein muss/kann und bei X* kommen noch die darin wiederum verwendeten Module/Devices dazu.

Ich arbeite noch an der "offiziellen" Doku, ja der Seitenhieb kommt an  8)


Für mein Verständnis ist msg kein Kommando, welches man einfach so als User oder ständig in der Kommandozeile ausführt. Vielmehr wird es als eine Art Wrapper für die Kommunikation mit Hilfe von Devices genutzt und erstellt entsprechende Readings (eher zur Status-Anzeige und Debug-Zwecken). msg-Befehle gehören also eher in notify, DOIF oder dergleichen hinein, also dort, wo Automationen definiert werden. Diese laufen nach meinem Verständnis ohnehin immer im Systemkontext und ohne gesonderte Beschränkung. Fehlt msg in allowedCommands kann man es auch jetzt schon nicht ausführen, was absolut ausreichend ist. Die Standardrolle wäre hier also "Administrator".


@Boris, deine generische Beschreibung finde ich sehr gut.

läuft gut :)

attrib fehlt mMn in der Betrachtung - wegen der evals ...

vg
joerg

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

Version oben (http://forum.fhem.de/index.php/topic,46181.msg380737.html#msg380737 (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.

Zitat von: viegener am 28 Dezember 2015, 18:40:29
- @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.

Zitat von: viegener am 28 Dezember 2015, 18:40:29
- @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).

Zitat von: viegener am 28 Dezember 2015, 18:40:29
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.

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.

Zitat von: Loredo am 28 Dezember 2015, 00:10:38
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...

Full ack, Martin

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.

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)


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


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:


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?

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.

Ich habe nginx rumgewickelt.

Zitat von: dero am 24 November 2016, 20:53:15
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