FHEM Security

[justme1968]

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

[micomat]

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

[Loredo]

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

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


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 zu verwenden.
Ein Script zum Härten eines Systems gibt es seit längerem in einer ersten Fassung, welche man recht einfach generisch aufbereiten kann, ebenso generelle Systemkonfigurationen.

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.

[viegener]

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

[justme1968]

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

[justme1968]

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

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

- 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

[justme1968]

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.

[viegener]

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?

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 

[Dr. Boris Neubert]

Das ganze wird ja durchaus kreativ und konstruktiv!

Danke, ja, finde ich super!

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

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

[viegener]

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.

[viegener]

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.

[justme1968]

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

[Dr. Boris Neubert]

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

[Loredo]

Ich bin doch positiv beeindruckt vom Diskussionsverlauf 

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 


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.

[herrmannj]

läuft gut

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

vg
joerg