A Linux kernel-ban nemrég megszaporodtak a biztonsági hibák, és egyre több hiba- és biztonsági jelentés születik részben vagy teljes egészében AI-eszközök segítségével. Emiatt szükség volt kiegészítő dokumentációra. A régi Linux-fejlesztő, Willy Tarreau vállalta, hogy megírja a kernel-hibákkal kapcsolatos új leírásokat.

Hogy mi számít biztonsági hibának a Linux kernel esetében, az új dokumentáció így fogalmaz:

"Fontos, hogy a legtöbb hibát nyilvánosan kezeljük, hogy a lehető legszélesebb közönséget bevonjuk, és a legjobb megoldást találjuk meg. A természetüknél fogva az olyan hibák, amelyeket zárt körben, kevés résztvevő között vitatnak meg, kisebb eséllyel vezetnek a lehető legjobb javításhoz (például könnyebben kimaradnak valós használati esetek, korlátozottabbak a tesztelési lehetőségek).

Kiderült, hogy a security team felé bejelentett hibák többsége valójában egyszerű, hétköznapi hiba, amelyet tévesen minősítettek biztonsági hibának, mert a bejelentő nem ismerte a Linux kernel fenyegetési modelljét, amelyet a Documentation/process/threat-model.rst ír le. Ezeket a hibákat inkább a szokásos csatornákon kellett volna beküldeni, ahogy azt a Documentation/admin-guide/reporting-issues.rst ismerteti.

A security lista olyan sürgős hibákra szolgál, amelyek egy támadónak olyan képességet adnak egy helyesen konfigurált, éles rendszerben, amellyel normál esetben nem rendelkezhetne, és amelyet könnyű kihasználni, így az sok felhasználóra közvetlen fenyegetést jelent. Bejelentés előtt gondold át, hogy a probléma valóban átlép-e egy tRust-határt egy ilyen rendszeren.

Ha AI segítségével azonosítottál egy hibát, úgy kell kezelned, mintha az már nyilvános lenne. Lehetnek ugyan jó okaid azt gondolni, hogy nem az, de a security team tapasztalatai szerint az így felfedezett hibák szinte mindig egyszerre, több kutatónál is felbukkannak, gyakran ugyanazon a napon. Ilyen esetben ne oszd meg nyilvánosan a reprodukálási lépéseket, mert ezzel akaratlanul is kárt okozhatsz; csak jelezd, hogy van reprodukáló leírás, és a karbantartók privátban elkérhetik, ha szükségük van rá.

Ha nem vagy biztos benne, hogy egy probléma megfelel-e a feltételeknek, inkább jelentsd privát csatornán: a security team inkább vállalja, hogy besorol egy határesetet, mint hogy elszalasszon egy valódi sebezhetőséget. A hétköznapi hibák security listára küldése viszont nem gyorsítja fel a kezelésüket, viszont olyan triage-kapacitást köt le, amelyre más bejelentéseknek lenne szüksége."

A Linux kernel-hibák AI-val történő, felelős felderítéséről a dokumentáció ezt írja:

"A security teamhez érkező hibajelentések jelentős része valójában AI-eszközökkel támogatott kódellenőrzés eredménye. Ez hatékony módja lehet annak, hogy ritkán vizsgált területeken hibákat találjunk, ugyanakkor túlterheli a karbantartókat, akik néha kénytelenek figyelmen kívül hagyni az ilyen jelentéseket a gyenge minőségük vagy pontatlanságuk miatt. Emiatt a bejelentőknek különösen oda kell figyelniük néhány pontra, amelyek gyakran feleslegesen nehezen kezelhetővé teszik ezeket a jelentéseket:

Hossz: az AI által generált jelentések hajlamosak túl hosszúak lenni, több szekcióval és túl sok részlettel. Így nehéz észrevenni a fontos információkat, például az érintett fájlokat, verziókat és a hatást. Gondoskodj róla, hogy a probléma világos összefoglalója és minden kritikus részlet elöl szerepeljen. Ne kényszerítsd a triage-mérnököket arra, hogy több oldalnyi szöveget átböngésszenek. Állítsd be az eszközeidet úgy, hogy tömör, emberi stílusú jelentéseket készítsenek.

Formázás: a legtöbb AI által generált jelentés tele van Markdown tagekkel. Ezek a díszítések megnehezítik a fontos információk keresését, és nem élik túl az idézési folyamatokat továbbítás vagy válaszolás közben. Kérjük, mindig alakítsd a jelentésedet egyszerű szöveggé, minden formázási díszítés nélkül, mielőtt elküldöd.

Hatás értékelése: sok AI által generált jelentés nem érti a kernel fenyegetési modelljét (lásd Documentation/process/threat-model.rst), és hosszan sorolja a kitalált, elméleti következményeket. Ez zajt kelt, és megnehezíti a triage-ot. Maradj a bizonyítható tényeknél (például: „ez a hiba lehetővé teszi bármely felhasználó számára a CAP_NET_ADMIN jog megszerzését”), és ne sorold fel a spekulatív következményeket. Kérd meg az eszközödet, hogy a kiértékelés részeként olvassa el ezt a dokumentációt.

Reproducer: az AI-alapú eszközök gyakran képesek reprodukáló teszteseteket generálni. Mindig gondoskodj róla, hogy az eszköz készítsen ilyet, és alaposan teszteld. Ha a reprodukáló nem működik, vagy az eszköz nem tud ilyet előállítani, a jelentés megbízhatóságát komolyan meg kell kérdőjelezni. Mivel a jelentés egy nyilvános listára kerül, a reprodukálót csak a karbantartók kérésére oszd meg.

* Javítás javaslata: sok AI-eszköz valójában jobban tud kódot írni, mint értékelni. Kérd meg az eszközt, hogy javasoljon javítást, és teszteld azt, mielőtt bejelented a problémát. Ha a javítást nem lehet tesztelni, mert ritka hardvert vagy szinte kihalt hálózati protokollokat igényel, akkor a probléma nagy valószínűséggel nem biztonsági hiba. Ha mégis születik javítás, annak meg kell felelnie a Documentation/process/submitting-patches.rst előírásainak, és tartalmaznia kell egy 'Fixes:' taget, amely megjelöli azt a commitot, amely a hibát bevezette.

Ha ezeket a szempontokat figyelmen kívül hagyod, a jelentésed könnyen a kukában végezheti.

Használj józan észt a jelentés értékelésekor. Ha az érintett fájlt több mint egy éve nem módosították, és egyetlen ember tartja karban, jó eséllyel már alig használják, és a kitettség gyakorlatilag nulla (például nagyon régi hardverek driverjei, elavult fájlrendszerek). Ilyen esetekben felesleges egy karbantartó idejét egy jelentéktelen jelentéssel terhelni. Ha a probléma nyilvánvalóan triviális és nyilvánosan is könnyen felfedezhető, közvetlenül a nyilvános levelezőlistákra jelentsd."

Willy Tarreau új Linux kernel-hibákról szóló dokumentációja teljes egészében elolvasható

ebben a commitban, amely már bekerült a Linux Git-be, a vasárnapra várható Linux 7.1-rc4 kiadás előtt.