Si Kees ang nagluluto Gumagawa ako ng isang post sa blog kung saan nagtaas ng mga alalahanin tungkol sa proseso ng pag-aayos ng bug nagpapatuloy sa matatag na mga sangay ng kernel ng Linux at iyon ba banggitin na sa bawat linggo mga isang daang pagwawasto ang kasama sa matatag na mga sangay, na kung saan ay labis at nangangailangan ng maraming pagsisikap upang mapanatili ang mga produktong batay sa kernel ng Linux.
Ayon kay Kees, ang proseso ng paghawak ng error sa kernel ay na-bypass at ang kernel ay kulang ng hindi bababa sa 100 karagdagang mga developer upang gumana sa isang pinag-ugnay na pamamaraan sa lugar na ito. Bilang karagdagan sa pagbanggit na ang mga pangunahing 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 ng third-party.
Sa paggawa nito, binanggit niya na ang mga gumagamit ng iba't ibang mga produktong batay sa kernel ng Linux ay wala ring paraan ng pagkontrol kung aling mga bug ang naayos at kung aling kernel ang ginagamit sa kanilang mga aparato. Sa huli, ang mga vendor ay responsable para sa seguridad ng kanilang mga produkto, ngunit nahaharap sa isang napakataas na rate ng mga patch sa matatag na mga sangay ng kernel, naharap nila ang pagpipilian ng paglipat ng lahat ng mga patch, piliing paglipat ng pinakamahalagang mga, o hindi papansin ang lahat ng mga patch. .
Maaaring ayusin ng mga tagabuo ng upstream kernel ang mga bug, ngunit wala silang kontrol sa kung ano ang pipiliin ng isang downstream vendor na isama sa kanilang mga produkto. Maaaring piliin ng mga end user ang kanilang mga produkto, ngunit sa pangkalahatan ay walang kontrol sa kung aling mga bug ang naayos o kung aling kernel ang ginagamit (isang problema sa sarili nito). Sa huli, responsable ang mga vendor sa pagpapanatiling ligtas ng kanilang mga core ng produkto.
Si Kees ang nagluluto nagmumungkahi na ang pinakamainam na solusyon ay ang paglilipat lamang ng pinakamahalagang mga pag-aayos at kahinaan, ngunit ang pangunahing problema ay paghiwalayin ang mga error na ito mula sa pangkalahatang daloy, dahil ang karamihan sa mga umuusbong na problema ay isang bunga ng paggamit ng wikang C, na nangangailangan ng maraming pangangalaga kapag nagtatrabaho sa memorya at mga payo.
Upang gawing mas masahol pa ang mga bagay, maraming mga potensyal na pag-aayos ng kahinaan ay hindi na-tag sa mga tagakilala ng CVE o hindi nakakatanggap ng isang tagakilala ng CVE ilang oras pagkatapos na mailabas ang patch.
Sa ganitong kapaligiran, napakahirap para sa mga tagagawa na ihiwalay ang mga menor de edad na pag-aayos mula sa pangunahing mga isyu sa seguridad. Ayon sa istatistika, higit sa 40% ng mga kahinaan ang inalis bago ang pagtatalaga ng CVE, at sa average ang pagkaantala sa pagitan ng isang fix release at isang pagtatalaga ng CVE ay tatlong buwan (iyon ay, sa simula, nakikita ang isang solusyon bilang isang pangkaraniwang pagkakamali,
Bilang isang resulta, walang pagkakaroon ng isang hiwalay na sangay na may mga pag-aayos para sa mga kahinaan at hindi pagtanggap ng impormasyon tungkol sa koneksyon sa seguridad ng ito o sa problemang iyon, ang mga tagagawa ng mga produktong batay sa kernel ng Linux ay dapat na patuloy na ilipat ang lahat ng mga pag-aayos ng mga bagong matatag na sangay. Ngunit ang gawaing ito ay masipag sa trabaho at nahaharap sa paglaban mula sa mga kumpanya dahil sa takot sa mga nagbabalik na pagbabago na maaaring makagambala sa normal na pagpapatakbo ng produkto.
Keys Cook naniniwala na ang tanging solusyon upang mapanatili ang kernel na ligtas sa isang makatwirang gastos sa pangmatagalang panahon ay upang ilipat ang mga inhinyero ng patch sa baliw na kernel buildsl upang magtulungan sa isang coordinated na paraan upang mapanatili ang mga patch at kahinaan sa upstream kernel. Tulad ng paninindigan nito, maraming mga vendor ang hindi gumagamit ng pinakabagong mga bersyon ng kernel sa kanilang mga produkto at pag-aayos ng backport sa kanilang sarili, iyon ay, lumalabas na ang mga inhinyero mula sa iba't ibang mga kumpanya ay doble ang gawain ng bawat isa, na nalulutas ang parehong problema.
Halimbawa, kung 10 mga kumpanya, bawat isa ay may isang inhinyero na sumusuporta sa parehong pag-aayos, i-redirect ang mga inhinyero na ito upang ayusin ang mga bug sa paitaas, sa halip na paglipat ng isang pag-aayos, maaari nilang ayusin ang 10 magkakaibang mga bug para sa pangkalahatang benepisyo o magkakasama upang suriin ang mga bug. Iminungkahing mga pagbabago . At iwasang isama ang buggy code sa kernel. Maaari ding magamit ang mga mapagkukunan upang lumikha ng bagong tool sa pagtatasa ng code at mga tool sa pagsubok na awtomatikong makakakita sa isang maagang yugto ng mga tipikal na klase ng error na paulit-ulit na nag-i-crop.
Keys Cook nagmumungkahi din na mas aktibong gumamit ng awtomatikong pagsubok at pag-fuzzing nang direkta sa proseso ng pag-unlad ng kernel, gumamit ng tuluy-tuloy na mga system ng pagsasama at talikuran ang archaic management ng pag-unlad sa pamamagitan ng e-mail.
Fuente: https://security.googleblog.com