Linuxi kerneli kogukond kogeb praegu hetke haavatavuste teatamise ja haldamise põhjalik ülevaadeSee on suuresti tingitud tehisintellekti tööriistade otsesest mõjust koodi auditeerimisele. Nende süsteemide laialdane kasutuselevõtt on dramaatiliselt suurendanud turvahoiatuste hulka, kuid see on toonud esile ka tõsise dubleerimise, müra ja hooldajatele lisakoormuse probleemi.
Linus Torvalds, projekti keskne tegelane, on seda isegi kirjeldanud (selles Linux 7.1-rc4 väljalaske märkmed) kerneli privaatne turvaloend kujul „Peaaegu täiesti juhitamatu” tehisintellekti toega aruannete laviini tõttuPaljud neist aruannetest olid duplikaadid või valesti klassifitseeritud. Vastuseks on projekt avaldanud Linux 7.1-sse integreeritud uue dokumentatsiooni, mis määratleb uuesti, mis on tõeline turvaauk ja kuidas tehisintellekti mudelite abil genereeritud aruandeid tuleks käsitleda.
Turvaloend on ĂĽlekoormatud topeltaruannetest
Oma hiljutistes Linux 7.1 arendust puudutavates teadetes hoiatas Torvalds, et haavatavuste meililistist on saanud kitsaskoht, kus olulised teated on segamini hulga üleliigsete aruannetegaProbleem pole ainult kvantiteedis, vaid selles, et erinevad inimesed, kes kasutavad samu automatiseeritud tööriistu, esitavad lõpuks täpselt samad leiud.
Nagu ta selgitas, raiskavad arendajad palju aega sõnumite edastamisele neile, kes peaksid need tegelikult saama, või selgitamisele, et viga on juba parandatud. parandatud päevi või nädalaid tagasi kerneli harudesSee olukord, mida mõned võrdlevad meilide "uputusega", sunnib ressursse suunama duplikaatide selgitamisele, selle asemel et keskenduda uutele ja tõsistele haavatavustele.
Willy Tarreau, veteranist stabiilse kerneli hooldaja, kes on tuntud oma töö poolest HAProxy kallal, on esitanud illustreerivad arvud: Vaid paar aastat tagasi sai privaatne meililisti kaks kuni kolm aruannet nädalas.Kuigi praegu töödeldakse iga päev viit kuni kümme aruannet, pärinevad paljud neist tehisintellekti abil tehtud analüüsidest, mis, kuigi mõnikord viitavad tegelikele probleemidele, saabuvad ebapraktilises vormingus ja ilma asjakohase lisateabeta.
Torvalds ei kritiseeri tehisintellekti, vaid selle väärkasutamist.
Kuigi see võib tunduda teisiti, on Torvalds selgelt öelnud, et See ei ole vastu tehisintellekti kasutamisele arendus- ja auditeerimisvahendina.Ta ise möönab seda tüüpi süsteemide kasutamist oma töös, kuid rõhutab, et neid tuleb kasutada vastutustundlikult ja kaalutletult.
Oma kogukonnale saadetud sõnumites on ta rõhutanud, et tehisintellekti tööriistad on „suurepärased”, kui need tegelikult aitavad, kuid muutuvad probleemiks, kui need tekitavad "Mittevajalik valu ja kasutu fiktiivne töö"Teisisõnu, ainuüksi asjaolu, et automatiseeritud mudel osutab võimalikule haavatavusele, ei õigusta turvakanalite üleujutamist halvasti kontrollitud või tehnilise kontekstita aruannetega.
Torvalds nõuab, et igaüks, kes kasutab tehisintellekti vigade leidmiseks, ei tohiks edastada ainult toortulemust, vaid Loe kerneli dokumentatsiooni, saa aru ohumudelist ja paku võimaluse korral parandus või vähemalt mõju põhjalik selgitus.Eesmärk on, et inimesed lisaksid automatiseeritud tööle väärtust, selle asemel et tegutseda pelgalt vahendajatena tööriista ja meililisti vahel.
Uued reeglid Linux 7.1-s: mis on haavatavus ja mis mitte
Sellele olukorrale reageerides on kerneli projekt Linux 7.1-sse lisanud täpsema dokumentatsiooni selle kohta, Milliseid tõrkeid tuleks käsitleda turvaaukudena ja milliseid lihtsalt vigadena, millega tuleb tegeleda tavapäraste kanalite kauduWilly Tarreau kirjutatud tekst on juba osa kerneli Giti puust ja saadaval enne Linux 7.1-rc4 väljaandmist.
Juhend algab lihtsast ideest: Enamikku vigu ei tohiks suunata privaatse turvaloendi kaudu.Selle asemel tuleks neid avalikult käsitleda avalikes arenduse meililistides. Probleemide avalik arutamine meelitab ligi rohkem arvustajaid, hõlmab rohkem kasutusjuhtumeid ja viib üldiselt kvaliteetsemate lahendusteni.
Dokumendis märgitakse, et Linuxil oli juba olemas selgelt määratletud ohumudelSee on nüüd peamine lähtepunkt otsustamisel, kas haavatavust tuleks käsitleda privaatselt. Turvahaavatavus on defineeritud kui selline, mis võimaldab ründajal omandada võimeid, mida õigesti konfigureeritud tootmissüsteemil ei tohiks olla, mis on mõistlikult ärakasutatav ja mis kujutab endast reaalset ohtu märkimisväärsele hulgale kasutajatele.
Praktikas kutsutakse neid, kes probleeme avastavad, endalt küsima, kas viga See ületab tüüpilises olukorras tõesti usalduse piiri.Kui vastus on eitav, on soovitatav lähenemisviis kontrollida avalikke meililistid (näiteks LKML ja alamsüsteemipõhised meililistid), mitte piiratud turvakanalit. Sellegipoolest lubab juhend teatud ettevaatust: kahtluse korral on parem kahtlase aruandega privaatselt tutvuda, mitte lasta tõelisel haavatavusel silmapiirilt libiseda.
Teine teksti oluline punkt on see, et Tavaliste vigade saatmine privaatsesse meililistti ei paranda neid kiiremini.Vastupidi, see võtab turvameeskonnalt triaažiaega, mida nad vajavad tõeliselt kriitiliste tõrgete prioriseerimiseks. Selle kanali üleujutamine väiksemate probleemidega halvendab lõppkokkuvõttes Linuxi-põhiste süsteemide, sealhulgas serverite, pilveinfrastruktuuri ja tööstusseadmete üldist kaitset.
Ohumudel: privileegide ja välistatud juhtumite eraldamine
Uus dokumentatsioon ajakohastab ja kirjeldab üksikasjalikult kerneli ohumudelit, mis loetleb garantiid, mille rikkumist peetakse esmajärjekorras tähelepanu vääriv turvaprobleemNende hulka kuuluvad kasutajaruumi ja kerneli eraldamine, protsesside vaheline mälu isoleerimine, ptrace'i piirangud, IPC ja võrgumehhanismide isoleerimine ning tundlike funktsioonidega (nt CAP_SYS_ADMIN, CAP_NET_ADMIN või CAP_SYS_PTRACE) seotud kaitse.
Erilist tähelepanu pööratakse kasutajanimeruumidele, kus sellised sätted nagu CONFIG_USER_NS lubavad privilegeerimata kasutajatel luua isoleeritud keskkondi. Projekt eeldab, et need juhtumid ei saa globaalset süsteemi kahjustadanii et igasugune selle isolatsiooni rikkumine omandab julgeolekualase tähtsuse.
Samuti analüüsitakse silumisliideseid nagu /proc/kmsg, perf või debugfs, pidades meeles, et tundlikule teabele juurdepääs nende mehhanismide kaudu on riskantne. See tuleb blokeerida, välja arvatud juhul, kui administraator on selleks selgesõnalise loa andnud.Vastasel juhul on oht andmete lekkimiseks, mida saaks kasutada rünnakute täiustamiseks või privileegide laiendamiseks.
Lisaks garantiide määratlusele selgitab juhend, milliseid probleeme Neid ei tohiks automaatselt haavatavusteks märgistadaSellesse kategooriasse kuuluvad vead aegunud kerneli harudes, administraatori valitud ohtlikud kompileerimisvalikud, valed õigused sysctl-is või failisüsteemides, silumiseks reserveeritud funktsioonid (LOCKDEP, KASAN, FAULT_INJECTION) ja eksperimentaalne kood testimisaladel.
Vead, mis nõuavad Liigsed privileegid, reaalsest kasutusest kaugel olevad laboristsenaariumid, manipuleeritud riistvara, kontrollimatu arv katseid või konfiguratsioone, mida ükski mõistlik administraator tootmiskeskkonnas ei rakendaks. Samamoodi jäävad turvakanali põhiulatusest välja andmelekked ilma selge ärakasutamata ja teatud probleemid failisüsteemi kujutistes, millega tavaliselt tegelevad sellised tööriistad nagu fsck.
Tehisintellekti abil tehtud järeldused: erasektorist avaliku sektorini
Üks silmatorkavamaid muudatusi värskenduses on lähenemine tehisintellekti abil avastatud vigadele. Dokumentatsioonis on kirjas, et Automaatse analüüsi käigus tuvastatud vigu tuleks käsitleda sisuliselt avalike vigadena.isegi kui esimene saadetis tehakse erapostiga.
Põhjus on puhtalt praktiline: turvameeskonna hiljutine kogemus näitab, et need tõrked kipuvad tekkima samaaegselt mitme uurija käes kes katsetavad sarnaseid tööriistu. On tavaline, et mõne tunni jooksul saabub mitu sama seisundit kirjeldavat meili, mille vorming on veidi erinev, mistõttu on pikaajalise konfidentsiaalsuse ootus ebareaalne.
See uus reaalsus paneb Torvaldsi väitma, et Pole mõtet käsitleda neid leide saladustena, mida tuleb varjata, kuni paik on olemas.Kui tavaline tehisintellekt suudab need leida, on mõistlik eeldada, et ka teised osapooled, sealhulgas potentsiaalsed ründajad, võivad sama tulemuseni jõuda. Nende märgistamine reserveeritud haavatavustena lisab ainult lisatööd ja raskendab koordineerimist.
See ei tähenda, et kõigi tehniliste üksikasjade avaldamine ilma filtreerimiseta on soovitatav. Juhendis palutakse tehisintellekti abil tuvastatud juhtudel... Vea jaoks töötavat mängijat ei jagata kohe (täpne sammude jada või kood, mis vea käivitab). Sobiv lähenemisviis on märkida, et see materjal on olemas, ja lubada hooldajatel seda privaatselt taotleda, kui nad peavad seda paranduse valideerimiseks vajalikuks.
Selle lähenemisviisiga püüab projekt ühendada kaks huvi: ühelt poolt Väldi privaatnimekirja risustamist leidudega, millest teised juba teavad.Teisest küljest on oluline mitte pakkuda kellelegi ärakasutamise „retsepti” enne leevendusmeetmete rakendamist. Meediapleierit peetakse väärtuslikuks tööriistaks nii veaotsinguks kui ka mõju hindamiseks, kuid see on ka tundlik teema, kui seda levitatakse ilma minimaalsete kontrollimeetmeteta.
Tehisintellekti loodud aruannete kvaliteedinõuded
Uues dokumentatsioonis on terve osa pühendatud tehisintellektiga toetatud aruannete kirjutamisele. Hooldusmeeskondade korduv kaebus on, et paljud neist aruannetest saabuvad... ülepaisutatud, üleliigsete selgitustega ja vähese keskendumisega olulistele andmetele, mis raskendab selle lugemist ja liigitamist.
Esiteks palutakse, et aruanded oleksid lühike, selge ja lihtsas tekstisMeeskond ei soovita kasutada selliseid vorminguid nagu Markdown, kaunistusi või keerulisi struktuure, mis ei pea meililistides ahelvastuste puhul hästi vastu. Idee seisneb selles, et sõnumi edastamisel või tsiteerimisel ei läheks info kaotsi ja tekst ei muutuks loetamatuks plokiks.
Sisu osas on soovitatav alustada ... Lihtne kokkuvõte, mis näitab mõjutatud faili või alamsüsteemi, mõjutatud versioone ja vea jälgitavat mõju.Sealt edasi saab lisada üksikasju, kuid alati eesmärgiga hõlbustada kiiret lugemist, mis võimaldab teil otsustada, kas rike on prioriteetne või kuulub väiksemate probleemide kategooriasse.
Teine oluline aspekt on see, kuidas mõju kirjeldatakse. Kerneli arendajad hoiatavad, et paljud tehisintellekti loodud aruanded... Nad kipuvad teoreetilisi tagajärgi liialdama.hüpoteetiliste stsenaariumide aheldamine, mis ei arvesta projekti tegeliku ohumudeliga. Keeruliste rünnakunarratiivide loomise asemel palutakse osalejatel jääda kontrollitavate faktide juurde, näiteks selgitada konkreetselt, milliseid lisavõimalusi kasutaja standardselt konfigureeritud süsteemis saaks.
Juhend läheb isegi nii kaugele, et soovitab, et tehisintellekti tööriist ise peaks võimaluse korral Linuxi ohumudeli dokumentatsiooni eelnevalt läbi lugema. viia oma järeldused vastavusse projektis juba kehtestatud kriteeriumidegaEesmärk on vähendada arusaamatusi ja takistada automatiseeritud aruandlusel piiratud mõjuga vea muutmist väidetavalt kriitiliseks haavatavuseks ilma igasuguse tegeliku aluseta.
Mängijad, plaastrid ja terve mõistus automatiseerimise ajastul
Lisaks rikke kirjeldamisele keskendub dokumentatsioon ka praktilisematele aspektidele: Mängijate ja plaastrite genereerimine ja valideerimine tehisintellekti abilPaljud tänapäevased tööriistad suudavad luua väikeseid testprogramme või skripte, mis vea käivitavad ja soovitavad selle parandamiseks koodimuudatusi, kuid need ei tee seda alati usaldusväärselt.
Kernel nõuab, et enne aruande saatmist Uurija peab isiklikult kontrollima, et mängija töötab kirjeldatud viisil.Kui jada ei käivita tõrget või kui tehisintellekt ei suuda genereerida reprodutseeritavat meetodit, on aruande kehtivus tõsiselt ohustatud. Tulemuste avaldamine ilma selle kinnituseta lisab ainult müra ja raiskab hooldajate aega.
Paigalduste osas toob tekst esile, et paljud tehisintellektid on veelgi paremad. koodi kirjutamine, mis hindab selle mõjuSeetõttu julgustatakse nende tööriistade kasutajaid paluma neil mitte ainult probleemi tuvastada, vaid ka lahendust pakkuda. Siiski rõhutatakse, et enne arenduse meililistidele esitamist tuleb tulemus käsitsi üle vaadata ja testida.
Juhend on üheselt mõistetav juhtudel, kui plaastrit ei saa testida, kuna see sõltub eksootiline riistvara, praktiliselt väljasurnud võrguprotokollid või äärmiselt haruldased konfiguratsioonidKui viga ilmneb vaid nii marginaalses keskkonnas, et keegi ei saa seda kergesti valideerida, on väga tõenäoline, et sellel puudub vastav turvanõrkuse kategooria ja see ei tohiks privaatkanali aega tarbida.
Paranduse pakkumisel tuletab projekt kasutajatele meelde, et see peab vastama kerneli paranduse esitamise standardsetele juhistele, sealhulgas sildile „Parandused:”, mis näitab konkreetset commit'i, mis vea põhjustasSamuti on soovitatav kasutada tervet mõistust: kui mõjutatud faili pole rohkem kui aasta muudetud ja seda haldab üks inimene, võib meil olla tegemist komponendiga, millel on väga vähe tegelikke kasutajaid, näiteks vanad riistvaradraiverid või aegunud failisüsteemid.
Sellistel juhtudel on soovitus selge: kui probleem on tühine, kergesti tuvastatav ja sellel pole tüüpilistes keskkondades ilmset mõju, Kõige mõistlikum lähenemisviis on tegeleda sellega otse avalike arendusnimekirjade kaudu. ja mitte turvalisusele pühendatud nimekirjas. Sel viisil reserveeritakse kõige tundlikumad ressursid potentsiaalselt tõsiste tagajärgedega intsidentide jaoks.
Fuzzingu ajastust tehisintellekti laviinini: õppetunnid tasuta tarkvara jaoks
Praegune olukord meenutab mõnevõrra ajastut, mil hakkasid kasutama fuzz-tööriistad nagu Syzkaller pommitab kerneli poolautomaatselt tuvastatud vigade aruannetegaSel ajal pidi kogukond õppima seda pidevat leidude voogu oma arendusprotsessi integreerima, ilma et see igapäevast tööd segaks.
Midagi sarnast juhtub tehisintellektiga, aga teisel skaalal. Nüüd ei ole automatiseeritud mitte ainult vigade põhjustavate sisendite genereerimine, vaid ka... aruannete endi koostamine, koodi staatiline analüüs ja paranduste pakkumineSee kiirendab vigade leidmist, aga kui neid korralikult ei filtreerita ja tähtsuse järjekorda ei seata, siis mitmekordistab see ka meilide, paralleelsete arutelude ja ootuste arvu kerneli meeskonna võimekuse kohta.
Linuxi ökosüsteemis endas on selle nähtuse hindamisel nüansse. Teine oluline kerneli hooldaja Greg Kroah-Hartman on välja toonud, et Tehisintellekti loodud aruanded on kiiresti muutunud peaaegu alati jamast väärtuslikeks panusteks.See optimistlikum vaade eksisteerib koos Torvaldsi murega duplikaatide liigse arvu ja turvanimekirja ülekoormuse pärast.
Vastuolu asemel peegeldavad need seisukohad sama lapsendamisprotsessi kaks pooltÜhelt poolt võib tehisintellekt olla väga kasulik reaalsete probleemide leidmiseks; teisalt aga, kui paljud inimesed käitavad samu tööriistu sama koodi kallal ja esitavad tulemused filtreerimata, on koosmõjuks raskesti hallatav teadete „torm“.
Näite vastutustundlikust automatiseerimise kasutamisest pakub Kroah-Hartman ise, kes on avaldanud kohandatud süsteeme kerneli skannimiseks, paranduste genereerimiseks, testimiseks ja esitamiseks projekti standardse töövoo järgi. Peamine on see, et nendel juhtudel Arendaja võtab kogu elutsükli eest täieliku tehnilise vastutuse, selle asemel, et lihtsalt edasi saata ilma tööriista tulemust kontrollimata.
Kogu Linux 7.1 ümber käiv liikumine näitab projekti, mis tehisintellekti eitamise asemel on hoopis... kohandades oma protsesse nii, et automatiseerimine toimiks turvalisuse kasuks, mitte vastuKehtestades haavatavuse määratlemiseks rangemad kriteeriumid, nõudes kontrollitavaid lihtteksti aruandeid ja julgustades tehisintellekti panustama paranduste genereerimisse ja testimisse, püüab kernel kaitsta hooldajate aega, vähendada müra ja suunata jõupingutused vigadele, mis võivad tegelikult tootmissüsteeme kahjustada.