Komunita linuxového jádra zažívá moment... hloubkový přezkum toho, jak jsou zranitelnosti hlášeny a spravoványTo je z velké části způsobeno přímým dopadem nástrojů umělé inteligence na audit kódu. Široké rozšíření těchto systémů dramaticky zvýšilo objem bezpečnostních upozornění, ale také odhalilo vážný problém duplicity, šumu a dodatečné zátěže pro správce.
Linus Torvalds, ústřední postava projektu, zašel dokonce tak daleko, že jej popsal (v Poznámky k vydání Linuxu 7.1-rc4) seznam soukromých bezpečnostních prvků jádra jako „téměř zcela nezvládnutelné“ kvůli lavině zpráv podporovaných umělou inteligencíMnoho z těchto hlášení bylo duplicitních nebo chybně klasifikovaných. V reakci na to projekt vydal novou dokumentaci integrovanou do Linuxu 7.1, která nově definuje, co představuje skutečnou bezpečnostní zranitelnost a jak by se mělo zacházet se hlášeními generovanými pomocí modelů umělé inteligence.
Seznam zabezpečení zahlcený duplicitními hlášeními
Ve svých nedávných sděleních týkajících se vývoje Linuxu 7.1 Torvalds varoval, že mailing list pro zranitelnosti se stal úzké hrdlo, kde se důležitá oznámení mísí s množstvím nadbytečných hlášeníProblém není jen v kvantitě, ale v tom, že různí lidé, kteří používají stejné automatizované nástroje, nakonec odesílají naprosto stejné výsledky.
Jak vysvětlil, vývojáři ztrácejí spoustu času přeposíláním zpráv těm, kteří by je skutečně měli obdržet, nebo upřesňováním, že chyba již byla opravena. opraveno před několika dny nebo týdny ve větvích jádraTato situace, kterou někteří přirovnávají k „záplavě“ e-mailů, nutí věnovat zdroje objasňování duplikátů namísto zaměření se na nové a závažné zranitelnosti.
Willy Tarreau, zkušený správce stabilního jádra známý svou prací na HAProxy, poskytl ilustrativní čísla: Ještě před pár lety dostával soukromý mailing list dvě až tři zprávy týdně.Zatímco nyní se denně zpracovává pět až deset hlášení. Mnohá z nich pocházejí z analýz s pomocí umělé inteligence, které sice někdy poukazují na skutečné problémy, ale přicházejí v nepraktickém formátu a bez poskytnutí relevantních doplňujících informací.
Torvalds se neostýchá proti umělé inteligenci, ale proti jejímu zneužívání.
I když se to může zdát jinak, Torvalds to jasně uvedl Neodporuje používání umělé inteligence jako nástroje pro vývoj a audit.Sám uznává, že tyto typy systémů ve své práci používá, ale trvá na tom, že je nutné je používat zodpovědně a uvážlivě.
Ve svých zprávách komunitě zdůraznil, že nástroje umělé inteligence „jsou skvělé“, když skutečně pomáhají, ale stávají se problémem, když generují „Zbytečná bolest a zbytečná fiktivní práce“Jinými slovy, pouhá skutečnost, že automatizovaný model upozorňuje na možnou zranitelnost, neospravedlňuje zahlcení bezpečnostních kanálů špatně ověřenými hlášeními nebo hlášeními bez technického kontextu.
Torvalds trvá na tom, že každý, kdo používá umělou inteligenci k hledání chyb, by neměl přeposílat pouze surový výsledek, ale Přečtěte si dokumentaci k jádře, pochopte model hrozby a pokud možno poskytněte záplatu nebo alespoň důkladné vysvětlení dopadu.Cílem je, aby lidé přidávali hodnotu automatizované práci, spíše než aby fungovali jako pouhí prostředníci mezi nástrojem a mailing listem.
Nová pravidla v Linuxu 7.1: co je zranitelnost a co ne
V reakci na tuto situaci kernelový projekt začlenil do Linuxu 7.1 přesnější dokumentaci týkající se Které chyby by měly být považovány za bezpečnostní zranitelnosti a které jsou jednoduše chybami, které je třeba řešit obvyklými kanály?Text, jehož autorem je Willy Tarreau, je již součástí stromu Gitu jádra a je k dispozici před vydáním Linuxu 7.1-rc4.
Průvodce začíná jednoduchou myšlenkou: Většina chyb by neměla být směrována přes seznam soukromých bezpečnostních adres.Místo toho by se s nimi mělo otevřeně zabývat ve veřejných e-mailových seznamech pro vývojáře. Veřejná diskuse o problémech přitahuje více recenzentů, pokrývá více případů užití a obecně vede ke kvalitnějším řešením.
Dokument uvádí, že Linux již měl jasně definovaný model hrozebToto nyní slouží jako primární referenční bod při rozhodování, zda by se s zranitelností mělo zacházet soukromě. Bezpečnostní zranitelnost je definována jako taková, která útočníkovi umožňuje získat funkce, které by správně nakonfigurovaný produkční systém neměl mít, kterou lze rozumně zneužít a která představuje skutečnou hrozbu pro významný počet uživatelů.
V praxi jsou ti, kteří objeví problémy, vyzýváni, aby se sami sebe zeptali, zda chyba V typickém prostředí to opravdu překračuje hranici důvěry.Pokud je odpověď ne, doporučeným přístupem je kontrola veřejných e-mailových seznamů (jako je LKML a e-mailové seznamy specifické pro daný subsystém), nikoli omezeného bezpečnostního kanálu. Průvodce však připouští určitou opatrnost: v případě pochybností je lepší si pochybné hlášení soukromě prohlédnout, než nechat skutečnou zranitelnost proklouznout sítí.
Dalším klíčovým bodem textu je, že Posílání běžných chyb na soukromý mailing list jejich opravu nijak neurychluje.Naopak to zabírá čas, který bezpečnostní tým potřebuje k určení priorit skutečně kritických selhání. Zahlcení tohoto kanálu drobnými problémy v konečném důsledku zhoršuje celkovou ochranu systémů založených na Linuxu, včetně serverů, cloudové infrastruktury a průmyslových zařízení.
Model hrozeb: oddělení oprávnění a vyloučené případy
Nová dokumentace aktualizuje a podrobně popisuje model hrozeb pro jádro, který uvádí záruky, jejichž porušení je považováno za... bezpečnostní problém zasloužící prioritní pozornostPatří mezi ně oddělení uživatelského prostoru a jádra, izolace paměti mezi procesy, omezení ptrace, izolace IPC a síťových mechanismů a ochrany spojené s citlivými funkcemi, jako jsou CAP_SYS_ADMIN, CAP_NET_ADMIN nebo CAP_SYS_PTRACE.
Zvláštní pozornost je věnována jmenným prostorům uživatelů, kde nastavení jako CONFIG_USER_NS umožňují neprivilegovaným uživatelům vytvářet izolovaná prostředí. Projekt očekává, že tyto případy nemohou ohrozit globální systémtakže jakékoli narušení této izolace se stává bezpečnostním problémem.
Analyzují se také ladicí rozhraní, jako například /proc/kmsg, perf nebo debugfs, s ohledem na to, že přístup k citlivým informacím prostřednictvím těchto mechanismů je riskantní. Musí být blokováno, pokud to správce výslovně nepovolí.Jinak existuje riziko úniku dat, která by mohla být použita k vylepšení útoků nebo ke zvýšení oprávnění.
Spolu s touto definicí záruk průvodce jasně uvádí, jaké druhy problémů Neměly by být automaticky označovány jako zranitelnostiTato kategorie zahrnuje chyby v zastaralých větvích jádra, nebezpečné možnosti kompilace zvolené administrátorem, nesprávná oprávnění v sysctl nebo souborových systémech, funkce rezervované pro ladění (LOCKDEP, KASAN, FAULT_INJECTION) a experimentální kód ve stagingových oblastech.
Vady, které vyžadují Nadměrná oprávnění, laboratorní scénáře vzdálené od reálného použití, manipulovaný hardware, nezvládnutelný počet pokusů nebo konfigurace, které by žádný rozumný administrátor v produkčním prostředí nepoužil. Podobně úniky dat bez jasného zneužití a určité problémy v obrazech souborových systémů, které obvykle řeší nástroje jako fsck, nespadají do základní působnosti bezpečnostního kanálu.
Zjištění s pomocí umělé inteligence: od soukromého k veřejnému
Jednou z nejvýraznějších změn v aktualizaci je přístup k chybám objeveným s pomocí umělé inteligence. Dokumentace uvádí, že Chyby zjištěné automatizovanou analýzou by měly být v podstatě považovány za veřejnéi když je první zásilka odeslána soukromou poštou.
Důvod je čistě praktický: nedávné zkušenosti bezpečnostního týmu ukazují, že k těmto selháním obvykle dochází. současně v rukou několika badatelů kteří experimentují s podobnými nástroji. Je běžné, že během několika hodin dorazí několik e-mailů popisujících stejnou situaci s drobnými odchylkami ve formátu, takže jakékoli očekávání dlouhodobé důvěrnosti je nerealistické.
Tato nová realita vede Torvaldse k tvrzení, že Nemá smysl zacházet s těmito zjištěními jako s tajemstvími, která musí být skryta, dokud nebude existovat záplata.Pokud je běžná umělá inteligence dokáže najít, je rozumné předpokládat, že stejného výsledku mohou dosáhnout i ostatní aktéři, včetně potenciálních útočníků. Označování těchto zranitelností jako vyhrazených pouze přidává práci navíc a komplikuje koordinaci.
To neznamená, že se doporučuje zveřejňovat všechny technické detaily bez filtrování. Průvodce požaduje, aby v případech zjištěných pomocí umělé inteligence… Funkční přehrávač pro chybu nebyl okamžitě zveřejněn (přesná posloupnost kroků nebo kód, který chybu spouští). Vhodným přístupem je uvést, že tento materiál existuje, a umožnit správcům, aby si ho soukromě vyžádali, pokud to považují za nezbytné k ověření opravy.
Tímto přístupem se projekt snaží spojit dva zájmy: na jedné straně Vyhněte se zahlcování soukromého seznamu zjištěními, o kterých ostatní již vědí.Na druhou stranu je důležité nenabízet jen tak komukoli „recept“ na zneužití, než budou zavedena zmírňující opatření. Přehrávač médií je považován za cenný nástroj pro ladění i posouzení dopadů, ale také za citlivou záležitost, pokud je distribuován bez minimálních kontrol.
Požadavky na kvalitu reportů generovaných umělou inteligencí
Nová dokumentace věnuje celou sekci tomu, jak by měly být psány zprávy podporované umělou inteligencí. Týmy údržby si opakovaně stěžují, že mnoho z těchto zpráv dorazí nadměrně nafouknuté, s nadbytečnými vysvětleními a malým zaměřením na základní data, což komplikuje jeho čtení a klasifikaci.
Nejprve se požaduje, aby zprávy byly stručně, jasně a v jednoduchém textuTým nedoporučuje používat formáty jako Markdown, zdobení nebo složité struktury, které neobstojí dobře v řetězených odpovědích na e-mailových seznamech. Myšlenka je taková, že při přeposílání nebo citování zprávy se neztratí žádné informace a text se nestane nečitelným blokem.
Pokud jde o obsah, doporučuje se začít s Jednoduchý souhrn s uvedením dotčeného souboru nebo subsystému, dotčených verzí a pozorovatelného dopadu chyby.Odtud lze přidávat podrobnosti, ale vždy s cílem usnadnit rychlé čtení, které vám umožní rozhodnout, zda je chyba prioritní, nebo spadá do kategorie drobných problémů.
Dalším důležitým aspektem je, jak je dopad popsán. Vývojáři jádra varují, že mnoho zpráv generovaných umělou inteligencí... Mají tendenci přehánět teoretické důsledky.řetězení hypotetických scénářů, které nerespektují skutečný model hrozeb projektu. Místo vytváření složitých narativů útoků jsou účastníci požádáni, aby se drželi ověřitelných faktů, jako je například konkrétní vysvětlení, jaké další funkce by uživatel mohl získat na standardně konfigurovaném systému.
Průvodce dokonce navrhuje, aby si samotný nástroj umělé inteligence, pokud je to proveditelné, předem přečetl dokumentaci k modelu hrozeb pro Linux. sladit své závěry s kritérii, která již projekt stanovilCílem je omezit nedorozumění a zabránit tomu, aby automatické hlášení proměnilo chybu s omezeným dopadem v údajnou kritickou zranitelnost bez jakéhokoli reálného základu.
Hráči, patche a zdravý rozum ve věku automatizace
Kromě popisu selhání se dokumentace zaměřuje i na praktičtější aspekty: Generování a ověřování hráčů a patchů s pomocí umělé inteligenceMnoho moderních nástrojů dokáže vytvářet malé testovací programy nebo skripty, které chybu spustí, a také navrhovat změny kódu k její opravě, ale ne vždy to dělají spolehlivě.
Jádro trvá na tom, že před odesláním zprávy Výzkumník musí osobně ověřit, zda přehrávač funguje tak, jak je popsáno.Pokud sekvence nespustí selhání nebo pokud umělá inteligence není schopna vygenerovat reprodukovatelnou metodu, je platnost zprávy vážně ohrožena. Publikování zjištění bez tohoto ověření pouze přidává šum a plýtvá časem správců.
Pokud jde o záplaty, text zdůrazňuje, že mnoho umělých inteligencí je ještě lepších. psaní kódu, který vyhodnocuje jeho dopadUživatelé těchto nástrojů se proto vyzývají, aby je požádali nejen o identifikaci problému, ale také o návrh řešení. Zdůrazňuje se však, že výsledek musí být před odesláním na vývojové e-mailové konference ručně zkontrolován a otestován.
Pokyn je jednoznačný v případech, kdy nelze náplast otestovat, protože závisí na exotický hardware, prakticky zaniklé síťové protokoly nebo extrémně vzácné konfiguracePokud se chyba projeví pouze v tak okrajovém prostředí, že ji nikdo nemůže snadno ověřit, je velmi pravděpodobné, že nemá příslušnou kategorii bezpečnostní zranitelnosti a neměla by zabírat čas soukromého kanálu.
Při navrhování opravy projekt uživatelům připomíná, že musí dodržovat standardní pokyny pro odesílání oprav jádra, včetně označení „Opravy:“ označující konkrétní commit, který chybu způsobilDoporučuje se také použít selský rozum: pokud se dotčený soubor nezměnil déle než rok a spravuje ho jedna osoba, můžeme se potýkat s komponentou s velmi malým počtem skutečných uživatelů, jako jsou staré ovladače hardwaru nebo zastaralé souborové systémy.
V těchto případech je doporučení jasné: pokud je problém triviální, snadno detekovatelný a nemá žádný zjevný dopad v typickém prostředí, Nejrozumnějším přístupem je řešit to přímo prostřednictvím seznamů veřejných záměrů. a ne na seznamu věnovaném bezpečnosti. Tímto způsobem jsou nejcitlivější zdroje rezervovány pro incidenty s potenciálně vážnými následky.
Od éry fuzzingu k lavině umělé inteligence: lekce pro svobodný software
Současná situace poněkud připomíná éru, kdy se začaly používat fuzzingové nástroje jako Syzkaller. bombardovat jádro hlášeními o zjištěných chybách poloautomatickým způsobemV té době se komunita musela naučit integrovat tento neustálý tok poznatků do svého vývojového procesu, aniž by to narušilo její každodenní práci.
Něco podobného se děje s umělou inteligencí, ale v jiném měřítku. Nyní je automatizováno nejen generování vstupů, které způsobují chyby, ale také... samotné vypracování zpráv, statická analýza kódu a návrh opravTo urychluje vyhledávání chyb, ale pokud nejsou správně filtrovány a prioritizovány, také se tím znásobuje počet e-mailů, paralelních diskusí a očekávání ohledně toho, co si jaderný tým dokáže poradit.
V samotném ekosystému Linuxu existují v hodnocení tohoto jevu nuance. Greg Kroah-Hartman, další klíčový správce jádra, poukázal na to, že Zprávy generované umělou inteligencí se rychle změnily z téměř vždy nesmyslných prací na platné příspěvky.Tento optimističtější pohled koexistuje s Torvaldsovými obavami z nadměrného počtu duplikátů a přetížení bezpečnostního seznamu.
Tyto postoje spíše než aby si protiřečily, odrážejí dvě strany stejného adopčního procesuNa jedné straně může být umělá inteligence velmi užitečná pro hledání skutečných problémů; na druhé straně, pokud mnoho lidí spouští stejné nástroje na stejném kódu a odesílá výsledky bez filtrování, kombinovaný efekt je „bouře“ upozornění, kterou je obtížné zvládat.
Příklad zodpovědného využití automatizace uvádí sám Kroah-Hartman, který publikoval vlastní systémy pro skenování jádra, generování záplat, jejich testování a odesílání podle standardního pracovního postupu projektu. Klíčové je, že v těchto případech... Vývojář přebírá plnou technickou odpovědnost za celý životní cyklus, namísto pouhého přeposílání bez kontroly toho, co nástroj vytváří.
Celé hnutí kolem Linuxu 7.1 ukazuje projekt, který zdaleka neodmítá umělou inteligenci, ale naopak... přizpůsobují své procesy tak, aby automatizace fungovala ve prospěch bezpečnosti, a ne proti níStanovením přísnějších kritérií pro to, co představuje zranitelnost, požadavkem ověřitelných hlášení v prostém textu a povzbuzováním umělé inteligence k přispívání ke generování a testování záplat, si jádro klade za cíl chránit čas správců, omezit šum a zaměřit úsilí na chyby, které mohou skutečně ohrozit produkční systémy.