iobroker.securitycheck --- Brainstorming
-
Und dann wär noch zu klären wer denn die User bei einem Alarm betreuen / beraten will ...
Ich Denke das ist Schritt drei, Schritt eins sollte sein Installation blocken, Schritt zwei betroffene Pakete löschen und weitere Maßnahmen.
Allerdings ist das ein erheblicher Aufwand und bedarf permanenter und Zeit naher Betreuung des entsprechenden Moduls.
So etwas mit rein zu nehmen macht m.E. Sinn, wenn möglich sollte hier aber auf eine Lösung gesetzt werden die Eigenständig ist und von mehreren Projekten genutzt wird.Und dann wär noch zu klären wer denn die User bei einem Alarm betreuen / beraten will ...
Ich Denke das ist Schritt drei, Schritt eins sollte sein Installation blocken, Schritt zwei betroffene Pakete löschen und weitere Maßnahmen.
Allerdings ist das ein erheblicher Aufwand und bedarf permanenter und Zeit naher Betreuung des entsprechenden Moduls.
So etwas mit rein zu nehmen macht m.E. Sinn, wenn möglich sollte hier aber auf eine Lösung gesetzt werden die Eigenständig ist und von mehreren Projekten genutzt wird.Installation blocken wird schwer - dazu müsstest du npm ändern...
Es geht ja nicht drum den Adapter @1.2.3 zu blocken sondern um dependencies. Und die bewertet ioBroker nicht. Die Auflösung erfolgt durch npm. ioBroker setzt nur 'npm i adapter@xxx' ab - alles andere erledigt npm. Da kann ioBroker also kaum was blocken.Löschen von Paketen wär auch hoch riskant. Das wär ein schönen DOS Tool. Ich würde dringend davon abraten einfach mal so Löschaktionen zentral auszulösen. Außerdem hätte das z.B. beim letzten Axios genau nix geholfen - außer das User nicht mehr gesehen hätten dass das schadhafte Paket installiert war.
Denkbar ist m.E. nur eine Warnfunktion. Alles andere stufe ich als riskant ein. Da würde ioBroker selbst ggF zu einer Schadensquelle.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer 'nen Kaffee spendieren will: https://paypal.me
-
Und dann wär noch zu klären wer denn die User bei einem Alarm betreuen / beraten will ...
Ich Denke das ist Schritt drei, Schritt eins sollte sein Installation blocken, Schritt zwei betroffene Pakete löschen und weitere Maßnahmen.
Allerdings ist das ein erheblicher Aufwand und bedarf permanenter und Zeit naher Betreuung des entsprechenden Moduls.
So etwas mit rein zu nehmen macht m.E. Sinn, wenn möglich sollte hier aber auf eine Lösung gesetzt werden die Eigenständig ist und von mehreren Projekten genutzt wird.Installation blocken wird schwer - dazu müsstest du npm ändern...
Es geht ja nicht drum den Adapter @1.2.3 zu blocken sondern um dependencies. Und die bewertet ioBroker nicht. Die Auflösung erfolgt durch npm. ioBroker setzt nur 'npm i adapter@xxx' ab - alles andere erledigt npm. Da kann ioBroker also kaum was blocken.Löschen von Paketen wär auch hoch riskant. Das wär ein schönen DOS Tool. Ich würde dringend davon abraten einfach mal so Löschaktionen zentral auszulösen. Außerdem hätte das z.B. beim letzten Axios genau nix geholfen - außer das User nicht mehr gesehen hätten dass das schadhafte Paket installiert war.
Denkbar ist m.E. nur eine Warnfunktion. Alles andere stufe ich als riskant ein. Da würde ioBroker selbst ggF zu einer Schadensquelle.
Ich hab gerade nochmal geschaut. Also nach meinem Dafürhalten sollte der in
iob diagintegrierte Test:
https://github.com/nodejs/is-my-node-vulnerable
auch sowas wie die axios-Geschichte abdecken. Es wird tagesaktuell die CVS-Datenbank abgefragt:This directory contains two lists of disclosed vulnerabilities:
core: Vulnerabilities affecting Node.js core npm: Vulnerabilities affecting third party modulesMit third party modules müsste dann ja auch z.B. axios und damals color oder wie das manipulierte Modul auch noch gleich hieß mitgefangen werden. Sollte man das nicht auch in den admin implementieren und alle 24 oder 48 Stunden ausführen lassen? Ausgabe dann im Log.
-
In letzter Zeit kam es ja schon häufiger vor, das u.a. npm Pakete korumpiert waren oder erst vor kurzem auch axios https://forum.iobroker.net/topic/84185/axios-kompromittiert
Wäre es möglich, solche Prüfungen z.B. auch über den Adapter laufen zu lassen? Vielleicht könnte man ja eine zentrale Datei auf github ablegen, welche als Quelle vom Adapter bei der Prüfung eingelesen wird? Auf diese Weise wäre dann eine Erkennung von korumpierten Pakete auch möglich, ohne das der User ein Adapter Update ausführen muss.
Die richtige Stelle wäre eigentlich der folgende Befehl
https://docs.npmjs.com/cli/v9/commands/npm-audit
Nach dem ersten größeren SupplyChain Attacks hatte ich da mal reingeschaut, allerdings ist das nix was ein Nutzer wirklich richtig interpretieren kann bzw. steht da auch viel drin, das momentan aktzepabel wäre.
das ist eine Ausgabe einer relativ aktuellen Testinstallation
Auf der Konsole sind dann noch ein paar extra Farben mit dabei, die das einfacher zum lesen macht.
Alternativ kann man sich das auch als JSON ausgeben lassen bzw. die Meldungen vorfiltern.Das sind die möglichen Severities
null, "info", "low", "moderate", "high", "critical", or "none"Wie ihr seht sind da einige Severity=high dabei. Wäre das dann schon kritisch um eine Installation abzubrechen? Wahrscheinlich nicht.
Es gibt 2 criticals, aber wer bewertet, ob dann die Installation abgebrochen werden soll. ggfs blockiert der Fehler dann auch längers den Update, da der maintainer das einfach nicht fixen will.
Nur soviel dazu, das man wahrscheinlich nix extra erfinden muss, weil es schon da ist.
Ggfs kann man auch mal bei anderen großen js/node Projekten schauen, bei denen viel mit Adapter/Plugins/etc. nachladbarer Funktionalität gearbeitet wird
(obwohl es betrifft ja auch sub und sub/sub dependencies, bei denen sich ein Problem einstellen kann) -
Die richtige Stelle wäre eigentlich der folgende Befehl
https://docs.npmjs.com/cli/v9/commands/npm-audit
Nach dem ersten größeren SupplyChain Attacks hatte ich da mal reingeschaut, allerdings ist das nix was ein Nutzer wirklich richtig interpretieren kann bzw. steht da auch viel drin, das momentan aktzepabel wäre.
das ist eine Ausgabe einer relativ aktuellen Testinstallation
Auf der Konsole sind dann noch ein paar extra Farben mit dabei, die das einfacher zum lesen macht.
Alternativ kann man sich das auch als JSON ausgeben lassen bzw. die Meldungen vorfiltern.Das sind die möglichen Severities
null, "info", "low", "moderate", "high", "critical", or "none"Wie ihr seht sind da einige Severity=high dabei. Wäre das dann schon kritisch um eine Installation abzubrechen? Wahrscheinlich nicht.
Es gibt 2 criticals, aber wer bewertet, ob dann die Installation abgebrochen werden soll. ggfs blockiert der Fehler dann auch längers den Update, da der maintainer das einfach nicht fixen will.
Nur soviel dazu, das man wahrscheinlich nix extra erfinden muss, weil es schon da ist.
Ggfs kann man auch mal bei anderen großen js/node Projekten schauen, bei denen viel mit Adapter/Plugins/etc. nachladbarer Funktionalität gearbeitet wird
(obwohl es betrifft ja auch sub und sub/sub dependencies, bei denen sich ein Problem einstellen kann)Die Ausgabe von npm audit verleitet allerdings sehr schnell dazu dann da per npm audit fix --force das ganze Ding in die Binsen zu hauen.
-
Die Ausgabe von npm audit verleitet allerdings sehr schnell dazu dann da per npm audit fix --force das ganze Ding in die Binsen zu hauen.
Wenn dann wäre es die Quelle für eine Funktion die dann Infos ausgibt bzw irgend ein Update dann blockiert
Hab ja geschrieben ein Nutzer kann das nicht wirklich auswerten. Auch ich tu mich da schwer.
-
Wenn dann wäre es die Quelle für eine Funktion die dann Infos ausgibt bzw irgend ein Update dann blockiert
Hab ja geschrieben ein Nutzer kann das nicht wirklich auswerten. Auch ich tu mich da schwer.
die KI hat auch nicht wirklich handhabbare Lösungen (meist solche die im business Umfeld eingesetzt werden, aber für ein OpenSource Projekt nicht wirklich handhabbar wäre, da zu aufwändig)
Auf npm Ebene wäre eigentlich auch so ein dependabot cooldown sinnvoll, das bei installtion nicht die pakete gezogen werden, die gerade eben erst aktualisiert wurden, sonder idealerweise mit einer Woche Verzögerung.
Dann gäbe es zumindest einen Puffer in der diese problematischen Pakete entdeckt werden können. Das erfolgte ja bisher immer recht schnell (hoffentlich, zumindest von denen wo man gehört hat)Nachtrag:
Das gibt es tatsächlich. npm install hat einen Parameter before
https://docs.npmjs.com/cli/v8/using-npm/config#before
Der sorgt dafür, das die dependencies so aufgelöst werden wie sie zu diesem Datum aufgelöst worden wären.
Darüber könnte man dann einen Puffer einführen.
Würde aber wahrscheinlich auch bedeuten, das neue Adapter versionen ebenfalls solange brauchen bis sie bei allen überhaupt ankommen. -
die KI hat auch nicht wirklich handhabbare Lösungen (meist solche die im business Umfeld eingesetzt werden, aber für ein OpenSource Projekt nicht wirklich handhabbar wäre, da zu aufwändig)
Auf npm Ebene wäre eigentlich auch so ein dependabot cooldown sinnvoll, das bei installtion nicht die pakete gezogen werden, die gerade eben erst aktualisiert wurden, sonder idealerweise mit einer Woche Verzögerung.
Dann gäbe es zumindest einen Puffer in der diese problematischen Pakete entdeckt werden können. Das erfolgte ja bisher immer recht schnell (hoffentlich, zumindest von denen wo man gehört hat)Nachtrag:
Das gibt es tatsächlich. npm install hat einen Parameter before
https://docs.npmjs.com/cli/v8/using-npm/config#before
Der sorgt dafür, das die dependencies so aufgelöst werden wie sie zu diesem Datum aufgelöst worden wären.
Darüber könnte man dann einen Puffer einführen.
Würde aber wahrscheinlich auch bedeuten, das neue Adapter versionen ebenfalls solange brauchen bis sie bei allen überhaupt ankommen.Wobei das halt auch Module ausbremst, die drigend gepatcht werden müssten. Außer du pflegst dann eine Whitelist.
-
Wobei das halt auch Module ausbremst, die drigend gepatcht werden müssten. Außer du pflegst dann eine Whitelist.
@Thomas-Braun
Da muss man halt dann auch abwägen was wichtiger ist
und wie groß der Pufferzeitraum ist (1 Tag, 1 Woche?)
Auch jetzt wird ja bei dringender Änderung nicht wirklich alles innerhalb kürzester Zeit aktualisiert. -
@Thomas-Braun
Da muss man halt dann auch abwägen was wichtiger ist
und wie groß der Pufferzeitraum ist (1 Tag, 1 Woche?)
Auch jetzt wird ja bei dringender Änderung nicht wirklich alles innerhalb kürzester Zeit aktualisiert.Auch jetzt wird ja bei dringender Änderung nicht wirklich alles innerhalb kürzester Zeit aktualisiert.
Das stimmt natürlch leider. Die 'never tatsch irgendwas'-Herangehensweise von einigen usern ist halt nicht kleinzukriegen.
-
ein großteil der benutzer sind auch keine systemadministratoren die oft sich um das system kümmern können/wollen.
müssen ggfs auch in der familie noch ein paar andere aufgaben administrieren -
ein großteil der benutzer sind auch keine systemadministratoren die oft sich um das system kümmern können/wollen.
müssen ggfs auch in der familie noch ein paar andere aufgaben administrierenRichtig. Aber es kann auch nicht sein, das die Kisten über Jahre nicht mehr angepackt werden.
Das hat auch nix mehr mit Systemadministrator oder nicht zu tun. Wenn du ein Computersystem aufsetzt und betreibst bist du dann auch der 'Systemadministrator' für den Hobel. Oder du stellst jemanden dafür ein, der dir die Aufgabe abnimmt. Macht natürlich privat keiner. Also musste da selber regelmäßig ran. Die Betonung auf regelmäßig, nicht zwingendermaßen sofort. -
Richtig. Aber es kann auch nicht sein, das die Kisten über Jahre nicht mehr angepackt werden.
Das hat auch nix mehr mit Systemadministrator oder nicht zu tun. Wenn du ein Computersystem aufsetzt und betreibst bist du dann auch der 'Systemadministrator' für den Hobel. Oder du stellst jemanden dafür ein, der dir die Aufgabe abnimmt. Macht natürlich privat keiner. Also musste da selber regelmäßig ran. Die Betonung auf regelmäßig, nicht zwingendermaßen sofort.das sind Wünsche aus der IT-Ecke.
In der Praxis sind viele Consumer-Geräte mit AutoUpdate ausgestattet.
Aber auch das ist aufwändig, da du alle konstellationen ständig testen musst, wenn
du nach einem update keine oder nur wenige elektronische backsteine produzieren willst.ich möchte nicht wissen welchen aufwand apple oder google betreibt um das mit den handys einigermaßen so hinzubekommen.
-
das sind Wünsche aus der IT-Ecke.
In der Praxis sind viele Consumer-Geräte mit AutoUpdate ausgestattet.
Aber auch das ist aufwändig, da du alle konstellationen ständig testen musst, wenn
du nach einem update keine oder nur wenige elektronische backsteine produzieren willst.ich möchte nicht wissen welchen aufwand apple oder google betreibt um das mit den handys einigermaßen so hinzubekommen.
das sind Wünsche aus der IT-Ecke.
Natürlich ist das Wunschdenken, ist mir auch klar.
In der Praxis sind viele Consumer-Geräte mit AutoUpdate ausgestattet.
Ja, mit den üblichen Dingen. Ich habe z. B. bewusst auf meinen Kisten kein AutoUpdate konfiguriert, ich sehe gerne was sich da ändert und spiele das dann bewusst ein. Dann hab ich auch eine Chance zu sehen bei welchem Update es vielleicht haken könnte. Klar, kann auch nicht jeder. Aber dann aus der Unsicherheit heraus lieber gar nichts zu machen ist halt auch falsch und führt dann zu diesen oft hoffnungslos abgesoffenen, 'never getatschten' Wracks.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden627
Online32.8k
Benutzer82.7k
Themen1.3m
Beiträge