Kees Cook-ը՝ kernel.org-ի նախկին գլխավոր համակարգի ադմինիստրատորը և Ubuntu Security Team-ի ղեկավարը, ով այժմ աշխատում է Google-ում՝ Android-ի և ChromeOS-ի ապահովման համար, մտահոգություն է հայտնել միջուկի կայուն ճյուղերում սխալների շտկման ընթացիկ գործընթացի վերաբերյալ: Ամեն շաբաթ մոտ հարյուր ֆիքսումներ են ընդգրկվում կայուն ճյուղերում, և հաջորդ թողարկումում փոփոխություններ ընդունելու պատուհանը փակվելուց հետո այն մոտենում է հազարին (սպասարկողները ֆիքսումները պահում են մինչև պատուհանը փակվի, և ձևավորվելուց հետո « -rc1» նրանք միանգամից հրապարակում են կուտակվածները), որը չափազանց շատ է և մեծ աշխատանք է պահանջում Linux միջուկի վրա հիմնված սպասարկման արտադրանքի համար։
Ըստ Keys-ի, միջուկում սխալների հետ աշխատելու գործընթացին պատշաճ ուշադրություն չի հատկացվում, և միջուկը չունի առնվազն 100 լրացուցիչ մշակող այս ոլորտում համակարգված աշխատանքի համար: Հիմնական միջուկի մշակողները պարբերաբար շտկում են սխալները, սակայն երաշխիք չկա, որ այդ ուղղումները կտեղափոխվեն միջուկի տարբերակներին, որոնք օգտագործվում են երրորդ կողմերի կողմից: Linux-ի միջուկի վրա հիմնված տարբեր ապրանքների օգտատերերը նույնպես հնարավորություն չունեն վերահսկելու, թե որ սխալներն են շտկվում և որ միջուկն է օգտագործվում իրենց սարքերում: Ի վերջո, արտադրողները պատասխանատու են իրենց արտադրանքի անվտանգության համար, բայց կայուն միջուկային ճյուղերում շտկումների հրապարակման շատ մեծ ինտենսիվության դեպքում նրանք ընտրության առաջ կանգնեցին՝ տեղափոխել բոլոր ուղղումները, ընտրովի տեղափոխել ամենակարևորները կամ անտեսել բոլոր ուղղումները։ .
Օպտիմալ լուծումը կլինի միայն ամենակարևոր ուղղումները և խոցելիությունները տեղափոխելը, սակայն հիմնական խնդիրն այդպիսի սխալների մեկուսացումն է ընդհանուր հոսքից: Ամենամեծ թվով խնդիրներ, որոնք հայտնվում են C լեզվի օգտագործման հետևանք են, ինչը մեծ խնամք է պահանջում հիշողության և ցուցիչների հետ աշխատելիս: Իրավիճակն ավելի վատթարացնելու համար, խոցելիության շատ պոտենցիալ պատչեր չեն տրամադրվում CVE նույնացուցիչով կամ նրանց նշանակվում է CVE նույնացուցիչ՝ պատչը հրապարակելուց որոշ ժամանակ անց: Նման միջավայրում արտադրողների համար շատ դժվար է առանձնացնել աննշան ուղղումները անվտանգության կարևոր խնդիրներից: Վիճակագրության համաձայն, խոցելիությունների ավելի քան 40%-ը շտկվում է նախքան CVE-ի նշանակումը, և միջին հաշվով շտկման թողարկման և CVE-ի նշանակման միջև ուշացումը կազմում է երեք ամիս (այսինքն՝ սկզբում շտկումը ընկալվում է որպես սովորական սխալ, բայց միայն մի քանի ամիս անց պարզ է դառնում, որ խոցելիությունը շտկվել է):
Արդյունքում, առանց խոցելիության շտկմամբ առանձին ճյուղի և առանց որոշակի խնդրի անվտանգության կապի մասին տեղեկություններ ստանալու, Linux միջուկի վրա հիմնված արտադրանքի արտադրողներին մնում է շարունակաբար փոխանցել բոլոր ուղղումները վերջին կայուն ճյուղերից: Բայց այս աշխատանքը պահանջում է մեծ աշխատուժ և ընկերություններում բախվում է դիմադրության՝ ռեգրեսիվ փոփոխությունների առաջացման վախի պատճառով, որոնք կարող են խաթարել արտադրանքի բնականոն գործունեությունը:
Հիշենք, որ ըստ Լինուս Տորվալդսի, բոլոր սխալները կարևոր են, և խոցելիությունները չպետք է առանձնացվեն այլ տեսակի սխալներից և հատկացվեն առանձին ավելի առաջնահերթ կատեգորիայի: Այս կարծիքը բացատրվում է նրանով, որ սովորական ծրագրավորողի համար, որը մասնագիտացած չէ անվտանգության հարցերում, շտկման և հնարավոր խոցելիության միջև կապն ակնհայտ չէ (շատ ուղղումների համար միայն առանձին աուդիտը թույլ է տալիս հասկանալ, որ դրանք վերաբերում են անվտանգությանը։ ) Ըստ Լինուսի, Linux բաշխումներում միջուկային փաթեթների պահպանման համար պատասխանատու թիմերի անվտանգության մասնագետները պետք է ներգրավված լինեն կարկատների ընդհանուր հոսքից հնարավոր խոցելիության հայտնաբերման գործում:
Kees Cook-ը կարծում է, որ միջուկի անվտանգությունը ողջամիտ երկարաժամկետ գնով պահպանելու միակ լուծումն այն է, որ ընկերությունները ինժեներներին տեղափոխեն շտկումներ տեղական միջուկի կառուցվածքներ՝ համատեղ, համակարգված ջանքերի մեջ՝ հիմնական միջուկի շտկումներն ու խոցելիությունները պահպանելու համար (վերևում ) Իր ներկայիս տեսքով, շատ արտադրողներ օգտագործում են ոչ վերջին միջուկի տարբերակներն իրենց արտադրանքներում և ներկայացնում են ներքին շտկումները, այսինքն. Պարզվում է, որ տարբեր ընկերությունների ինժեներները կրկնօրինակում են միմյանց աշխատանքը՝ լուծելով նույն խնդիրը։
Օրինակ, եթե 10 ընկերություններ, որոնցից յուրաքանչյուրը նույն ուղղումները ներկայացնում է մեկ ինժեներ, վերահաստատեն այդ ինժեներներին վերին հոսքում սխալները շտկելու համար, ապա մեկ ուղղման փոխարեն նրանք կարող են ուղղել 10 տարբեր սխալներ ընդհանուր շահի համար կամ միանալ առաջարկվող վերանայմանը: փոփոխությունները և կանխելու խելագարված կոդի ներառումը միջուկում: Ռեսուրսները կարող են նաև տրամադրվել կոդի փորձարկման և վերլուծության նոր գործիքների ստեղծմանը, որոնք թույլ կտան վաղաժամ հայտնաբերել սխալների սովորական դասերը, որոնք կրկին ու կրկին հայտնվում են:
Kees Cook-ը նաև առաջարկում է ավելի ակտիվորեն օգտագործել ավտոմատացված և անորոշ թեստավորումն անմիջապես միջուկի մշակման գործընթացում՝ օգտագործելով շարունակական ինտեգրման համակարգեր և հրաժարվել էլփոստի միջոցով հնացած զարգացման կառավարումից: Ներկայումս արդյունավետ թեստավորմանը խոչընդոտում է այն փաստը, որ հիմնական փորձարկման գործընթացները առանձնացված են մշակումից և տեղի են ունենում թողարկումների ձևավորումից հետո: Keys-ը նաև խորհուրդ է տալիս մշակելիս օգտագործել այնպիսի լեզուներ, որոնք ապահովում են անվտանգության ավելի բարձր մակարդակ, ինչպիսին է Rust-ը, սխալների քանակը նվազեցնելու համար:
Source: opennet.ru