Kees Cook, iama ĉefa sistemadministranto de kernel.org kaj gvidanto de la Sekureca Teamo de Ubuntu kiu nun laboras ĉe Google por sekurigi Android kaj ChromeOS, esprimis zorgon pri la nuna procezo de ripari erarojn en la stabilaj branĉoj de la kerno. Ĉiusemajne, ĉirkaŭ cent korektoj estas inkluzivitaj en la stabilaj branĉoj, kaj post kiam la fenestro por akcepti ŝanĝojn en la sekva eldono estas fermita, ĝi alproksimiĝas al mil (la prizorgantoj tenas la korektojn ĝis la fenestro estas fermita, kaj post la formado de " -rc1” ili publikigas la amasigitajn samtempe), kio estas tro multe kaj postulas multan laboron por prizorgaj produktoj bazitaj sur la Linukso-kerno.
Laŭ Ŝlosiloj, la procezo labori kun eraroj en la kerno ne ricevas konvenan atenton kaj al la kerno mankas almenaŭ 100 pliaj programistoj por kunordigita laboro en ĉi tiu areo. La ĉefaj kernaj programistoj regule riparas erarojn, sed ne estas garantio, ke ĉi tiuj korektoj estos transdonitaj al kernaj variantoj uzataj de triaj partioj. Uzantoj de diversaj produktoj bazitaj sur la Linukso-kerno ankaŭ havas nenian manieron kontroli kiuj eraroj estas riparitaj kaj kiu kerno estas uzata en siaj aparatoj. Finfine, fabrikistoj respondecas pri la sekureco de siaj produktoj, sed kun la tre alta intenseco de publikigado de korektoj en stabilaj kernaj branĉoj, ili alfrontis elekton - porti ĉiujn korektojn, selekteme porti la plej gravajn aŭ ignori ĉiujn korektojn. .
La optimuma solvo estus migri nur la plej gravajn korektojn kaj vundeblecojn, sed izoli tiajn erarojn de la ĝenerala fluo estas la ĉefa problemo. La plej granda nombro da problemoj kiuj aperas estas sekvo de uzado de la C-lingvo, kiu postulas grandan zorgon kiam oni laboras kun memoro kaj montriloj. Por plimalbonigi la aferojn, multaj eblaj vundeblecoj ne estas provizitaj per CVE-identigilo, aŭ estas asignitaj CVE-identigilo iom da tempo post kiam la peceto estas publikigita. En tia medio, estas tre malfacile por fabrikantoj apartigi negravajn korektojn de gravaj sekurecaj problemoj. Laŭ statistiko, pli ol 40% de vundeblecoj estas riparitaj antaŭ ol CVE estas asignita, kaj averaĝe la prokrasto inter la liberigo de riparo kaj la asigno de CVE estas tri monatoj (t.e., komence la riparo estas perceptita kiel regula cimo, sed nur post kelkaj monatoj evidentiĝas, ke la vundebleco estis riparita).
Kiel rezulto, sen aparta branĉo kun korektoj por vundeblecoj kaj sen ricevi informojn pri la sekureca konekto de aparta problemo, fabrikistoj de produktoj bazitaj sur la Linukso-kerno restas senĉese transdoni ĉiujn korektojn de la plej novaj stabilaj branĉoj. Sed ĉi tiu laboro postulas multan laboron kaj alfrontas reziston en kompanioj pro timo pri la apero de regresaj ŝanĝoj, kiuj povus interrompi la normalan funkciadon de la produkto.
Ni rememoru, ke laŭ Linus Torvalds, ĉiuj eraroj estas gravaj kaj vundeblecoj ne devas esti apartigitaj de aliaj specoj de eraroj kaj asignitaj al aparta pli alta prioritata kategorio. Ĉi tiu opinio estas klarigita per la fakto, ke por ordinara programisto, kiu ne specialiĝas pri sekurecaj aferoj, la ligo inter riparo kaj ebla vundebleco ne estas evidenta (por multaj korektoj, nur aparta revizio ebligas kompreni, ke ili koncernas sekurecon. ). Laŭ Linus, sekurecaj specialistoj de la teamoj respondecaj pri konservado de kernaj pakoj en Linukso-distribuoj devus esti implikitaj en identigado de eblaj vundeblecoj el la ĝenerala fluo de flikoj.
Kees Cook opinias, ke la sola solvo por konservi kernan sekurecon je akceptebla longperspektiva kosto estas, ke kompanioj movu la inĝenierojn implikitajn en portado de korektoj al lokaj kernaj konstruoj en komunan, kunordigan klopodon konservi korektojn kaj vundeblecojn en la ĉefa kerno (kontraŭflue). ). En ĝia nuna formo, multaj produktantoj uzas ne la plej novajn kernversiojn en siaj produktoj kaj retroportas la korektojn endome, t.e. Montriĝas, ke inĝenieroj en malsamaj kompanioj duobligas la laboron de unu la alian, solvante la saman problemon.
Ekzemple, se 10 kompanioj, ĉiu kun unu inĝeniero retroportanta la samajn korektojn, reasignis tiujn inĝenierojn por ripari cimojn en la kontraŭfluo, tiam anstataŭ retroporti unu korekton, ili povus ripari 10 malsamajn erarojn por la komuna avantaĝo aŭ aliĝi al la revizio de proponita. ŝanĝojn kaj malebligas ke bugkodo estu inkluzivita en la kerno. Rimedoj ankaŭ povus esti dediĉitaj al kreado de novaj iloj por testado kaj analizo de kodo, kiuj permesus fruan detekton de oftaj klasoj de eraroj, kiuj aperas denove kaj denove.
Kees Cook ankaŭ sugestas pli aktive uzi aŭtomatigitan kaj fuzigan testadon rekte en la kerna evoluprocezo, uzi kontinuajn integrigajn sistemojn kaj forlasi arkaikan evoluadministradon per retpoŝto. Nuntempe, efika testado estas malhelpita de la fakto, ke la ĉefaj testaj procezoj estas apartigitaj de evoluo kaj okazas post kiam la eldonoj estas formitaj. Ŝlosiloj ankaŭ rekomendis uzi lingvojn kiuj provizas pli altan nivelon de sekureco, kiel Rust, dum evoluado por redukti la nombron da eraroj.
fonto: opennet.ru