Három évvel azután, hogy egy biztonsági kutató és csapata egy új Linux Security Module, a TSEM bevezetését javasolta a kernelbe, a kérdés ismét reflektorfénybe került. A javasolt LSM akkor nem jutott be a fő kernelágba, azóta pedig érdemi visszajelzés vagy részletes iránymutatás sem érkezett a fejlesztők felé. A kutató most nyilvánosan jelezte elégedetlenségét a levelezőlistákon, és felvetette, hogy ha nem tisztázódik a helyzet, az ügyet akár a Linux Foundation Technical Advisory Board elé is viheti. A probléma lényege szerinte nem pusztán a TSEM elutasításában rejlik, hanem abban, hogy nincs világosan dokumentálva, miként kellene új LSM-eket megfelelő formában benyújtani és elfogadtatni.
Tartalomjegyzék
Linus Torvalds határozott álláspontja
A TSEM egy általános biztonsági modellezési keretrendszerként készült, amely különösen a gépi tanulásra és a viselkedésalapú biztonsági megközelítésekre építene. A fejlesztők állítása szerint a beküldött fejlesztések az elmúlt három évben érdemi technikai átvizsgálás nélkül maradtak, miközben konkrét kritikák is érték a kód szerkezetét, például azt, hogy egyes alapvető struktúrákat és definíciókat egyetlen nagy patchben vezettek be. A csapat többször kért iránymutatást az LSM alrendszer karbantartójától arra vonatkozóan, hogyan kellene egy teljesen új kódbázist megfelelően felépíteni a kernelhez, ám állításuk szerint erre nem kaptak választ.
A vita valódi súlyát Linus Torvalds reakciója adta meg. A kernel fő karbantartója nyíltan kijelentette, hogy már így is túl sok Linux Security Module létezik, és a sokféleség régen átbillent abba az állapotba, ahol inkább problémát és töredezettséget okozott mint érdemi hasznot. Szerinte ha egy fejlesztő nem tudja meggyőzni az LSM-alrendszer közösségét és karbantartóit a kódja létjogosultságáról, akkor őt sem fogja. Torvalds úgy látja, hogy a biztonsági szakemberek többsége meg van győződve a saját modelljük felsőbbrendűségéről, miközben egymással sem értenek egyet, ennek eredményeként pedig egymást átfedő, párhuzamos megoldások sora került be a kernelbe az évek során.
Torvalds szerint a megoldás nem újabb biztonsági modellek bevezetése lenne, hanem a meglévők konszolidálása és egységesebb használata. Úgy fogalmazott, hogy nem kíván sem döntőbíró, sem „a józan ész hangja” lenni ebben a kérdésben, és nem érzi feladatának azt sem, hogy minden új LSM-vitában állást foglaljon. A válasza egyszerre volt pragmatikus és türelmetlen hangvételű, ami jól tükrözi a kernel biztonsági ökoszisztémájával kapcsolatos régóta fennálló frusztrációját.
Nyílt pálya vagy irányított fejlődés?
Torvalds megszólalását nem hagyták válasz nélkül. A TSEM fejlesztője hangsúlyozta, hogy nem közvetlen beavatkozást kértek, hanem világos, dokumentált folyamatot. Szerinte éppen Torvalds lenne az egyetlen, aki egyértelmű iránymutatással lezárhatná a kérdést, akár úgy is, hogy kimondja: új LSM-eket a kernel többé nem fogad be. Ez szerinte vagy kiszorítaná a biztonsági fejlesztést a kernelből, vagy más technológiák, például az eBPF irányába terelné azt.
A válasz már jóval élesebb hangot üt meg, és attól tart, hogy világos szabályok nélkül a Linux ugyanarra az útra léphet, mint egykor a kereskedelmi Unix rendszerek, amelyek vállalati érdekek mentén feldarabolódtak. A fejlesztő szerint a nyílt hozzájárulás lehetősége alapérték, és ennek hiányában a Linux ökoszisztémája is töredezetté válhat.
