ગૂગલના કીઝ કૂકે લિનક્સ કર્નલમાં બગ્સ પર કામ કરવાની પ્રક્રિયાને આધુનિક બનાવવા માટે હાકલ કરી હતી

Kees Cook, kernel.org ના ભૂતપૂર્વ ચીફ સિસ્ટમ એડમિનિસ્ટ્રેટર અને Ubuntu સુરક્ષા ટીમના નેતા જેઓ હવે Android અને ChromeOS ને સુરક્ષિત કરવા માટે Google પર કામ કરે છે, કર્નલની સ્થિર શાખાઓમાં બગ્સ સુધારવાની વર્તમાન પ્રક્રિયા વિશે ચિંતા વ્યક્ત કરી. દર અઠવાડિયે, સ્થિર શાખાઓમાં લગભગ સો ફિક્સનો સમાવેશ કરવામાં આવે છે, અને આગામી પ્રકાશનમાં ફેરફારો સ્વીકારવા માટેની વિંડો બંધ થઈ જાય તે પછી, તે એક હજાર સુધી પહોંચે છે (જાળવણીકર્તાઓ જ્યાં સુધી વિન્ડો બંધ ન થાય ત્યાં સુધી ફિક્સને પકડી રાખે છે, અને "ની રચના પછી. -rc1” તેઓ સંચિતને એક જ સમયે પ્રકાશિત કરે છે), જે ઘણા બધા છે અને Linux કર્નલ પર આધારિત જાળવણી ઉત્પાદનો માટે ઘણી મજૂરીની જરૂર છે.

કીઝ મુજબ, કર્નલમાં ભૂલો સાથે કામ કરવાની પ્રક્રિયા પર યોગ્ય ધ્યાન આપવામાં આવતું નથી અને કર્નલ પાસે આ ક્ષેત્રમાં સંકલિત કાર્ય માટે ઓછામાં ઓછા 100 વધારાના વિકાસકર્તાઓનો અભાવ છે. મુખ્ય કર્નલ વિકાસકર્તાઓ નિયમિતપણે ભૂલોને ઠીક કરે છે, પરંતુ ત્યાં કોઈ ગેરેંટી નથી કે આ સુધારાઓ તૃતીય પક્ષો દ્વારા ઉપયોગમાં લેવાતા કર્નલ વેરિઅન્ટ્સ પર લઈ જવામાં આવશે. Linux કર્નલ પર આધારિત વિવિધ ઉત્પાદનોના વપરાશકર્તાઓ પાસે પણ તેમના ઉપકરણોમાં કઈ ભૂલો સુધારાઈ છે અને કઈ કર્નલનો ઉપયોગ થાય છે તે નિયંત્રિત કરવાનો કોઈ રસ્તો નથી. આખરે, ઉત્પાદકો તેમના ઉત્પાદનોની સુરક્ષા માટે જવાબદાર છે, પરંતુ સ્થિર કર્નલ શાખાઓમાં પ્રકાશન સુધારાઓની ખૂબ જ ઊંચી તીવ્રતા સાથે, તેઓને એક પસંદગીનો સામનો કરવો પડ્યો હતો - તમામ ફિક્સેસને પોર્ટ કરો, સૌથી મહત્વપૂર્ણને પસંદગીપૂર્વક પોર્ટ કરો અથવા તમામ ફિક્સેસને અવગણો. .

શ્રેષ્ઠ ઉકેલ માત્ર સૌથી મહત્વપૂર્ણ સુધારાઓ અને નબળાઈઓને સ્થાનાંતરિત કરવાનો હશે, પરંતુ આવી ભૂલોને સામાન્ય પ્રવાહથી અલગ પાડવી એ મુખ્ય સમસ્યા છે. સૌથી મોટી સંખ્યામાં સમસ્યાઓ કે જે પોપ અપ થાય છે તે C ભાષાના ઉપયોગનું પરિણામ છે, જેને મેમરી અને પોઈન્ટર્સ સાથે કામ કરતી વખતે ખૂબ કાળજી લેવાની જરૂર છે. બાબતોને વધુ ખરાબ કરવા માટે, ઘણા સંભવિત નબળાઈ પેચો CVE ઓળખકર્તા સાથે પ્રદાન કરવામાં આવતા નથી, અથવા પેચ પ્રકાશિત થયાના અમુક સમય પછી CVE ઓળખકર્તા સોંપવામાં આવે છે. આવા વાતાવરણમાં, નિર્માતાઓ માટે મહત્વપૂર્ણ સુરક્ષા મુદ્દાઓથી નાના સુધારાઓને અલગ કરવા ખૂબ જ મુશ્કેલ છે. આંકડા મુજબ, CVE સોંપવામાં આવે તે પહેલાં 40% થી વધુ નબળાઈઓ નિશ્ચિત કરવામાં આવે છે, અને સરેરાશ રીતે ફિક્સના પ્રકાશન અને CVEની સોંપણી વચ્ચેનો વિલંબ ત્રણ મહિનાનો છે (એટલે ​​​​કે, શરૂઆતમાં ફિક્સ તરીકે માનવામાં આવે છે. નિયમિત બગ, પરંતુ કેટલાક મહિનાઓ પછી જ તે સ્પષ્ટ થાય છે કે નબળાઈ ઠીક કરવામાં આવી છે).

પરિણામે, નબળાઈઓ માટેના ફિક્સેસ સાથેની અલગ શાખા વિના અને કોઈ ચોક્કસ સમસ્યાના સુરક્ષા કનેક્શન વિશે માહિતી પ્રાપ્ત કર્યા વિના, Linux કર્નલ પર આધારિત ઉત્પાદનોના ઉત્પાદકો નવીનતમ સ્થિર શાખાઓમાંથી તમામ સુધારાઓને સતત સ્થાનાંતરિત કરવા માટે બાકી છે. પરંતુ આ કાર્ય માટે ઘણી મહેનતની જરૂર પડે છે અને ઉત્પાદનની સામાન્ય કામગીરીને વિક્ષેપિત કરી શકે તેવા પ્રતિગામી ફેરફારોના ઉદભવના ભયને કારણે કંપનીઓમાં પ્રતિકારનો સામનો કરવો પડે છે.

ચાલો યાદ કરીએ કે લિનસ ટોરવાલ્ડ્સ અનુસાર, બધી ભૂલો મહત્વપૂર્ણ છે અને નબળાઈઓને અન્ય પ્રકારની ભૂલોથી અલગ ન કરવી જોઈએ અને અલગ ઉચ્ચ અગ્રતા શ્રેણીમાં ફાળવવી જોઈએ. આ અભિપ્રાય એ હકીકત દ્વારા સમજાવવામાં આવ્યો છે કે સામાન્ય વિકાસકર્તા કે જેઓ સુરક્ષા મુદ્દાઓમાં નિષ્ણાત નથી, ફિક્સ અને સંભવિત નબળાઈ વચ્ચેનું જોડાણ સ્પષ્ટ નથી (ઘણા સુધારાઓ માટે, માત્ર એક અલગ ઓડિટ એ સમજવું શક્ય બનાવે છે કે તેઓ સુરક્ષાની ચિંતા કરે છે. ). લિનસના જણાવ્યા મુજબ, Linux વિતરણોમાં કર્નલ પેકેજો જાળવવા માટે જવાબદાર ટીમોના સુરક્ષા નિષ્ણાતો પેચના સામાન્ય પ્રવાહમાંથી સંભવિત નબળાઈઓને ઓળખવામાં સામેલ હોવા જોઈએ.

કીઝ કૂક માને છે કે વાજબી લાંબા ગાળાના ખર્ચે કર્નલ સુરક્ષા જાળવવાનો એકમાત્ર ઉકેલ એ છે કે કંપનીઓ સ્થાનિક કર્નલ બિલ્ડ્સમાં ફિક્સેસ પોર્ટિંગમાં સામેલ એન્જિનિયરોને મુખ્ય કર્નલ (અપસ્ટ્રીમ) માં સુધારાઓ અને નબળાઈઓ જાળવવા માટે સંયુક્ત, સંકલિત પ્રયાસમાં ખસેડે છે. ). તેના વર્તમાન સ્વરૂપમાં, ઘણા ઉત્પાદકો તેમના ઉત્પાદનોમાં નવીનતમ કર્નલ સંસ્કરણોનો ઉપયોગ કરતા નથી અને ઘરના સુધારાને બેકપોર્ટ કરે છે, એટલે કે. તે તારણ આપે છે કે વિવિધ કંપનીઓના એન્જિનિયરો સમાન સમસ્યાને હલ કરીને, એકબીજાના કામની નકલ કરે છે.

ઉદાહરણ તરીકે, જો 10 કંપનીઓ, જેમાં પ્રત્યેક એક એન્જિનિયર સમાન ફિક્સ બેકપોર્ટ કરે છે, તે એન્જિનિયરોને અપસ્ટ્રીમમાં બગ્સ ફિક્સ કરવા માટે ફરીથી સોંપવામાં આવે છે, તો પછી એક ફિક્સને બેકપોર્ટ કરવાને બદલે, તેઓ સામાન્ય લાભ માટે 10 અલગ-અલગ ભૂલોને ઠીક કરી શકે છે અથવા સૂચિતની સમીક્ષામાં જોડાઈ શકે છે. ફેરફારો કરે છે અને બગ્ગી કોડને કર્નલમાં સમાવવાથી અટકાવે છે. સંસાધનો કોડના પરીક્ષણ અને પૃથ્થકરણ માટે નવા સાધનો બનાવવા માટે પણ સમર્પિત થઈ શકે છે જે વારંવાર ઉદભવતી ભૂલોના સામાન્ય વર્ગોને વહેલા શોધવાની મંજૂરી આપશે.

કીઝ કૂક કર્નલ ડેવલપમેન્ટ પ્રક્રિયામાં સીધા જ સ્વચાલિત અને ફઝિંગ ટેસ્ટિંગનો વધુ સક્રિય રીતે ઉપયોગ કરવાનું સૂચન કરે છે, સતત એકીકરણ પ્રણાલીનો ઉપયોગ કરીને અને ઈમેલ દ્વારા પ્રાચીન વિકાસ વ્યવસ્થાપનને છોડી દે છે. હાલમાં, અસરકારક પરીક્ષણ એ હકીકત દ્વારા અવરોધાય છે કે મુખ્ય પરીક્ષણ પ્રક્રિયાઓને વિકાસથી અલગ કરવામાં આવે છે અને પ્રકાશનોની રચના થયા પછી થાય છે. કીઝે ભૂલોની સંખ્યા ઘટાડવા માટે વિકાસ કરતી વખતે રસ્ટ જેવી ઉચ્ચ સ્તરની સુરક્ષા પ્રદાન કરતી ભાષાઓનો ઉપયોગ કરવાની પણ ભલામણ કરી છે.

સોર્સ: opennet.ru