In un recente post pubblicato sul blog dell’azienda CIQ, madre del progetto Rocky Linux di cui costantemente parliamo nell’ambito delle alternative a Red Hat Enterprise Linux, Jeremy Allison si è posto una semplice domanda: le distribuzioni che applicano solo poche e selezionate patch al Kernel Linux lo rendono più sicuro?

La risposta sembra essere decisamente no.

L’assunto di partenza è questa affermazione, parte dell’approccio dei vendor che l’articolo analizza:

These are the git mines. Working here we see the talented engineers of [INSERT YOUR DISTRO HERE] carefully selecting only the most polished and pristine open source patches from the raw upstream open source Linux kernel in order to create the secure distribution kernel you depend on in your business.

Queste sono le miniere di Git. Lavorando qui vediamo i talentuosi ingegneri di [INSERISCI LA TUA DISTRO QUI] selezionare attentamente solo le patch open source più raffinate e incontaminate dal kernel Linux open source upstream grezzo per creare il kernel di distribuzione sicuro da cui dipendi nella tua attività.

All’apparenza è un’affermazione sensatissima.

Partendo dal Kernel “vanilla”, ossia quello rilasciato direttamente dal progetto guidato da Linus Torvalds, le uniche integrazioni che vengono effettuate sono selezionatissime, dipendentemente dalle esigenze. Il problema è che il white paper dice l’esatto contrario.

Quel che emerge non potrebbe essere più chiaro:

• Un Kernel “congelato” è un kernel non sicuro e l’insicurezza raddoppia se il Kernel viene rilasciato più avanti nel tempo.
• Il numero di bug noti in un Kernel “congelato” cresce nel tempo e la crescita del numero di bug accelera addirittura nel tempo.
• Ci sono troppi bug aperti in questi Kernel perché sia possibile analizzarli o addirittura classificarli.

Quindi no, l’approccio non pare decisamente quello corretto e ci sono i numeri a dimostrarlo, infatti nei recenti Kernel relativi a RHEL 8 il conteggio dei bug è chiarissimo: in RHEL 8.6 sono 5.034, in RHEL 8.7 invece 4.767, mentre in RHEL 8.8 sono 4.594.

Insomma, aggiornare (o rimanere aggiornati) conviene.

Lontano dal voler criticare chi lavora affinché tutto funzioni al meglio, Allison sottolinea come il problema in questione sia di difficile soluzione, e come in ogni caso questa passi dalla collaborazione delle varie entità con il lavoro upstream fatto sul Kernel Linux.

Ed a pensarci questo è proprio il principio del tanto discusso e poco applicato Shift-Left, ossia l’inserimento delle questioni sulla sicurezza il prima possibile nel ciclo di sviluppo. Poiché, questo studio ne è la dimostrazione, lavorare mediante backport è certamente meno efficiente oltre che più complicato.