Linux Kernel „Killswitch" – a vészfék, ami megosztja a közösséget

A Copy Fail és a Dirty Frag után a Linux kernel fejlesztői közössége egy kényelmetlenül egyszerű kérdéssel szembesült: mi legyen addig, amíg a javítás megérkezik?

Sasha Levin, az NVIDIA mérnöke és a Linux stabil kernel egyik karbantartója május 11-én egy szokatlan javaslattal állt elő a Linux Kernel Mailing Liston: adjunk az adminisztrátorok kezébe egy vészféket — egy olyan mechanizmust, amellyel futó rendszeren lehet kikapcsolni egy sebezhető kernelfunkciót, anélkül hogy újra kellene indítani a gépet, vagy meg kellene várni a javított kernel csomagot.

A javaslatot „Killswitch"-nek nevezték el. És a Linux közösség megoszlott tőle.

Mi a probléma, amelyet megold?

Amikor egy komoly Linux kernel sebezhetőség napvilágra kerül, az érintett rendszerek egy sajátos veszélyzónába kerülnek: a hiba nyilvános, az exploit kód elérhető — de a javított kernel még nincs kész, vagy ha kész is, a disztribúciók csomagolása, tesztelése és kiszállítása még napokat vehet igénybe. Nagyvállalati környezetben, ahol egy kernelfrissítés után az összes szervert újra kell indítani, ez heteket is jelenthet.

„Amikor egy biztonsági probléma nyilvánosságra kerül, a rendszerek addig maradnak kitéve, amíg a javított kernel felépül, kiszállításra kerül, és újraindítják őket" — írta Levin a javaslatban. „Sok ilyen esetben a legegyszerűbb enyhítés az, ha megállítjuk a hibás funkció hívását. A Killswitch ezt biztosítja."

A kontextus nem véletlen. Az elmúlt hetek nem éppen a hagyományos „várj a javításra" megközelítés legjobb reklámjai voltak. Először a Copy Fail vált nyilvánossá — egy helyi jogosultság-kiterjesztési hiba, amely a közzétételtől számítva gyorsan aktív kihasználásig jutott. Napokkal később érkezett a Dirty Frag, egy másik hasonló osztályú sebezhetőség, amelynek exploit kódja szintén megjelent, mielőtt a koordinált közzététel lezárulhatott volna.

Hogyan működik a Killswitch?

A Killswitch lényege egy „must exterminate" megközelítés: az adminisztrátor megad egy kernelfüggvény nevet és egy visszatérési értéket. Ettől kezdve az adott függvény nem fut le — helyette azonnal visszaadja a megadott értéket (általában egy hibakódot), mintha a funkció nem lenne elérhető.

A vezérlés a kernel securityfs interfészén keresztül történik:

echo "engage af_alg_sendmsg -1" \
  > /sys/kernel/security/killswitch/control

Ezután minden program, amely az AF_ALG-on (a kernel kriptográfiai interfészén, amelyet a Copy Fail is kihasznált) keresztül próbál adatot küldeni, hibát kap vissza. Az af_alg_sendmsg-ben lévő hiba elérhetetlenné válik, mert a függvény soha nem fut le ténylegesen. A hatás azonnal érvénybe lép minden CPU-magon, és addig marad aktív, amíg az adminisztrátor ki nem kapcsolja, vagy a rendszert újra nem indítják.

Van egy bootparaméteres változat is a flottakezeléshez:

killswitch=af_alg_sendmsg=-1,ksmbd_something=-1,...

Ez lehetővé teszi, hogy egy teljes szerverpark bootloaderén keresztül egyszerre alkalmazzák az enyhítést.

Levin azokat a kódútvonalakat célozza meg ezzel az eszközzel, amelyekre a legtöbb rendszer nem támaszkodik napi szinten. Külön megemlíti az AF_ALG-ot, a ksmbd-t (Windows fájlmegosztás), az nf_tables-t, a vsock-ot és az ax25-öt mint jó jelölteket.

A kernel „megfertőzése" — és amit ez jelent

A Killswitch nem titkol semmit. A bekapcsolás „megfertőzi" a kernelt — ez a kernel jelzése arra, hogy a futó kód már nem tiszta upstream Linux. Egy új flag (H, 20. bit) kerül beállításra, amint bármely killswitch aktív, és ez megmarad a kikapcsolás után is egészen a következő újraindításig. Minden ezt követő összeomlás bannerében ott lesz a H betű — ez jelzés a Linux karbantartóknak, hogy a képet módosítottak.

Ez tudatos döntés: az eszköz nem kívánja elrejteni a beavatkozás tényét. Ha valami elromlik a Killswitch bekapcsolása után, a hibajelentés egyértelműen mutatja, hogy a rendszer módosított állapotban volt.

Miért osztja meg a közösséget?

A javaslat nem talált egyöntetű lelkesedésre.

Valaki a Redditen így fogalmazott, több mint 100 upvote-tal: „Hasznos végső mentsvárként, de ijesztő, ha az emberek javításként kezelik. Könnyen el tudom képzelni, hogyan töri ez szét a production rendszereket kreatív módokon." Egy másik vélemény még élesebben fogalmaz: „Olyan biztonsági funkció, amely rosszabb lehet, mint maga a sebezhetőség."

A szkepticizmus mögött komoly érvek állnak:

A Killswitch nem javít semmit. Ez nem patch — ez amputáció. A sebezhető kód nem kerül kijavításra, csak elérhetetlenné válik. Bármi, ami arra a funkcióra támaszkodott, szintén leáll.

Nincs automatikus biztonsági ellenőrzés. A patch nem tartalmaz automatikus biztonsági ellenőrzéseket arra vonatkozóan, hogy egy adott függvény biztonságosan kikapcsolható-e. A rossz függvény kikapcsolása vagy helytelen visszatérési érték megadása megzavarhatja a rendszer működését, vagy új problémákat okozhat.

Az eszköz maga is támadási felület lehet. Ha egy rossz szereplő root hozzáféréssel rendelkezik — ami a Killswitch aktiválásához szükséges —, akkor eleve más lehetőségei is vannak. Ha viszont valaki social engineeringgel rávesz egy adminisztrátort, hogy aktiválja a rossz funkcióra, az denial-of-service hatást érhet el.

Miért nem a livepatch? Több fejlesztő is megjegyezte: miért vezessünk be egy killswitch-et, ha a livepatch már régóta elérhető, és már rendelkezik logikával arra vonatkozóan, hogy a kódútvonal éppen használatban van-e — amit az új javaslat nem kínál.

A támogatók érvei

A vita másik oldalán azok állnak, akik a Killswitch-et pragmatikus, szükségszerű eszköznek látják.

A Copy Fail megmutatta, hogy még a jól szándékú közzététel is sodorhatja a disztribúciókat pánikba a folyamat bonyolultságának rossz megértése miatt. A Dirty Frag megmutatta, hogyan válnak értelmetlenné a sebezhetőség-közzétételi embargók, ha egy javítás egy nyilvános repóba kerül. A killswitch proposal maga is elismerés: a jelenlegi rendszer nem működik elég gyorsan.

A javaslat inkább az enterprise Linux telepítéseket célozza, mintsem a tipikus asztali rendszereket. A cél az ismert biztonsági problémáknak való kitettség csökkentése a javítás fejlesztése közben.

Levin maga is reálisan fogalmaz: a legtöbb felhasználó számára „ez a socket-család nem működik egy napig" kisebb árat jelent, mint egy ismert sebezhető kernelt futtatni a javítás megérkezéséig.

Hol tart most a javaslat?

A killswitch patch jelenleg még felülvizsgálat alatt áll, és nem került be a Linux kernelbe. Hogy végül bekerül-e, és milyen formában, az a kernel karbantartók felülvizsgálati folyamatától és a közösségen belüli szélesebb körű vitáktól függ.

Egyelőre tehát nem elérhető egyetlen kiadott kernelben vagy disztribúcióban sem — de a vita önmagában is figyelemre méltó. Az, hogy a javaslat egyáltalán komolyan tárgyalásra kerül, jelzi: a Linux biztonsági ökoszisztéma tanul a közelmúlt eseményeiből, és keresi az eszközöket arra, hogy a következő Copy Fail vagy Dirty Frag kevésbé fájdalmas legyen.

Összefoglalás

A Killswitch egy kényelmetlenül őszinte beismerés: a jelenlegi patch-és-reboot ciklus nem mindig elég gyors. Hogy a közösség elfogadja-e ezt a vészféket, vagy megtalálja a jobb megoldást — az a következő hetek kernelmailing-listás vitáiból fog kiderülni.