TuxTape - Új Linux kernel livepatch megoldást fejleszt egy amerikai biztosító cég

Címkék

Ugyan évek óta számos livepatch-elő megoldás érhető el a Linux kernelhez, a GEICO nevű, amerikai biztosítási vállalat úgy döntött, hogy újat fejleszt TuxTape néven. A terméket pedig hamarosan elérhetővé teszi nyílt forráskódú licenc alatt.

Részletek itt.

Hozzászólások

Szerkesztve: 2025. 02. 04., k – 15:15

trey@alderaan:~$ canonical-livepatch status
last check: 12 minutes ago
kernel: 5.15.0-130.140-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.15 is covered by Livepatch
patch state: ✓ no livepatches available for kernel 5.15.0-130.140-generic
tier: updates (Free usage; This machine beta tests new patches.)
machine id: df28cf4e310d4fxxxxxxxxxxxxxxxxxxxx
 

🤔 🤷‍♂️

trey @ gépház

> Red Hat's Kpatch, Oracle's Ksplice, and SUSE's kGraft are the most well known solutions currently for Linux kernel live-patching

A canonical-livepatchot nem jegyzik? 

Az ilyen livepatch rendszerekről az jut az eszembe, hogy micsoda szívás lenne, ha feltörik ezt a rendszert és az összes érintett szerverre feltelepítenek valamilyen trójait vagy más kártékony kódot. Mi a biztosíték, hogy ez  nem történik meg?

Sakk-matt,
KaTT :)

Visszatértem! A hozzászólásom alatt lévő szavazat gomb nem nyomódik meg magától!

Ez sajnos ilyen műfaj, az extra kényelem mindig a biztonság rovására megy. Bár szerintem meg tudják oldani, ahogy a nem livepatch-es kernelt tartalmazó tükrökben, csomagkezelőkben, hogy a feltelepített csomag megfelelően alá legyen írva, és esetleg még reprodukálható is legyen, disznóságokat, hekkelés belerondításokat megelőzendő.

Nem vagyok a livepatch-nek ellene, mert szerveren valóban jogos igény, hogy ne legyen sok leállási idő mindenféle újraindulgatás miatt. Desktopon viszont nem sok értelme van, mai SSD-s, sok giga RAM-os, sok CPU magos rendszeren pár másodperc egy új boot, és akkor teljesen tiszta lappal, tiszta memóriaállapottal, újrainicializált hardverrel indul a rendszer, sok bugot ki lehet így kerülni.

The world runs on Excel spreadsheets. (Dylan Beattie)

Az is megoldható, nem is kell hozzá feltétlen sleep vagy hibernáció sem. Egy csomó DE tud sessiont kezelni, visszatölteni azokat a programokat, amik nyitva voltak, és alkalmazások is tudnak a komolyabbak közül saját munkamenetet kezelni, visszanyitni azokat a füleket, projekteket, amelyek nyitva voltak. 1-1 ilyennek a visszahozása alig pár extra másodperc összesen. Még mindig nem az a tétel, amihez live kernelpatch-csel kéne trükközni, hogy ne legyen újraindítás.

Ettől az újraindítástól nem kell félni, utoljára a HDD-korszakban volt probléma. Meg szerveren, de ott sem a bootidő feltétlen hosszabb, hanem a UEFI inicializáció, hardveres öntesztek hosszúak, maga az OS gyorsan bebootol azon is, hanem utána a rajta futó szolgáltatások azok még, amiknek esetleg kicsit tovább tart, mire talpraállnak.

Ami engem ebben a hírben meglep, hogy biztosítóról van szó. Annak mi köze a Linuxhoz? Minimum fura.

The world runs on Excel spreadsheets. (Dylan Beattie)

Próbáltam régen is, most megint teszteltem.
Plasma6 KDE Session Restore.On last logout bejelölve.
Amit visszanyitott alkalmazást azt mindet egy activitire ott az első desktopra és a default képernyőre. Ennek nem sok értelme van. Igazán megjegyezhetné hol voltak elhelyezve. Amúgy ha jól emlékszem a vscode régen nem nyílt vissza. Most visszanyílt pár üres viszont egy részük megőrizte a munkamenetet is. Ez fejlődés, de amíg nem teszi ugyanoda ahol voltak értelmetlen feature. 

A docker konténereket meg a saját szkripttel elindíthatod bejelentkezés után, automatikusan, valami autorun, xinit, init service, systemd job, shellrc, vagy hasonló megoldásba beteszed. A tmux-nak utána kell nézzek, hogy az rebootok között helyreállítható-e. Szerk: a tmux session sem helyreállítható reboot után, nem menthető. Előre scriptelhető, de egy meglévőt menteni nem lehet.

Az SSH session az jogos, azt valóban csak a hibernáció/sleep állíthatja vissza, az reboot után bukta, mindenkinek újra kell kapcsolódnia. Ez értelemszerű, ha SSH-ra van használva az már szerverkategória, azt nem indítgatod újra passzióból. Amit írtam, azt a desktop felhasználásról írtam, meg a hagyományos session helyreállításáról, amit DE/WM-ek tudnak, meg egyes programok (IDE-k). Azok nagyrészt pótolják, amit a hibernálás/sleep csinál.

Én már csak azért sem használok ilyet, meg épp ezért nagyon automata indulásra se teszek be érdemi felhasználói programot (a rendszerbeállítást, desktop setup-ot végző programok azok kivételek, mert azoknak el kell induljanak), mert nekem a rendszerrel ne induljon olyan, amit ebben a session-ben lehet nem is fogok használni, minek töltögessen vissza, meg indítgasson olyan szart, ami lehet nem is kell. Mert oké, ment, amikor sleep-be tettem, de következőleg nem biztosan fog kelleni, minek fusson akkor egy csomó múltbeli sallang, halálra idegesítene. Csak az fusson, ami tényleg használok, de azt nem látom előre, mindig az aktuális kedvem, időm, a nap, munka témája határozza meg, hogy mi fog futni. Akkor tényleg az isten RAM-ja, meg procimagja se elég, ha az ember élből futva hagy minden szart, akár két héttel ezelőttről is visszamaradva, olyan jeligére, hogy egyszer kellett valamire.

Már a fülek is idegesítenek a böngészős session helyreállításánál, de azokat muszájból használom, mert ha kint vannak a szokásosan használt fülek, akkor látom, hogy mivel kell foglalkozni, nem fogom elfelejteni, hogy mikre akartam visszatérni.

The world runs on Excel spreadsheets. (Dylan Beattie)

Értem (asszem), hogy a livepatch lényege az üzletfolytonosság fenntartása és a hibák gyorsabb befoltozása, de ennek tényleg ilyen nagy jelentősége van a felhős szolgáltatások, Kubernetes, sokféle HA rendszer korában?

Tényleg van olyan felhasználó, akinek valami annyira fontos, hogy egy újraindítást sem bír ki a szolgáltatás, de nincs lehetőség redundáns megoldás bevezetésére, ami egy node kiesését elbírja?

Vagy van olyan ITsec elvárási szint, amikor mindenképp azonnal telepíteni kell egy kernel patch-et egyszerre az összes node-ra, nem lehet ütemezetten, egymás után?

Ár-érték viszonyban egy support mániás cégnek az 1-2U méretű 2 socket-es, sok memóriával megáldott gépek valók. Csakhogy a hardver minimális kapacitása (brand szerver világ) kezd egy átlag középvállalat számára nagy lenni. Ugye egy node nem node, veszel rögtön hármat. De akkor meg hülye állapotba kerül a klaszter ha ezen fut minden kontroll funkció is és kiesik egy, így rögtön plusz 2, az már 5. Annyi meg ugye felesleges, tehát elkezded levenni a redundanciát, de ekkor goto hülye állapot ha megáll, így nem állhat meg. Ugye milyen jó a live patch? 

Hint: amúgy egyetértek veled, nálam is instant red flag ha felmerül ilyen igény.

de ennek tényleg ilyen nagy jelentősége van a felhős szolgáltatások, Kubernetes, sokféle HA rendszer korában?

Mit segítenek ezek, ha nincs hivatalos javítás? Ez arra való, hogy napvilágot lát egy 0day kernelsebezhetőség, de még nincs rá hivatalos javítás (patch -> mainline kernelkiadás -> disztribútor -> disztribútor csomagja -> végfelhasználó -> javított rendszer), addig gyorsan a disztribútor ki tud tolni olyan workaround-ot, ami pillanatok alatt szétterül (disztribútor livepatch-e -> ügyfél rendszerei) és reboot nélkül biztosítja a rendszerek ideiglenes védelmét addig, amíg a megfelelő javítás el nem készül.

De, te is készíthetsz ilyen livepatchet a rendszeredhez a hivatalos javítás megérkezéséig. Minek deployolnál többször, minek rebootolnál többször, minek költöztetnél node-ról node-ra többször?

Az automatikus livepatcheléssel a sebezhetőségi ablakot tudod lecsökkenteni. Egy 0day esetén, lehet, hogy te Európában még alszol, amikor a livepatch már véd, mire reggel bemész és elolvasod, hogy létezik egyáltalán ilyen sérülékenység. Hol van itt még a részedről a reagálás? Sehol.

trey @ gépház

Teljesen más a koncepció. Az

  • egy 3rd party termék
    • ez a disztribútor sajátja
  • az egy komplett programcsomag
    • ez egy atomikus, sebészi pontossággal csak arra a problémára megírt workaround
  • azt nem lehetett eltávolítani központilag, kézzel kellett
    • ez egy esetleges működésbeli probléma esetén újraindítással megoldható

trey @ gépház

El tudok képzelni ilyent annak ellenére, hogy nem kellett soha ilyennel dolgoznom. Ahogy írtam is, nyilván van olyan ITsec elvárás, ahol a lehető leghamarabb kell reagálni 0day hibára.

Azt nem tudom elképzelni, hogy annyi ilyen rendszer van (support szerződéssel való ledefés nélkül), hogy megéri egy újabb livepatch megoldást kifejleszteni az eddigiek mellé. Ráadásul ez nem csak szoftveres/műszaki kérdés, hanem bizalmi is. Mert hiába lesz mondjuk open source megoldás, ki és milyen alapon fog megbízni az ezen a csatornához kiadott javításokban?

nyilván van olyan ITsec elvárás, ahol a lehető leghamarabb kell reagálni 0day hibára

Nem van olyan, hanem ez az elvárás. A SoC-okat nem azért üzemeltetik milliókért cégek, hogy eső után köpönyeg reagáljanak, hanem még az incidens bekövetkezése előtt észleljék és reagáljanak. Ez nyilván egy 0day esetén nem a javítást fogja jelenteni, mert nincs hivatalos javítás, hanem egy proaktív megelőzést, workaround-ot. Ennek lehet része a livepatch.

Azt nem tudom elképzelni, hogy annyi ilyen rendszer van

Erről szól a cikk. Egy biztosítótársaság úgy látta, hogy nem csak, hogy szüksége van ilyen livepatch megoldásra, de rájött, hogy a meglevőek nem is 100%-ban fedik le az igényeit, ezért házon belül fejleszt egyet a saját problémájára. Mondom, biztosítótársaság. Aminek kurván nem is profilja, mégis tesz bele energiát, erőforrást, embert.

Mi meg örülhetünk, ha ha ennek az erőfeszítésnek az eredményét open source megoldásként megkapjuk.

trey @ gépház