Kees Cook, CSO wa zamani wa kernel.org na kiongozi wa Timu ya Usalama ya Ubuntu, ambaye sasa anafanya kazi kwa Google kupata Android na ChromeOS, alionyesha wasiwasi wake kuhusu mchakato wa sasa wa kurekebisha hitilafu katika matawi thabiti ya punje. Kila wiki, karibu marekebisho mia moja yanajumuishwa katika matawi thabiti, na baada ya kufunga dirisha la kukubali mabadiliko kwa toleo linalofuata, inakaribia elfu (watunzaji hushikilia marekebisho hadi dirisha limefungwa, na baada ya kuunda "-rc1" wao. kuchapisha zilizokusanywa mara moja), ambayo ni nyingi sana na inahitaji kazi nyingi kwa bidhaa za matengenezo kulingana na kernel ya Linux.
Kulingana na Keys, mchakato wa kufanya kazi na makosa kwenye kernel haupewi umakini unaostahili na punje inakosa angalau watengenezaji 100 wa ziada kwa kazi iliyoratibiwa katika eneo hili. Wasanidi wa msingi wa kernel hurekebisha hitilafu mara kwa mara, lakini hakuna hakikisho kwamba marekebisho haya yatatumwa kwa vibadala vya kernel vinavyotumiwa na watu wengine. Watumiaji wa bidhaa mbalimbali kulingana na kerneli ya Linux pia hawana njia ya kudhibiti ni hitilafu zipi zimerekebishwa na ni punje gani inatumika katika vifaa vyao. Wachuuzi hatimaye wanawajibikia usalama wa bidhaa zao, lakini kwa kiwango cha juu sana cha kuweka viraka katika matawi ya kernel thabiti, walikabiliwa na chaguo kati ya kurudisha viraka vyote, kwa kuchagua vilivyo muhimu zaidi, au kupuuza mabaka yote.
Suluhisho mojawapo itakuwa kuhamia tu marekebisho muhimu na udhaifu, lakini kutenganisha makosa hayo kutoka kwa mtiririko wa jumla ni tatizo kuu. Shida nyingi zinazojitokeza ni kwa sababu ya matumizi ya lugha ya C, ambayo inahitaji uangalifu mkubwa wakati wa kushughulikia kumbukumbu na viashiria. Ili kufanya mambo kuwa mabaya zaidi, marekebisho mengi yanayoweza kuathiriwa hayajatolewa na vitambulishi vya CVE, au kupokea kitambulisho kama hicho muda baada ya kiraka kuchapishwa. Chini ya hali hiyo, ni vigumu sana kwa wazalishaji kutenganisha marekebisho madogo kutoka kwa masuala makubwa ya usalama. Kulingana na takwimu, zaidi ya 40% ya udhaifu hurekebishwa kabla ya CVE kukabidhiwa, na wastani wa kuchelewa kati ya kutolewa kwa kiraka na ugawaji wa CVE ni miezi mitatu (yaani, mwanzoni, kiraka huchukuliwa kuwa cha kawaida. mdudu, lakini tu baada ya miezi michache inakuwa wazi kuwa hatari imerekebishwa).
Kama matokeo, bila kuwa na tawi tofauti na marekebisho ya udhaifu na bila kupokea habari kuhusu muunganisho wa usalama wa shida fulani, watengenezaji wa bidhaa kulingana na kernel ya Linux huachwa ili kuendelea kuhamisha marekebisho yote kutoka kwa matawi safi thabiti. Lakini kazi hii inahitaji kazi nyingi na inakabiliwa na upinzani katika makampuni kutokana na hofu ya mabadiliko ya regressive ambayo yanaweza kuharibu uendeshaji wa kawaida wa bidhaa.
Kumbuka kwamba, kulingana na Linus Torvalds, makosa yote ni muhimu na udhaifu haupaswi kutenganishwa na aina zingine za makosa na kugawanywa kwa kitengo tofauti cha kipaumbele. Hati hii inafafanuliwa na ukweli kwamba kwa msanidi programu wa kawaida ambaye hana utaalam katika maswala ya usalama, uhusiano kati ya kurekebisha na hatari inayowezekana sio dhahiri (kwa marekebisho mengi, ukaguzi tofauti tu hukuruhusu kuelewa kuwa yanahusiana na usalama. ) Kulingana na Linus, ni juu ya timu za usalama kwenye timu zinazohusika na kudumisha vifurushi vya kernel kwenye usambazaji wa Linux ili kutenganisha udhaifu unaowezekana kutoka kwa mtiririko wa jumla wa kiraka.
Kees Cook anaamini kuwa suluhu la pekee la kuweka punje salama kwa gharama inayokubalika ya muda mrefu ni kwa makampuni kuwahamisha wahandisi wanaohusika katika kuhamisha viraka hadi kwenye miundo ya ndani ya kernel ili kufanya kazi kwa ushirikiano na kwa uratibu kudumisha mabaka na udhaifu katika kernel ya juu ya mkondo. Katika hali yake ya sasa, wazalishaji wengi hawatumii toleo la hivi karibuni la kernel katika bidhaa zao na marekebisho ya backport peke yao, i.e. inageuka kuwa wahandisi katika makampuni tofauti huiga kazi ya kila mmoja, kutatua tatizo sawa.
Kwa mfano, ikiwa kampuni 10, kila moja ikiwa na mhandisi mmoja anayeunga mkono urekebishaji sawa, zitaelekeza wahandisi hao kurekebisha hitilafu juu ya mkondo, basi badala ya kuweka urekebishaji mmoja, zinaweza kurekebisha hitilafu 10 tofauti kwa manufaa ya wote au kujiunga na ukaguzi wa mabadiliko yanayopendekezwa. na zuia msimbo wa buggy kujumuishwa kwenye kernel. Rasilimali pia zinaweza kutumiwa kuunda zana mpya za majaribio na uchanganuzi wa misimbo, ambayo ingeruhusu katika hatua ya awali kutambua kiotomati aina za kawaida za makosa ambayo hujitokeza tena na tena.
Kees Cook pia anapendekeza matumizi amilifu zaidi ya majaribio ya kiotomatiki na fuzzing moja kwa moja katika mchakato wa uundaji msingi, matumizi ya mifumo ya ujumuishaji endelevu na kuachwa kwa usimamizi wa maendeleo ya kizamani kupitia barua pepe. Hivi sasa, upimaji wa ufanisi unazuiwa na ukweli kwamba taratibu kuu za kupima zinatenganishwa na maendeleo na hutokea baada ya kuundwa kwa releases. Vifunguo pia vinapendekezwa kutumia lugha salama zaidi, kama vile Rust, ili kupunguza hitilafu.
Chanzo: opennet.ru