[MartinRinas]

Introduce a new URL display theme for Raspberry Pi, enabling users to connect to a specified URL.

[MartinRinas]

Raspberry Pi 3 Model B Plus Rev 1.3

[benderl]

Kurzes Update:
Wegen der Systemlast prüfen wir noch, in wie weit sich das überwachen lässt und ggf. der Chromium beendet werden kann.

Was aber definitiv noch anzupassen ist: es dürfen nur URLs mit einer IP aus einem nicht öffentlichen Subnetz eingegeben werden. Hintergrund ist einfach, dass man seine openWB und potentiell das gesamt Heimnetz nicht durch eine "böse" Webseite kompromittieren kann.

Die Prüfung des Subnetz müsste an mehreren Stellen durchgeführt werden:

• bei der Eingabe der URL im Frontend
• im Display-Theme Modul bei der Instantiierung inkl. Entfernung der nicht zugelassenen URL
• optional eine zusätzliche Prüfung im Frontend des Display-Themes, sollte aber nicht notwendig sein, wenn das Modul ordentlich validiert

Kannst Du das so integrieren oder benötigst Du dafür Hilfe?

[MartinRinas]

klar, eine Validierung einzubauen ist sicher nicht so arg schwer. Ich schau' mal was mir das System vorschlägt.

Wobei mir der konkrete Angriffsvektor nicht klar ist. Um eine kompromittierte URL hinterlegen zu können muss der Angreifer ja bereits kontrolle über das System haben, also ein post-compromise. Angenommen das ist der Fall und es wird eine andere URL hinterlegt, wie genau würde der Angriffsvektor dann aussehen? Auf dem Display wird eine andere URL dargestellt, welches weitere Risiko geht davon aus? Es wird ja kaum jemand Zugangsdaten übers Display eingeben. Und Chromium sollte hinreichend abgesichert sein dass durch die reine Anzeige einer URL keine weitere Kompromittierung des Systems erfolgen kann, zumal es ja bereits eine Kompromittierung gegeben haben muss um in den Zustand zu kommen.

Zum Thema Systemlast, gibts vergleichswerte von den Display Themes welche mit der openWB kommen, wie hoch ist die Last dort? Kann man das Problem durch Anpassung der Prozessprioritäten für Chromium und Python Regelschleife nicht anpassen? So würde die Regelschleife immer genug CPU Zyklen bekommen, selbst wenn Chromium am Rad dreht.

[benderl]

Der Angriffsvektor ist einfach der potentiell veraltete, ungepatchte Chromium Browser. Wenn jemand die URL eines "super tollen Portals", was ihm irgend einen immensen Vorteil verspricht, einträgt und der Betreiber dieses "Portals" sich durch bekannte Schwachstellen auf der openWB einnistet, haben wir ein Problem.

Hauptanwendungsfall ist eine lokale URL von EVCC oder was auch immer die secondary ansteuert. Dann sollten wir es auch so beschränken, um nicht Tür und Tor zu öffnen.

[benderl]

Zum Thema Systemlast, gibts vergleichswerte von den Display Themes welche mit der openWB kommen, wie hoch ist die Last dort? Kann man das Problem durch Anpassung der Prozessprioritäten für Chromium und Python Regelschleife nicht anpassen? So würde die Regelschleife immer genug CPU Zyklen bekommen, selbst wenn Chromium am Rad dreht.

Die Animation im Energiefluss sorgt für eine Auslastung von ca. 90-100% (verteilt auf mehrere Cores). Die Load liegt bei meinem Testsystem ohne Ladepunkte, dafür Simulator, bei etwa 2. Ist demnach zum EVCC bei Dir auch kein großer Unterschied.

[Patrick-Remy]

@MartinRinas danke für deine Arbeit für dieses Festure, ich habe exakt den selben Anwendungsfall mit evcc und openWB und den selben Wunsch seit ein paar Monaten im Kopf.

Ich war gerade dabei mich in den openWB Quellcode einzuarbeiten, als ich den PR gefunden habe.
Würdest du wie vom Team gewünscht noch eine Validierung auf IP-only und lokale Subnetze hinzufügen?
Wobei es ehrlicherweise auch keine echte Sicherheit gibt, da man auch eine lokale IP ansteuern kann, die einen Proxy beherbergt. Daher wäre ich persönlich eher für einen deutlichen Warnhinweis, dass ausschließlich Websites eingebunden werden sollte, denen vertraut wird. Zuzüglich könnte man an der selben Stelle auch darauf hinweisen, dass die Performanceeinschränkungen berücksichtigt werden müssen.

Dann könnte ich nach einem Merge auch über den Entwicklungszweig von meinen Erfahrungen hinsichtlich Stabilität und Performance auf dem eingebauten Pi der OpenWB Pro berichten.

Vielleicht wäre es auch möglich dem Chromium Prozess über "nice" o.Ä. eine geringe Priorität zuzuweisen.

[kevinwieland]

Kurzes Update: Wegen der Systemlast prüfen wir noch, in wie weit sich das überwachen lässt und ggf. der Chromium beendet werden kann.

Was aber definitiv noch anzupassen ist: es dürfen nur URLs mit einer IP aus einem nicht öffentlichen Subnetz eingegeben werden. Hintergrund ist einfach, dass man seine openWB und potentiell das gesamt Heimnetz nicht durch eine "böse" Webseite kompromittieren kann.

Die Prüfung des Subnetz müsste an mehreren Stellen durchgeführt werden:

• bei der Eingabe der URL im Frontend
• im Display-Theme Modul bei der Instantiierung inkl. Entfernung der nicht zugelassenen URL
• optional eine zusätzliche Prüfung im Frontend des Display-Themes, sollte aber nicht notwendig sein, wenn das Modul ordentlich validiert

Kannst Du das so integrieren oder benötigst Du dafür Hilfe?

@MartinRinas
Kannst du das noch machen? Das ist der blocking point für den Merge

[MartinRinas]

@kevinwieland ah ja, das ist sozusagen aus meinem Kontex-Fenster gefallen. Schau' ich mir gern noch an, wird aber vermutlich Anfang September werden.

[MartinRinas]

ungültige Werte werden nun durch das Backend verweigert:

[MartinRinas]

@kevinwieland Die Validierung ist implementiert und funktioniert. UI Changes habe ich auch erstellt, einschließlich der Möglichkeit in der secondary ein anderes Theme auszuwählen. Das ist in der Betriebsart als nur secondary (z.b. Steuerung durch andere externe Systeme wie evcc) notwendig.

[Kai9555]

Wird es der PR noch in die Alpha schaffen?

[Kai9555]

Hab den PR mal bei mir installiert, openWB als Secondary mit evcc. Läuft soweit.

Auf meinem älteren Image (Bullseye) war noch Chromium 106 drauf, damit blieb die evcc-Seite komplett weiß. Nach dem Wechsel auf chromium-browser 126 aus dem Raspberry-Pi-Repo wird sie korrekt angezeigt. Außerdem fehlten die Emojis in evcc, bis ich fonts-noto-color-emoji installiert hab.

Ich lass es jetzt mal eine Weile laufen und kann dann gern nochmal berichten.

Nachtrag: evcc nutzt als Trennpunkt den japanischen Mittelpunkt (U+30FB), der wurde nur als Kästchen angezeigt. Mit fonts-ipafont-gothic passt das jetzt auch.

[Patrick-Remy]

Ich habe seit ungefähr Juli evcc über das integrierte Display am laufen und funktioniert wunderbar. Tatsächlich habe ich aber auch noch dem Chromium einen höheren nice Wert gegeben.
Alle paar Monate hängt sich der Chromium oder Raspi auf, das ist mir aber davor mit der Koala UI auch passiert.

[Kai9555]

In evcc auf dem Display der openWB standen zwischendurch Warnungen wie "Tesla Model Y: charge power: read tcp 192.168.2.117:49824 (ivcc) ->192.168.2.84:1502: i/o timeout (openWB)". Kann auch noch von den Neustarts gewesen sein, so genau weiß ich das nicht mehr. Zur Sicherheit läuft Chromium jetzt aber mit nice 10, seitdem alles unauffällig.

Was mich noch genervt hat: Wenn das Display nach 60 s in den Standby geht, löst der Tipp zum Aufwecken direkt was in evcc aus. Hab mir ein kleines Skript gebaut, das den ersten Touch im Standby abfängt, jetzt weckt der nur noch auf und es kann nicht mehr versehentlich etwas aktiviert werden.