Kees Cook a Google-től felhívta a figyelmet a Linux kernel hibajavító folyamatának modernizálására

Kis Kuk (Kees Cook), a former chief system administrator of kernel.org and leader of the Ubuntu Security Team, now working at Google on securing Android and ChromeOS, expressed concerns about the current process of bug fixes in stable kernel branches. Approximately a hundred fixes are included in the stable branches weekly, and after the close of the update window for the next release, it approaches a thousand (maintainers hold fixes until the window closes, then publish the accumulated ones after forming '-rc1'), which is too much and requires significant effort to maintain products based on the Linux kernel.

According to Kees, the process of managing errors in the kernel does not receive adequate attention, and at least 100 additional developers are needed for coordinated work in this area. Core kernel developers regularly fix bugs, but there are no guarantees that these fixes will be carried over to kernel variants used by third-party manufacturers. Users of various products based on the Linux kernel also do not have the ability to monitor which bugs have been fixed and which kernel is being used in their devices. Ultimately, manufacturers are responsible for the security of their products, but in the face of a very high intensity of publication of fixes in stable kernel branches, they are faced with a choice — carry over all fixes, selectively port the most important ones, or ignore all fixes.

Optimizált megoldás lenne csak a legfontosabb javítások és biztonsági rések átvitele, de a probléma legfőbb része éppen az, hogy nehéz kiemelni ezeket a hibákat a sokaságból. A legtöbb felmerülő probléma a C nyelv használatának következménye, ami nagy precizitást igényel a memória és a pointerek kezelésénél. A helyzetet tovább súlyosbítja, hogy sok potenciális biztonsági rés javítása nem rendelkezik CVE azonosítókkal, vagy csak a javítás közzététele után kap hasonló azonosítót egy idő elteltével. Ilyen körülmények között a gyártóknak nagyon nehéz megkülönböztetni a másodlagos javításokat a fontos, biztonságra vonatkozó problémáktól. Statisztikák szerint a potenciális biztonsági rések több mint 40%-át javítják a CVE által való azonosítás előtt, és az javítás kiadása és a CVE azonosító hozzárendelése között átlagosan három hónap telik el (azaz kezdetben a javítást egy egyszerű hibaként kezelik, de csak hónapokkal később derül ki, hogy biztonsági résről van szó).

Ennek eredményeként, mivel nincs külön szál a biztonsági rések javításaira, és nem kapnak információt a problémák biztonsággal való kapcsolatáról, a Linux kernel alapú termékeket gyártó cégeknek folyamatosan át kell vinniük az összes javítást az új stabil ágakból. Az ilyen munka azonban nagy erőforrás-igénnyel jár, és a cégek ellenállásába ütközik, mivel attól tartanak, hogy regresszív változások léphetnek fel, amelyek megzavarhatják a termék normális működését.

Emlékeztetünk arra, hogy Linus Torvalds véleménye szerint minden hiba fontos, és a biztonsági réseket nem szabad elkülöníteni más hibáktól, vagy egy külön, magasabb prioritású kategóriába sorolni. Ez a vélemény azért alakult ki, mert a hagyományos fejlesztő, aki nem szakosodott a biztonsági kérdésekre, számára nem nyilvánvaló a javítás és a potenciális biztonsági rés közötti kapcsolat (sok javítás esetében külön audit elvégzése szükséges ahhoz, hogy megértsük, hogy azok biztonsági vonatkozásúak). Linus szerint a potenciális biztonsági rések a javítások közül való kiemelésével biztonsági szakértőknek kell foglalkozniuk, akik a Linux disztribúciók kernel csomagjainak támogatásáért felelős csapatok tagjai.

Kis Kuk úgy véli, hogy a mag biztonságának fenntartásához a hosszú távú ésszerű költségek mellett a megoldás az, ha a cégek átirányítják azokat az mérnököket, akik a javítások helyi magváltozatokba történő portolásával foglalkoznak, hogy közösen és összehangolt munkával a fő mag (upstream) javításainak és problémáinak kezelésére összpontosítsanak. Jelenlegi állapotában sok gyártó az általuk használt termékekben nem a legfrissebb magverziókat alkalmazza, és saját hatáskörben visszamenőleges javításokat végez, ami azt jelenti, hogy a különböző cégeknél dolgozó mérnökök párhuzamosan végzik az ugyanazokkal a problémákkal kapcsolatos munkát.

Például, ha 10 cég van, ahol mindegyikben egy mérnök foglalkozik a visszamenőleges javításokkal, és ezek az mérnökök átváltanak az upstream hibajavítására, akkor egy javítás portolása helyett 10 különböző hibát javíthatnának a közérdek érdekében, vagy csatlakozhatnának a javasolt módosítások felülvizsgálatához, hogy elkerüljék a hibás kód magba való bekerülését. Az erőforrásokat új tesztelő és kódelemző eszközök létrehozására is lehetne fordítani, amelyek korai fázisban automatikusan észlelik azokat a gyakori hibakategóriákat, amelyek újra és újra felmerülnek.

Kis Kuk azt is javasolja, hogy aktívan alkalmazzák az automatizált és fuzzing-tesztelést közvetlenül a mag fejlesztése során, folyamatos integrációs rendszereket használjanak, és mondjanak le az elavult, e-mailen keresztüli fejlesztéskezelésről. Jelenleg a hatékony tesztelés útjában áll, hogy a tesztelési folyamatok a fejlesztéstől el vannak választva, és már a kiadások kialakítása után történnek. Kis javasolta továbbá, hogy a hibák számának csökkentése érdekében olyan nyelveket alkalmazzanak a fejlesztés során, amelyek biztosítják a magas szintű biztonságot, mint például a Rust.

Forrás: opennet.ru