eibd URL im Backend

[makki]

Die eibd-URL (local:/tmp/eib) ist im Backend derzeit hardcoded, was unter Umständen nicht optimal ist wenn z.B. die CV auf einem Gerät und der eibd auf einem anderen Host läuft.

Die Übergabe per URL-Parameter o.ä. hatten wir initial aus Sicherheitsgründen ausgeschlossen, Vorschlag wäre nun folgender:

- Defaultmässig natürlich weiterhin local:/tmp/eib
- Optional wird eine Environment-Variable EIBD_URL ausgelesen

Zu setzen wäre diese in der Webserver-config, am Beispiel lighty:

server.modules              = (
...
	    "mod_setenv",
...
)
setenv.add-environment = ( "EIBD_URL" => "local:/tmp/eib" )

Einwände, andere/bessere Vorschläge ?

Makki

[Chris M.]

Für mich: absolut i.O.

[makki]

Wird eh nicht morgen realisiert, wenn noch was kommt -> her damit!

Was ich oben aber vergessen habe: das coole daran ist (und warum genau diese Umsetzung), man könnte damit auch auf einem Webserver verschiedene Instanzen laufen lassen, die auf mehrere, voneinander unabhängige KNX-Instanzen zugreifen
Das mir keiner sagt, das würde nicht weit jenseits von KNX auch gut skalieren

Makki

[ctr]

Hmm, irgendwie verstehe ich das nicht, das ist doch ein Socket oder? Wie soll man den denn auf einem remote-System erreichen können?
Wie soll denn die CV aufs Netz zugreifen wenn kein lokaler eibd läuft?

Wünschenswert den Pfad des Sockets zu ändern wäre es natürlich trotzdem, warum der per default in /tmp steht weiß wohl auch nur Martin Kögler, imho gehört sowas nach /var/run (mal von den Rechten ganz abgesehen, aber das ist ein anderes Thema)

[makki]

Naja, nehmen wir mal an, das geht, war ja nicht die Frage

Makki

P.S.: den Socket kann man per -uXXX auch angeben, /var/run ist nach FHS ebenso falsch, stellt sich die Frage welche Rolle das bei einer absoluten Spezialsache spielt.
Und die Rechte, naja, ich bin es der den chmod a+rw /tmp/eib macht, damit es nun einfach funzt, was soll der heckmeck angemeldete User auszusperren, wo -i und -R (KNXnet/IP Routing) für hanni&Nanni 100% offen sind
KNX ist völlig sicherheitsfrei, ist halt so, da muss man IMHO nun nicht bei guten Lösungen anfangen mit vermeindlicher Security Anwender zu ärgern

Makki

[ctr]

KNX ist völlig sicherheitsfrei, ist halt so, da muss man IMHO nun nicht bei guten Lösungen anfangen mit vermeindlicher Security Anwender zu ärgern

Gerade *weil* KNX völlig sicherheitsfrei ist sollte man sich die Mühe machen, weil das WG immerhin ein Gateway zwischen KNX und IP darstellt und damit eine Brücke von einem unsicheren aber physisch begrenzten Medium zu einem potentiell unkontrollierbarem Medium (vermutlich werden fast alle WG Nutzer ihr WG im normalen LAN zu stehen haben und dann einige womöglich noch über Wireless oder das Internet (ohne VPN) darauf zugreifen.) Ich will jetzt wirklich nicht auf die Details eingehen und es gibt mit Sicherheit auch noch andere Ansatzpunkte, aber wenn mir etwas auffällt, dann äußere ich das auch und ein Socket mit rwx für jeden ist alles andere als ideal (so ließe sich z.B. mit jedem Bug im Webserver oder cgi oder php Daten vom Socket lesen, schreiben oder sogar den Socket durch einen Wrapper ersetzen der dann lustige Sachen macht)

Ich denke auch nicht dass man dadurch "Anwender ärgert" wenn man auf Distributionsseite ein gewisses Maß an Sicherheit hinzufügt indem man z.B. die Rechte so einschränkt, dass auch nur darauf zugreifen darf wer es muß. Wenn sich dann jemand zum Basteln als root auf dem WG einloggt, dann darf er sowieso alles und sonst gibt es keine User auf der Kiste sondern nur System accounts, d.h. da sollte man wissen wer Zugriff braucht und wer nicht...

Btw, wo steht in der FHS das Sockets nicht mehr nach /var/run dürfen? Imho dürfen dort nur keine *User* Sockets mehr rein (eibd ist kein User Prozess) und Fedora schiebt sie jetzt nach /run (das ist aber nicht in der FHS definiert). In der FHS 2.3 steht zu /var/run "System programs that maintain transient UNIX-domain sockets must place them in this directory."

[makki]

Naja, ich mache hauptberuflich sowas ähnliches wie IT-Security

Für mich ist das ehrlichgesagt müssig (sogar der Thread-titel/inhalt ist eigentlich müssig!):
- 99% nutzen das als (sicherheitsfreies) KNXnet/IP-Gateway. Mit -i/-T/-R ist Polen offen, ebenso: der Webserver für jegliche Visu muss nun lesen&schreiben können.. Wieder Polen offen..
-> Mir mag nicht einleuchten, welchen Sinn es nun haben soll, angemeldete lokale User auszusperren, wo doch eh Hanni & Nanni im LAN tun und lassen können, was sie wollen?

Das nenne ich dann "Anwender ohne jegliche Not ärgern", z.B. mit Funktions-verhinderndern Rechten ("eibd should not run as root.."), die zwar vielleicht esotherisch richtiger wären aber in der Praxis einfach nur nervig

Das Sicherheitskonzept fürs WG ist übrigens daher ganz klar: vertrautes (trusted) LAN ohne AAA -> oder eben sauber-> vorhandenes VPN.

Mit dem FHS hast Du recht, theoretisch

Makki

[greentux]

Steht das mit dem "Sicherheitskonzept" irgendwo fett im Handbuch? Die Zielgruppe "Otto-Normal-User/Elektriker" sollte das ggf. wissen. Was in die eine Richtung geht, geht ja ggf. auch in die andere. Ich habe den eibd nicht analysiert, aber durchaus möglich, das man auch aus dem KNX lustige Sachen im IP-Netz machen kann.

[gramels]

Hallo zusammen,
ich habe mir am Wochenende mal Cometvisu und das DMX gateway installiert. Sehr schick, mit dem Farbkreis RGB LEDs zu steuern macht richtig Laune.
Als Denksportaufgabe hab ich dann angefangen zu überlegen, wie die geeignete (Sicherheits)architektur wäre, wenn man nun genau ein Farbkreis ins Internet stellen wollen würde um den Nachbarn die Freude zu machen damit rumzuspielen.
Habt ihr dazu Ideen?
1 CV Instanz mit eigenem eibd, den man auf genau 3 GAs einschränkt erscheint mir am sinnvollsten. Aber wie kann man den eibd einschränken?
Gibt es so was wie einen KNX firewall, der nur einzelne GAs durchlässt. Am sinnvollsten als Filterproxy.
Oder andere schlaue Ansätze?

Grüsse

Lothar

[makki]

Steht das mit dem "Sicherheitskonzept" irgendwo fett im Handbuch?

Nein, das ist IMHO auch nicht die Aufgabe eines 1-Wire-KNX-Gateways mit Visu, Lebenshilfe in grundlegenden Fragen zu geben (IP, warum sollte ich auf meiner Fritzbox keine Ports aus dem Internet weiterleten, wenn ich nicht weiss, was das bedeutet? uvm )

Das WG beschreibt eine empholene, vorinstallierte und saubere Lösung (OpenVPN) in der Online-Hilfe, ich rate seit Jahren davon ab etwas zu machen wo man die Auswirkungen nicht blickt, ehrlich, das muss reichen, darüber hinaus muss man halt wissen was man tut oder sich über empfehlungen hinwegsetzen, das kann und will ich keinem aufdoktrinieren, freie Menschen, freie Entscheidung

Und wenn es mir egal wäre, dann hätte ich diese Frage garnicht gestellt, nur so am Rande, die Problematik ist mir durchaus klar nur kann man aus sch*** auch nicht Gold machen

Hallo zusammen,
ich habe mir am Wochenende mal Cometvisu und das DMX gateway installiert. Sehr schick, mit dem Farbkreis RGB LEDs zu steuern macht richtig Laune.
Als Denksportaufgabe hab ich dann angefangen zu überlegen, wie die geeignete (Sicherheits)architektur wäre, wenn man nun genau ein Farbkreis ins Internet stellen wollen würde um den Nachbarn die Freude zu machen damit rumzuspielen.
Habt ihr dazu Ideen?
1 CV Instanz mit eigenem eibd, den man auf genau 3 GAs einschränkt erscheint mir am sinnvollsten. Aber wie kann man den eibd einschränken?
Gibt es so was wie einen KNX firewall, der nur einzelne GAs durchlässt. Am sinnvollsten als Filterproxy.
Oder andere schlaue Ansätze?

Garnicht (erstmal). erstmal eine passende AAA auf den Webserver setzen (Google kan das besser als ich erklären), dem eib(d) sind alle drei AAA's die man in der IT kennt fremd, das ist zwar sicher nicht perfekt aber nunmal so.
Wir müssen das beste daraus machen, wer nachhaltig etwas ändern will soll sich bitte an der KNXnet/IP WG bei der Konnex beteiligen, ich wär dabei

Makki

[greentux]

Ja nun, an einem Hinweis im Handbuch ist noch niemand umgekommen.
"Beachten Sie bitte, das Sie mit der Installation des Wiregate eine Kopplung ihres KNX Netzes mit dem IP-Netz realisieren. Das KNX Netz bietet keinerlei Sicherheitsmechanismen. Fragen Sie Ihren Arzt oder Apotheker, blah blub".

[EPIX]

und net vergessen den wichtigen Hinweis "Das Hineinbohren mit dem Finger kann ihre Sehkraft beeinträchtigen"....

Im Ernst: man "kann" es auch übertreiben - nachdem KNX gewisse FACHkenntnisse voraussetzt kann man schon davon ausgehen das "man" sich auch über die Sicherheitsthemen informiert hat.
Als Steuerung für eine Raketenabschussrampe oder Atomanlage wird wohl eh keiner KNX als Steuerungssystem einsetzen...

[greentux]

Alles Produkthaftungsspezialisten hier. Prima

[ctr]

Im Ernst: man "kann" es auch übertreiben - nachdem KNX gewisse FACHkenntnisse voraussetzt kann man schon davon ausgehen das "man" sich auch über die Sicherheitsthemen informiert hat.

Das glaubst Du doch nicht selber oder? Hier prallen zwei Welten aufeinander.

Der klassische EIB-Eli (oder wer verkauft/installiert Endkunden Homeserver und Wiregates?) wird in den seltensten Fällen (Ausnahmen bestätigen natürlich die Regel!) das nötige IP-Know-How haben. Klassischer Fall: Hauptsache es geht https://knx-user-forum.de/knx-eib-fo...nd-dyndns.html
Und ein Endbenutzer der sich das Wiregate selbst kauft ist eben ein Endbenutzer und nach manchen Fragen im WG-Support-Forum würde ich da auch nicht bei deutlich mehr als 50% der Nutzer schätzen, dass sie die (alle) Implikationen verstehen die sich da ergeben wenn man die beiden Welten miteinander verbindet.

[EPIX]

ich glaub NICHT, dass man über das KNX-Netz des LAN "hacken" kann...

Daher der scherzhafte Zugang