- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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
- A hozzászóláshoz be kell jelentkezni
igen? van ilyen
- A hozzászóláshoz be kell jelentkezni
gondoltam rakerdezek, mi ertelme volt a kommentednek ? :D
- A hozzászóláshoz be kell jelentkezni
> 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?
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Na ezért csinálnak egy n+1-iket. Az ügyfeleket a saját infrastruktúrájukban akarják tartani.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Pár másodperc a reeboot. Igaz is lenne, ha minden alkalmazás megnyitna az újraindítás előtti állapotban és pozícióban.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
És a docker container-eimmel mi lesz? SSH session-ök? tmux session-ök?
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
É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?
- A hozzászóláshoz be kell jelentkezni
Á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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
A CloudStrike eseteben is ez a koncepcio, aztan megtapasztaltuk, hogy mi lett belole.
- A hozzászóláshoz be kell jelentkezni
CrowdStrike
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
ilyen nagy jelentősége van a felhős szolgáltatások, Kubernetes, sokféle HA rendszer korában?
Nem csak ezek futtatnak linuxot, hanem pl azok az eszközök amiken keresztül eljutsz a fenti rendszerekhez, routerek, switchek, BRAS-ok stb
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Amelyek pont ugyanúgy redundánsan futnak, ha fontos a működésük...
- A hozzászóláshoz be kell jelentkezni
És ugyanúgy redundánsan sérülékenyek, HA MÉG NINCS hozzájuk javított firmware. Ezek kiadásának átfutási ideje ... :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Azt hittem ezt mar 15 eve az Oracle ksplice idejen felfogta mindenki... leginkabb gyenge fantazianak es tajekozatlansagnak hivnam, ha nem tudsz restartot nem turo rendszert elkepzelni.
- A hozzászóláshoz be kell jelentkezni
Most csendben emlekezzunk meg a szep regi idokrol, amikor mondjuk egy enterprise 3000-ben (kozel 30 eve) menet kozben csereltel processor kartyat, mert nem lehetett/szabadott ujrainditani....eh, de kurva oreg vagyok :D
- A hozzászóláshoz be kell jelentkezni
És félelmetes, hogy milyen téveszmék élek még most is a fejekben vele kapcsolatban.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Emlekszem, mikor tobb, mint 10 eve nem lehetett itt valakinek elmagyarazni, hogy a live patchinghez "nem kell lemenni init 3-ba" es mindenki paraszt volt, aki jobban ertette, mint o. :)
- A hozzászóláshoz be kell jelentkezni
Biztos, azonban itt arról van szó, hogy a "a felhős szolgáltatások, Kubernetes, sokféle HA rendszer korában" buzzword ezen a problémán vajmi keveset segít.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Megtalaltam:
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ha elkészül, nagyon kíváncsi leszek egy használható összehasonlításra.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
van olyan ITsec elvárás, ahol a lehető leghamarabb kell reagálni 0day hibára
Van olyan, ahol nem? :)
- A hozzászóláshoz be kell jelentkezni