Kees Cook, a kernel.org korábbi főrendszergazdája és az Ubuntu Security Team vezetője, aki jelenleg a Google-nál dolgozik az Android és a ChromeOS biztonságáért, aggodalmának adott hangot a kernel stabil ágaiban lévő hibák javításának jelenlegi folyamata miatt. Hetente körülbelül száz javítás kerül be a stabil ágakba, és a következő kiadás változásbefogadási ablakának bezárása után megközelíti az ezret (a karbantartók az ablak bezárásáig tartják a javításokat, majd a „ -rc1” egyszerre teszik közzé a felhalmozottakat), ami túl sok és sok munkát igényel a Linux kernel alapú karbantartási termékekhez.
Keys szerint a kernel hibáival való munka folyamata nem kap kellő figyelmet, és a kernelnek hiányzik legalább 100 további fejlesztője az összehangolt munkához ezen a területen. A fő kernelfejlesztők rendszeresen javítják a hibákat, de nincs garancia arra, hogy ezek a javítások átkerülnek a harmadik felek által használt kernelváltozatokra. A Linux kernelen alapuló különféle termékek felhasználóinak nincs módjuk arra sem, hogy szabályozzák, mely hibákat javítsák ki, és melyik kernelt használnak az eszközeiken. Végső soron a gyártók felelősek termékeik biztonságáért, de a javítások stabil kernelágakban való közzétételének igen nagy intenzitása miatt választás elé kerültek - portolja az összes javítást, szelektíven portolja a legfontosabbakat, vagy figyelmen kívül hagyja az összes javítást. .
Az optimális megoldás az lenne, ha csak a legfontosabb javításokat és sebezhetőségeket migrálnák, de a fő probléma az ilyen hibák elkülönítése az általános áramlástól. A legtöbb felbukkanó probléma a C nyelv használatának következménye, ami nagy körültekintést igényel a memóriával és a mutatókkal való munka során. Tovább rontja a helyzetet, hogy sok potenciális sebezhetőségi javítás nem rendelkezik CVE-azonosítóval, vagy a javítás közzététele után valamivel CVE-azonosítót rendel hozzá. Ilyen környezetben a gyártóknak nagyon nehéz elkülöníteni a kisebb javításokat a fontos biztonsági problémáktól. A statisztikák szerint a sérülékenységek több mint 40%-át javítják a CVE hozzárendelése előtt, és átlagosan három hónap telik el a javítás kiadása és a CVE hozzárendelése között (azaz eleinte a javítást úgy tekintik, mint rendszeres hiba, de csak néhány hónap múlva derül ki, hogy a sérülékenységet javították).
Ennek eredményeként a sebezhetőségeket javító külön ág nélkül, és anélkül, hogy egy adott probléma biztonsági kapcsolatáról tájékoztatást kapnának, a Linux kernelen alapuló termékek gyártói folyamatosan átvihetik az összes javítást a legújabb stabil ágakból. Ez a munka azonban sok munkát igényel, és a vállalatok ellenállásába ütközik, mert félnek a regresszív változásoktól, amelyek megzavarhatják a termék normál működését.
Emlékezzünk vissza, Linus Torvalds szerint minden hiba fontos, és a sebezhetőségeket nem szabad elkülöníteni a más típusú hibáktól, és külön magasabb prioritású kategóriába sorolni. Ezt a véleményt az magyarázza, hogy egy átlagos fejlesztő számára, aki nem specializálódott biztonsági kérdésekre, nem egyértelmű a kapcsolat a javítás és a potenciális sebezhetőség között (sok javítás esetében csak egy külön audit teszi lehetővé annak megértését, hogy azok biztonsággal kapcsolatosak. ). Linus szerint a Linux disztribúciókban a kernelcsomagok karbantartásáért felelős csapatok biztonsági szakértőit be kell vonni a javítások általános folyamából származó lehetséges sebezhetőségek azonosításába.
Kees Cook úgy véli, hogy az egyetlen megoldás a kernelbiztonság ésszerű, hosszú távú költségek melletti fenntartására, ha a vállalatok áthelyezik a javítások helyi kernelbeépítésekre történő portolásában részt vevő mérnököket egy közös, összehangolt erőfeszítésbe a javítások és a sebezhetőségek fenntartása érdekében a fő kernelben (felfelé). ). Jelenlegi formájában sok gyártó nem a legújabb kernelverziókat használja termékeiben, és házon belül viszi vissza a javításokat, pl. Kiderült, hogy a különböző cégek mérnökei megkettőzik egymás munkáját, és ugyanazt a problémát oldják meg.
Például, ha 10 vállalat, mindegyik egy-egy mérnökkel ugyanazokat a javításokat háttérportálva, átrendelné ezeket a mérnököket az upstream hibák kijavítására, akkor egy javítás helyett 10 különböző hibát javíthatnának ki a közös előny érdekében, vagy csatlakozhatnának a javasolt áttekintéshez. módosításokat, és megakadályozza, hogy hibás kód kerüljön a kernelbe. Erőforrásokat lehetne fordítani a kód tesztelésére és elemzésére szolgáló új eszközök létrehozására is, amelyek lehetővé tennék az újra és újra felbukkanó gyakori hibaosztályok korai felismerését.
Kees Cook azt is javasolja, hogy aktívabban alkalmazzák az automatizált és zavaros tesztelést közvetlenül a kernelfejlesztési folyamatban, folyamatos integrációs rendszereket használva, és felhagyva az e-mailen keresztüli archaikus fejlesztéskezeléssel. Jelenleg a hatékony tesztelést nehezíti, hogy a fő tesztelési folyamatok elkülönülnek a fejlesztéstől, és a kiadások kialakulása után következnek be. A Keys olyan nyelvek használatát is javasolta, amelyek magasabb szintű biztonságot nyújtanak, mint például a Rust, a hibák számának csökkentése érdekében.
Forrás: opennet.ru