Si Kees Cook, dating punong tagapangasiwa ng system ng kernel.org at pinuno ng Ubuntu Security Team na ngayon ay nagtatrabaho sa Google upang ma-secure ang Android at ChromeOS, ay nagpahayag ng pagkabahala tungkol sa kasalukuyang proseso ng pag-aayos ng mga bug sa mga matatag na sangay ng kernel. Bawat linggo, humigit-kumulang isang daang mga pag-aayos ang kasama sa mga matatag na sanga, at pagkatapos na sarado ang window para sa pagtanggap ng mga pagbabago sa susunod na release, ito ay lumalapit sa isang libo (ang mga maintainer ay humahawak ng mga pag-aayos hanggang sa sarado ang window, at pagkatapos ng pagbuo ng " -rc1" ini-publish nila ang mga naipon nang sabay-sabay), na napakarami at nangangailangan ng maraming paggawa para sa mga produkto ng pagpapanatili batay sa Linux kernel.
Ayon sa Keys, ang proseso ng pagtatrabaho sa mga error sa kernel ay hindi binibigyang pansin at ang kernel ay kulang ng hindi bababa sa 100 karagdagang mga developer para sa coordinated na trabaho sa lugar na ito. Ang pangunahing mga developer ng kernel ay regular na nag-aayos ng mga bug, ngunit walang garantiya na ang mga pag-aayos na ito ay dadalhin sa mga variant ng kernel na ginagamit ng mga third party. Ang mga gumagamit ng iba't ibang produkto batay sa Linux kernel ay wala ring paraan upang makontrol kung aling mga bug ang naayos at kung aling kernel ang ginagamit sa kanilang mga device. Sa huli, ang mga tagagawa ay may pananagutan para sa seguridad ng kanilang mga produkto, ngunit sa napakataas na intensity ng pag-publish ng mga pag-aayos sa mga matatag na sanga ng kernel, sila ay nahaharap sa isang pagpipilian - i-port ang lahat ng mga pag-aayos, piliing i-port ang pinakamahalaga, o huwag pansinin ang lahat ng mga pag-aayos .
Ang pinakamainam na solusyon ay ang paglipat lamang ng pinakamahalagang pag-aayos at kahinaan, ngunit ang paghihiwalay ng mga naturang error mula sa pangkalahatang daloy ay ang pangunahing problema. Ang pinakamalaking bilang ng mga problemang lumalabas ay bunga ng paggamit ng wikang C, na nangangailangan ng mahusay na pangangalaga kapag nagtatrabaho sa memorya at mga pointer. Ang masama pa nito, maraming potensyal na vulnerability patch ang hindi binibigyan ng CVE identifier, o itinalaga ang CVE identifier ilang oras pagkatapos ma-publish ang patch. Sa ganitong kapaligiran, napakahirap para sa mga tagagawa na paghiwalayin ang mga menor de edad na pag-aayos mula sa mahahalagang isyu sa seguridad. Ayon sa mga istatistika, higit sa 40% ng mga kahinaan ay naayos bago italaga ang isang CVE, at sa karaniwan, ang pagkaantala sa pagitan ng pagpapalabas ng isang pag-aayos at pagtatalaga ng isang CVE ay tatlong buwan (ibig sabihin, sa una ang pag-aayos ay itinuturing bilang isang regular na bug, ngunit pagkatapos lamang ng ilang buwan ay magiging malinaw na ang kahinaan ay naayos na).
Bilang resulta, nang walang hiwalay na sangay na may mga pag-aayos para sa mga kahinaan at walang natatanggap na impormasyon tungkol sa koneksyon sa seguridad ng isang partikular na problema, ang mga tagagawa ng mga produkto batay sa Linux kernel ay naiwan upang patuloy na ilipat ang lahat ng mga pag-aayos mula sa pinakabagong mga matatag na sangay. Ngunit ang gawaing ito ay nangangailangan ng maraming paggawa at nahaharap sa paglaban sa mga kumpanya dahil sa takot sa paglitaw ng mga regressive na pagbabago na maaaring makagambala sa normal na operasyon ng produkto.
Alalahanin natin na ayon kay Linus Torvalds, lahat ng mga error ay mahalaga at ang mga kahinaan ay hindi dapat ihiwalay sa iba pang mga uri ng mga error at inilalaan sa isang hiwalay na kategorya ng mas mataas na priyoridad. Ang opinyon na ito ay ipinaliwanag sa pamamagitan ng katotohanan na para sa isang ordinaryong developer na hindi nagdadalubhasa sa mga isyu sa seguridad, ang koneksyon sa pagitan ng isang pag-aayos at isang potensyal na kahinaan ay hindi halata (para sa maraming mga pag-aayos, isang hiwalay na pag-audit lamang ang ginagawang posible na maunawaan na ang mga ito ay may kinalaman sa seguridad. ). Ayon kay Linus, ang mga espesyalista sa seguridad mula sa mga koponan na responsable sa pagpapanatili ng mga kernel package sa mga pamamahagi ng Linux ay dapat na kasangkot sa pagtukoy ng mga potensyal na kahinaan mula sa pangkalahatang stream ng mga patch.
Naniniwala si Kees Cook na ang tanging solusyon sa pagpapanatili ng seguridad ng kernel sa isang makatwirang pangmatagalang gastos ay para sa mga kumpanya na ilipat ang mga inhinyero na kasangkot sa pag-port ng mga pag-aayos sa mga lokal na kernel build sa isang magkasanib, coordinated na pagsisikap upang mapanatili ang mga pag-aayos at mga kahinaan sa pangunahing kernel (upstream ). Sa kasalukuyang anyo nito, maraming mga tagagawa ang hindi gumagamit ng pinakabagong mga bersyon ng kernel sa kanilang mga produkto at i-backport ang mga pag-aayos sa loob ng bahay, i.e. Lumalabas na ang mga inhinyero sa iba't ibang kumpanya ay duplicate ang trabaho ng bawat isa, na nilulutas ang parehong problema.
Halimbawa, kung 10 kumpanya, bawat isa ay may isang inhinyero na nag-backport ng parehong mga pag-aayos, na muling italaga ang mga inhinyero na iyon sa pag-aayos ng mga bug sa upstream, sa halip na mag-backport ng isang pag-aayos, maaari silang mag-ayos ng 10 iba't ibang mga bug para sa karaniwang benepisyo o sumali sa pagsusuri ng iminungkahing mga pagbabago at maiwasan ang buggy code na maisama sa kernel. Ang mga mapagkukunan ay maaari ding italaga sa paglikha ng mga bagong tool para sa pagsubok at pagsusuri ng code na magpapahintulot sa maagang pagtuklas ng mga karaniwang klase ng mga error na paulit-ulit na lumalabas.
Iminumungkahi din ni Kees Cook ang mas aktibong paggamit ng automated at fuzzing na pagsubok nang direkta sa proseso ng pagbuo ng kernel, gamit ang tuluy-tuloy na mga sistema ng integration at pag-abandona sa archaic development management sa pamamagitan ng email. Sa kasalukuyan, ang epektibong pagsubok ay nahahadlangan ng katotohanan na ang mga pangunahing proseso ng pagsubok ay pinaghihiwalay mula sa pag-unlad at nangyayari pagkatapos na mabuo ang mga paglabas. Inirerekomenda din ng mga key ang paggamit ng mga wikang nagbibigay ng mas mataas na antas ng seguridad, gaya ng Rust, kapag umuunlad upang mabawasan ang bilang ng mga error.
Pinagmulan: opennet.ru