Kees Cook, entinen kernel.orgin pääjärjestelmänvalvoja ja Ubuntu Security Teamin johtaja, joka työskentelee nyt Googlella Androidin ja ChromeOS:n turvaamisessa, ilmaisi huolensa ytimen vakaiden osien virheiden korjausprosessista. Joka viikko noin sata korjausta sisältyy vakaan haaroihin, ja seuraavan julkaisun muutosten hyväksymisikkunan sulkemisen jälkeen se lähestyy tuhatta (ylläpitäjät pitävät korjauksia ikkunan sulkemiseen asti ja "" -rc1” julkaisevat kertyneet kerralla), mikä on liikaa ja vaatii paljon työvoimaa Linux-ytimeen perustuviin ylläpitotuotteisiin.
Keysin mukaan ytimen virheiden käsittelyyn ei kiinnitetä riittävästi huomiota ja ytimeltä puuttuu vähintään 100 lisäkehittäjää koordinoitua työtä varten. Tärkeimmät ytimen kehittäjät korjaavat säännöllisesti bugeja, mutta ei ole takeita siitä, että nämä korjaukset siirretään kolmansien osapuolten käyttämiin ydinversioihin. Erilaisten Linux-ytimeen perustuvien tuotteiden käyttäjillä ei myöskään ole mahdollisuutta hallita, mitkä viat korjataan ja mitä ydintä laitteissaan käytetään. Viime kädessä valmistajat ovat vastuussa tuotteidensa turvallisuudesta, mutta koska korjausten julkaiseminen vakaissa ytimen haaroissa oli erittäin suuri, he joutuivat valinnan eteen - porttia kaikki korjaukset, porttia valikoivasti tärkeimmät tai jättää kaikki korjaukset huomiotta. .
Optimaalinen ratkaisu olisi siirtää vain tärkeimmät korjaukset ja haavoittuvuudet, mutta tällaisten virheiden eristäminen yleisestä virtauksesta on suurin ongelma. Suurin osa esiin tulevista ongelmista johtuu C-kielen käytöstä, mikä vaatii suurta huolellisuutta muistin ja osoittimien kanssa työskentelyssä. Asiaa pahentaa vielä se, että monilla mahdollisilla haavoittuvuuskorjauksilla ei ole CVE-tunnistetta tai niille annetaan CVE-tunniste jonkin aikaa korjaustiedoston julkaisemisen jälkeen. Tällaisessa ympäristössä valmistajien on erittäin vaikea erottaa pienet korjaukset tärkeistä tietoturvaongelmista. Tilastojen mukaan yli 40 % haavoittuvuuksista korjataan ennen CVE:n osoittamista, ja keskimääräinen viive korjauksen julkaisun ja CVE:n osoittamisen välillä on kolme kuukautta (eli aluksi korjauksen katsotaan olevan tavallinen bugi, mutta vasta muutaman kuukauden kuluttua käy selväksi, että haavoittuvuus on korjattu).
Tämän seurauksena Linux-ytimeen perustuvien tuotteiden valmistajat joutuvat jatkuvasti siirtämään kaikki korjaukset viimeisimmiltä vakailta haaroilta ilman erillistä haavoittuvuuksien korjauksia ja ilman tietoa tietyn ongelman tietoturvayhteydestä. Mutta tämä työ vaatii paljon työtä ja kohtaa vastustusta yrityksissä, koska pelätään regressiivisten muutosten syntymistä, jotka voivat häiritä tuotteen normaalia toimintaa.
Muistakaamme, että Linus Torvaldsin mukaan kaikki virheet ovat tärkeitä, eikä haavoittuvuuksia pidä erottaa muun tyyppisistä virheistä ja kohdistaa erilliseen korkeamman prioriteetin kategoriaan. Tämä mielipide selittyy sillä, että tavalliselle kehittäjälle, joka ei ole erikoistunut tietoturvakysymyksiin, korjauksen ja mahdollisen haavoittuvuuden välinen yhteys ei ole ilmeinen (monin korjauksen osalta vain erillisellä auditoinnilla on mahdollista ymmärtää, että ne koskevat turvallisuutta ). Linuksen mukaan Linux-jakelujen ydinpakettien ylläpidosta vastaavien ryhmien tietoturvaasiantuntijoiden tulisi olla mukana tunnistamassa mahdollisia haavoittuvuuksia yleisestä korjaustiedostovirrasta.
Kees Cook uskoo, että ainoa ratkaisu ytimen turvallisuuden ylläpitämiseen kohtuullisin pitkän aikavälin kustannuksin on se, että yritykset siirtävät korjausten siirtämiseen paikallisiin ytimen rakennelmiin osallistuvat insinöörit yhteiseksi, koordinoiduksi pyrkimykseksi ylläpitää korjauksia ja haavoittuvuuksia pääytimessä (ylävirtaan). ). Nykyisessä muodossaan monet valmistajat eivät käytä tuotteissaan uusimpia ydinversioita ja portaat korjaukset talon sisällä, ts. Osoittautuu, että eri yritysten insinöörit toistavat toistensa työtä ja ratkaisevat saman ongelman.
Jos esimerkiksi 10 yritystä, joista jokaisessa on yksi insinööri, joka toimittaa samat korjaukset, määräsi nämä suunnittelijat korjaamaan virheitä alkuvaiheessa, yhden korjauksen siirtämisen sijaan ne voisivat korjata 10 erilaista virhettä yhteisen edun vuoksi tai osallistua ehdotettujen muutosten tarkasteluun. ja estää bugisen koodin sisällyttämisen ytimeen. Resursseja voitaisiin käyttää myös sellaisten uusien työkalujen luomiseen koodin testaamiseen ja analysointiin, jotka mahdollistaisivat yhä uudelleen esiin tulevien yleisten virheluokkien varhaisen havaitsemisen.
Kees Cook ehdottaa myös aktiivisemman automaattisen ja sumean testauksen käyttämistä suoraan ytimen kehitysprosessissa, jatkuvan integrointijärjestelmän käyttöä ja arkaaisen sähköpostin kautta tapahtuvan kehityshallinnan luopumista. Tällä hetkellä tehokasta testausta vaikeuttaa se, että päätestausprosessit ovat erillään kehityksestä ja tapahtuvat julkaisujen muodostumisen jälkeen. Keys suositteli myös käyttämään korkeamman turvallisuustason tarjoavia kieliä, kuten Rust, kehitettäessä virheiden määrän vähentämiseksi.
Lähde: opennet.ru