Kris on Nostr: CVS Schwemme und Kasperkram ...
CVS Schwemme und Kasperkram
https://www.heise.de/news/Linux-Kritik-Gruende-und-Folgen-der-CVE-Schwemme-im-Kernel-9963793.html
Jetzt gibt es endlich die von vielen Leuten in Unkenntnis der Sachlage geforderten Kernel-CVEs und das ist nun auch wieder nicht recht. Jedenfalls ist "Linux" nun eine NA (eine Nummernvergabestelle) und macht davon dann auch reichlich Gebrauch.
Wie sehen zwei DInge:
Die meisten Leute haben keine Ahnung, wie CVEs zu bewerten sind, im Kontext ihrer eigenen Anwendung und können nicht einmal feststellen, ob der betreffende Code bei ihnen irgendwo verwendet wird. Inventories sind schlecht, oder grob (nicht für modulare Software oder Kernels geeignet). Tooling dafür fehlt.
Das ist ein klassischer Fall von "Never check for an error condition you don't know to handle", hier: Checken ob eine CVE überhaupt zutreffend für den eigenen Einsatz ist.
Und
Die meisten Leute haben kein sinnvolles Deployment Modell. "Kein Rechner hat mehr als 30 Tage uptime, wir reinstallieren jede Kiste reihum, ohne Betriebsunterbrechung, mit aktueller und getesteter Software" ist als Operations-Ziel für die meisten Firmen nicht erreichbar.
Das ist so, weil die Operations unzureichend automatisiert sind, und Tests und Zulassungen unzureichend automatisiert sind. Dadurch werden Updates zu Projekten, statt Bestandteil des operativen Prozesses zu werden.
Das ist doppelt schlecht, weil Security als Projekt unmöglich ist, sondern in jedem Fall eine Komponente des normalen operativen Prozesses sein muß.
Und wenn ich
Das Thema Live-Patching wurde nur gestreift, denn auch dort gibt es noch offene Fragen. Damit alle oder zumindest einen größeren Batzen der CVE-Fixes zur Laufzeit einzuspielen, wäre vielleicht theoretisch denkbar, in der Praxis aber schwer zu realisieren: Das Erstellen und Verifizieren solch komplexer Live-Patches ist dazu zu arbeits- und zeitintensiv. Letztlich dürfte es dadurch vermutlich gelingen, Reboots einige Wochen zu vermeiden, aber nicht viele Monate.
lese, dann bekomme ich einen Hals.
Live-Patching ist unendlich komplex: Du willst neuen Code in einen laufenden Kernel einführen, wo alte Datenstrukturen vom alten Code im Speicher stehen. Der neue Code muß dann mit diesen bestehenden, durch alten Code erschaffenen Datenstrukturen (und Alignments und allem) weiter laufen.
Wenn Du ein System hast, daß so wichtig und so SPOF ist, daß Du es nicht rebooten kannst, dann kannst Du es auch nicht Live-Patchen, WEIL DAS RISIKO DABEI ZU VERKACKEN NOCH VIEL GRÖSSER IST.
Live-Patches sind schwierig, faktisch nicht zu testen und keine Lösung – Du musst am Ende ja doch das Upgrade einspielen und dann booten. Live-Patches sind eine Verschwendung von Developer-Zeit und Operations-Schlangenöl.
Tut das nicht.
Professionalisiert Eure Prozesse.
Einzelne Kisten müssen egal sein. Sind sie es nicht, hätte es nie so gebaut werden dürfen.
https://www.heise.de/news/Linux-Kritik-Gruende-und-Folgen-der-CVE-Schwemme-im-Kernel-9963793.html
Jetzt gibt es endlich die von vielen Leuten in Unkenntnis der Sachlage geforderten Kernel-CVEs und das ist nun auch wieder nicht recht. Jedenfalls ist "Linux" nun eine NA (eine Nummernvergabestelle) und macht davon dann auch reichlich Gebrauch.
Wie sehen zwei DInge:
Die meisten Leute haben keine Ahnung, wie CVEs zu bewerten sind, im Kontext ihrer eigenen Anwendung und können nicht einmal feststellen, ob der betreffende Code bei ihnen irgendwo verwendet wird. Inventories sind schlecht, oder grob (nicht für modulare Software oder Kernels geeignet). Tooling dafür fehlt.
Das ist ein klassischer Fall von "Never check for an error condition you don't know to handle", hier: Checken ob eine CVE überhaupt zutreffend für den eigenen Einsatz ist.
Und
Die meisten Leute haben kein sinnvolles Deployment Modell. "Kein Rechner hat mehr als 30 Tage uptime, wir reinstallieren jede Kiste reihum, ohne Betriebsunterbrechung, mit aktueller und getesteter Software" ist als Operations-Ziel für die meisten Firmen nicht erreichbar.
Das ist so, weil die Operations unzureichend automatisiert sind, und Tests und Zulassungen unzureichend automatisiert sind. Dadurch werden Updates zu Projekten, statt Bestandteil des operativen Prozesses zu werden.
Das ist doppelt schlecht, weil Security als Projekt unmöglich ist, sondern in jedem Fall eine Komponente des normalen operativen Prozesses sein muß.
Und wenn ich
Das Thema Live-Patching wurde nur gestreift, denn auch dort gibt es noch offene Fragen. Damit alle oder zumindest einen größeren Batzen der CVE-Fixes zur Laufzeit einzuspielen, wäre vielleicht theoretisch denkbar, in der Praxis aber schwer zu realisieren: Das Erstellen und Verifizieren solch komplexer Live-Patches ist dazu zu arbeits- und zeitintensiv. Letztlich dürfte es dadurch vermutlich gelingen, Reboots einige Wochen zu vermeiden, aber nicht viele Monate.
lese, dann bekomme ich einen Hals.
Live-Patching ist unendlich komplex: Du willst neuen Code in einen laufenden Kernel einführen, wo alte Datenstrukturen vom alten Code im Speicher stehen. Der neue Code muß dann mit diesen bestehenden, durch alten Code erschaffenen Datenstrukturen (und Alignments und allem) weiter laufen.
Wenn Du ein System hast, daß so wichtig und so SPOF ist, daß Du es nicht rebooten kannst, dann kannst Du es auch nicht Live-Patchen, WEIL DAS RISIKO DABEI ZU VERKACKEN NOCH VIEL GRÖSSER IST.
Live-Patches sind schwierig, faktisch nicht zu testen und keine Lösung – Du musst am Ende ja doch das Upgrade einspielen und dann booten. Live-Patches sind eine Verschwendung von Developer-Zeit und Operations-Schlangenöl.
Tut das nicht.
Professionalisiert Eure Prozesse.
Einzelne Kisten müssen egal sein. Sind sie es nicht, hätte es nie so gebaut werden dürfen.