Kees Cook, antic administrador del sistema en cap de kernel.org i líder de l'equip de seguretat d'Ubuntu que ara treballa a Google per protegir Android i ChromeOS, va expressar la seva preocupació pel procés actual de correcció d'errors a les branques estables del nucli. Cada setmana, s'inclouen al voltant d'un centenar de correccions a les branques estables i, després de tancar la finestra per acceptar canvis a la propera versió, s'acosta a mil (els mantenedors mantenen les correccions fins que la finestra es tanca i després de la formació de " -rc1” publiquen els acumulats alhora), que és massa i requereix molta mà d'obra per als productes de manteniment basats en el nucli Linux.
Segons Keys, el procés de treballar amb errors al nucli no rep l'atenció deguda i el nucli no té com a mínim 100 desenvolupadors addicionals per al treball coordinat en aquesta àrea. Els principals desenvolupadors del nucli solucionen errors regularment, però no hi ha cap garantia que aquestes correccions es traslladin a variants del nucli utilitzades per tercers. Els usuaris de diversos productes basats en el nucli de Linux tampoc tenen cap manera de controlar quins errors es corregeixen i quin nucli s'utilitza als seus dispositius. En última instància, els fabricants són els responsables de la seguretat dels seus productes, però amb l'alta intensitat de publicació de correccions en branques estables del nucli, es van enfrontar a una opció: portar totes les solucions, portar selectivament les més importants o ignorar totes les solucions. .
La solució òptima seria migrar només les correccions i vulnerabilitats més importants, però aïllar aquests errors del flux general és el principal problema. El major nombre de problemes que apareixen són conseqüència de l'ús del llenguatge C, que requereix molta cura quan es treballa amb memòria i punters. Per empitjorar les coses, molts pedaços de vulnerabilitat potencial no es proporcionen amb un identificador CVE o se'ls assigna un identificador CVE un temps després de la publicació del pedaç. En un entorn així, és molt difícil per als fabricants separar les correccions menors dels problemes de seguretat importants. Segons les estadístiques, més del 40% de les vulnerabilitats es solucionen abans que s'assigni un CVE i, de mitjana, el retard entre el llançament d'una correcció i l'assignació d'un CVE és de tres mesos (és a dir, al principi la correcció es percep com un error habitual, però només després de diversos mesos queda clar que la vulnerabilitat s'ha solucionat).
Com a resultat, sense una branca separada amb solucions per a vulnerabilitats i sense rebre informació sobre la connexió de seguretat d'un problema particular, els fabricants de productes basats en el nucli de Linux es deixen transferir contínuament totes les correccions de les últimes branques estables. Però aquesta feina requereix molta mà d'obra i s'enfronta a resistències a les empreses per por a l'aparició de canvis regressius que puguin alterar el funcionament normal del producte.
Recordem que, segons Linus Torvalds, tots els errors són importants i les vulnerabilitats no s'han de separar d'altres tipus d'errors i assignar-los a una categoria de prioritat més alta. Aquesta opinió s'explica pel fet que per a un desenvolupador normal que no s'especialitza en problemes de seguretat, la connexió entre una correcció i una vulnerabilitat potencial no és òbvia (per a moltes solucions, només una auditoria separada permet entendre que es refereixen a la seguretat). ). Segons Linus, els especialistes en seguretat dels equips responsables del manteniment dels paquets del nucli a les distribucions de Linux haurien de participar en la identificació de vulnerabilitats potencials del flux general de pedaços.
Kees Cook creu que l'única solució per mantenir la seguretat del nucli a un cost raonable a llarg termini és que les empreses traslladin els enginyers implicats en portar les correccions a les versions locals del nucli en un esforç conjunt i coordinat per mantenir les solucions i les vulnerabilitats al nucli principal (aigües amunt). ). En la seva forma actual, molts fabricants no utilitzen les últimes versions del nucli als seus productes i donen suport a les correccions internes, és a dir. Resulta que els enginyers de diferents empreses dupliquen el treball dels altres, resolent el mateix problema.
Per exemple, si 10 empreses, cadascuna amb un enginyer que retroportà les mateixes solucions, reassignaven aquests enginyers a la correcció d'errors a l'aigües amunt, aleshores, en lloc de retroportar una correcció, podrien corregir 10 errors diferents per al benefici comú o participar en la revisió de les propostes. canvis i evitar que el codi amb errors s'inclogui al nucli. També es podrien dedicar recursos a crear noves eines per provar i analitzar codi que permetrien la detecció precoç de classes comunes d'errors que apareixen una i altra vegada.
Kees Cook també suggereix utilitzar de manera més activa les proves automatitzades i difuses directament en el procés de desenvolupament del nucli, utilitzar sistemes d'integració contínua i abandonar la gestió arcaica del desenvolupament per correu electrònic. Actualment, les proves efectives es veuen obstaculitzades pel fet que els processos de proves principals estan separats del desenvolupament i es produeixen després de la formació dels llançaments. Keys també recomana utilitzar idiomes que proporcionen un nivell de seguretat més alt, com Rust, a l'hora de desenvolupar per reduir el nombre d'errors.
Font: opennet.ru