ഗൂഗിളിന്റെ കീസ് കുക്ക്, ലിനക്സ് കെർണലിലെ ബഗുകളിൽ പ്രവർത്തിക്കുന്ന പ്രക്രിയയെ നവീകരിക്കാൻ ആവശ്യപ്പെട്ടു.

kernel.org-ന്റെ മുൻ ചീഫ് സിസ്റ്റം അഡ്‌മിനിസ്‌ട്രേറ്ററും Android, ChromeOS എന്നിവ സുരക്ഷിതമാക്കാൻ Google-ൽ ഇപ്പോൾ പ്രവർത്തിക്കുന്ന ഉബുണ്ടു സെക്യൂരിറ്റി ടീമിന്റെ നേതാവുമായ Kees Cook, കേർണലിന്റെ സ്ഥിരതയുള്ള ശാഖകളിലെ ബഗുകൾ പരിഹരിക്കുന്ന നിലവിലെ പ്രക്രിയയെക്കുറിച്ച് ആശങ്ക പ്രകടിപ്പിച്ചു. എല്ലാ ആഴ്‌ചയും, സ്ഥിരതയുള്ള ശാഖകളിൽ നൂറോളം പരിഹാരങ്ങൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, അടുത്ത പതിപ്പിലെ മാറ്റങ്ങൾ സ്വീകരിക്കുന്നതിനുള്ള വിൻഡോ അടച്ചതിനുശേഷം, അത് ആയിരത്തിലേക്ക് അടുക്കുന്നു (വിൻഡോ അടയ്‌ക്കുന്നതുവരെ പരിപാലിക്കുന്നവർ പരിഹാരങ്ങൾ സൂക്ഷിക്കുന്നു, കൂടാതെ രൂപീകരണത്തിന് ശേഷവും " -rc1” അവർ ശേഖരിക്കപ്പെട്ടവ ഒരേസമയം പ്രസിദ്ധീകരിക്കുന്നു), ഇത് വളരെ കൂടുതലാണ്, ലിനക്സ് കേർണൽ അടിസ്ഥാനമാക്കിയുള്ള മെയിന്റനൻസ് ഉൽപ്പന്നങ്ങൾക്ക് വളരെയധികം അധ്വാനം ആവശ്യമാണ്.

കീസ് പറയുന്നതനുസരിച്ച്, കേർണലിലെ പിശകുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്ന പ്രക്രിയയ്ക്ക് വേണ്ടത്ര ശ്രദ്ധ നൽകപ്പെടുന്നില്ല, കൂടാതെ ഈ മേഖലയിലെ ഏകോപിത പ്രവർത്തനത്തിനായി കേർണലിന് കുറഞ്ഞത് 100 അധിക ഡെവലപ്പർമാരെങ്കിലും ഇല്ല. പ്രധാന കേർണൽ ഡെവലപ്പർമാർ പതിവായി ബഗുകൾ പരിഹരിക്കുന്നു, എന്നാൽ ഈ പരിഹാരങ്ങൾ മൂന്നാം കക്ഷികൾ ഉപയോഗിക്കുന്ന കേർണൽ വേരിയന്റുകളിലേക്ക് കൊണ്ടുപോകുമെന്ന് യാതൊരു ഉറപ്പുമില്ല. ലിനക്സ് കേർണലിനെ അടിസ്ഥാനമാക്കിയുള്ള വിവിധ ഉൽപ്പന്നങ്ങളുടെ ഉപയോക്താക്കൾക്ക് അവരുടെ ഉപകരണങ്ങളിൽ ഏതൊക്കെ ബഗുകളാണ് പരിഹരിച്ചിരിക്കുന്നതെന്നും ഏത് കേർണലാണ് ഉപയോഗിക്കുന്നതെന്നും നിയന്ത്രിക്കാൻ മാർഗമില്ല. ആത്യന്തികമായി, നിർമ്മാതാക്കൾ അവരുടെ ഉൽപ്പന്നങ്ങളുടെ സുരക്ഷയ്ക്ക് ഉത്തരവാദികളാണ്, എന്നാൽ സ്ഥിരതയുള്ള കേർണൽ ബ്രാഞ്ചുകളിൽ വളരെ ഉയർന്ന തീവ്രതയുള്ള പരിഹാരങ്ങൾ പ്രസിദ്ധീകരിക്കുന്നതിനാൽ, അവർ ഒരു തിരഞ്ഞെടുപ്പിനെ അഭിമുഖീകരിച്ചു - എല്ലാ പരിഹാരങ്ങളും പോർട്ട് ചെയ്യുക, ഏറ്റവും പ്രധാനപ്പെട്ടവ തിരഞ്ഞെടുത്ത് പോർട്ട് ചെയ്യുക, അല്ലെങ്കിൽ എല്ലാ പരിഹാരങ്ങളും അവഗണിക്കുക .

ഏറ്റവും പ്രധാനപ്പെട്ട പരിഹാരങ്ങളും കേടുപാടുകളും മാത്രം മൈഗ്രേറ്റ് ചെയ്യുക എന്നതാണ് ഒപ്റ്റിമൽ പരിഹാരം, എന്നാൽ പൊതുവായ ഒഴുക്കിൽ നിന്ന് അത്തരം പിശകുകൾ വേർതിരിക്കുന്നത് പ്രധാന പ്രശ്നമാണ്. സി ഭാഷ ഉപയോഗിക്കുന്നതിന്റെ അനന്തരഫലമാണ് പോപ്പ് അപ്പ് ചെയ്യുന്ന ഏറ്റവും വലിയ പ്രശ്‌നങ്ങൾ, മെമ്മറിയും പോയിന്ററുകളും ഉപയോഗിച്ച് പ്രവർത്തിക്കുമ്പോൾ വളരെ ശ്രദ്ധ ആവശ്യമാണ്. കാര്യങ്ങൾ കൂടുതൽ വഷളാക്കാൻ, പല സാധ്യതയുള്ള വൾനറബിലിറ്റി പാച്ചുകളും ഒരു CVE ഐഡന്റിഫയർ നൽകിയിട്ടില്ല, അല്ലെങ്കിൽ പാച്ച് പ്രസിദ്ധീകരിച്ച് കുറച്ച് സമയത്തിന് ശേഷം ഒരു CVE ഐഡന്റിഫയർ അസൈൻ ചെയ്യുന്നു. അത്തരമൊരു പരിതസ്ഥിതിയിൽ, പ്രധാനപ്പെട്ട സുരക്ഷാ പ്രശ്നങ്ങളിൽ നിന്ന് ചെറിയ പരിഹാരങ്ങൾ വേർതിരിക്കുന്നത് നിർമ്മാതാക്കൾക്ക് വളരെ ബുദ്ധിമുട്ടാണ്. സ്ഥിതിവിവരക്കണക്കുകൾ അനുസരിച്ച്, ഒരു CVE അസൈൻ ചെയ്യുന്നതിനുമുമ്പ് 40%-ത്തിലധികം കേടുപാടുകൾ പരിഹരിച്ചിരിക്കുന്നു, കൂടാതെ ഒരു ഫിക്സിൻറെ റിലീസും ഒരു CVE യുടെ അസൈൻമെന്റും തമ്മിലുള്ള ശരാശരി കാലതാമസം മൂന്ന് മാസമാണ് (അതായത്, ആദ്യം ശരിയാക്കുന്നത് ഇങ്ങനെയാണ്. ഒരു സാധാരണ ബഗ്, പക്ഷേ കുറച്ച് മാസങ്ങൾക്ക് ശേഷം മാത്രമേ അപകടസാധ്യത പരിഹരിച്ചുവെന്ന് വ്യക്തമാകൂ).

തൽഫലമായി, കേടുപാടുകൾ പരിഹരിക്കലുകളുള്ള ഒരു പ്രത്യേക ബ്രാഞ്ച് ഇല്ലാതെയും ഒരു പ്രത്യേക പ്രശ്നത്തിന്റെ സുരക്ഷാ കണക്ഷനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കാതെയും, ഏറ്റവും പുതിയ സ്ഥിരതയുള്ള ശാഖകളിൽ നിന്ന് എല്ലാ പരിഹാരങ്ങളും തുടർച്ചയായി കൈമാറാൻ ലിനക്സ് കേർണലിനെ അടിസ്ഥാനമാക്കിയുള്ള ഉൽപ്പന്നങ്ങളുടെ നിർമ്മാതാക്കൾ അവശേഷിക്കുന്നു. എന്നാൽ ഈ ജോലിക്ക് വളരെയധികം അധ്വാനം ആവശ്യമാണ്, കൂടാതെ ഉൽപ്പന്നത്തിന്റെ സാധാരണ പ്രവർത്തനത്തെ തടസ്സപ്പെടുത്തുന്ന റിഗ്രസീവ് മാറ്റങ്ങളുടെ ആവിർഭാവത്തെ ഭയന്ന് കമ്പനികളിൽ പ്രതിരോധം നേരിടുന്നു.

ലിനസ് ടോർവാൾഡ്സ് പറയുന്നതനുസരിച്ച്, എല്ലാ പിശകുകളും പ്രധാനമാണെന്നും കേടുപാടുകൾ മറ്റ് തരത്തിലുള്ള പിശകുകളിൽ നിന്ന് വേർപെടുത്തി ഒരു പ്രത്യേക ഉയർന്ന മുൻഗണനാ വിഭാഗത്തിലേക്ക് അനുവദിക്കരുതെന്നും നമുക്ക് ഓർക്കാം. സുരക്ഷാ പ്രശ്‌നങ്ങളിൽ വൈദഗ്ദ്ധ്യം നേടാത്ത ഒരു സാധാരണ ഡെവലപ്പർക്ക്, ഒരു പരിഹാരവും സാധ്യതയുള്ള അപകടസാധ്യതയും തമ്മിലുള്ള ബന്ധം വ്യക്തമല്ല എന്ന വസ്തുതയാണ് ഈ അഭിപ്രായം വിശദീകരിക്കുന്നത് (പല പരിഹാരങ്ങൾക്കും, ഒരു പ്രത്യേക ഓഡിറ്റ് മാത്രമേ അവർ സുരക്ഷയെ ആശങ്കപ്പെടുത്തുന്നുണ്ടെന്ന് മനസ്സിലാക്കാൻ കഴിയൂ. ). ലിനസ് പറയുന്നതനുസരിച്ച്, ലിനക്സ് വിതരണങ്ങളിൽ കേർണൽ പാക്കേജുകൾ പരിപാലിക്കുന്നതിന് ഉത്തരവാദിത്തമുള്ള ടീമുകളിൽ നിന്നുള്ള സുരക്ഷാ വിദഗ്ധർ പാച്ചുകളുടെ പൊതുവായ സ്ട്രീമിൽ നിന്നുള്ള അപകടസാധ്യതകൾ തിരിച്ചറിയുന്നതിൽ പങ്കാളികളായിരിക്കണം.

ന്യായമായ ദീർഘകാല ചെലവിൽ കേർണൽ സുരക്ഷ നിലനിർത്തുന്നതിനുള്ള ഒരേയൊരു പരിഹാരം കമ്പനികൾ പ്രാദേശിക കേർണൽ ബിൽഡുകളിലേക്ക് പോർട്ടിംഗ് ഫിക്സുകളിൽ ഏർപ്പെട്ടിരിക്കുന്ന എഞ്ചിനീയർമാരെ പ്രധാന കേർണലിലെ (അപ്പ്സ്ട്രീം) പരിഹാരങ്ങളും കേടുപാടുകളും നിലനിർത്തുന്നതിനുള്ള സംയുക്തവും ഏകോപിതവുമായ ശ്രമത്തിലേക്ക് മാറ്റുക എന്നതാണ് എന്ന് കീസ് കുക്ക് വിശ്വസിക്കുന്നു. ). നിലവിലെ രൂപത്തിൽ, പല നിർമ്മാതാക്കളും അവരുടെ ഉൽപ്പന്നങ്ങളിൽ ഏറ്റവും പുതിയ കേർണൽ പതിപ്പുകൾ ഉപയോഗിക്കാറില്ല, കൂടാതെ വീട്ടിനുള്ളിൽ തന്നെയുള്ള പരിഹാരങ്ങൾ ബാക്ക്പോർട്ട് ചെയ്യുന്നു, അതായത്. വ്യത്യസ്ത കമ്പനികളിലെ എഞ്ചിനീയർമാർ പരസ്പരം ജോലി തനിപ്പകർപ്പാക്കി ഒരേ പ്രശ്നം പരിഹരിക്കുന്നുവെന്ന് ഇത് മാറുന്നു.

ഉദാഹരണത്തിന്, 10 കമ്പനികൾ, ഓരോ എഞ്ചിനീയർമാരും ഒരേ പരിഹാരങ്ങൾ ബാക്ക്‌പോർട്ടുചെയ്യുന്നു, ആ എഞ്ചിനീയർമാരെ അപ്‌സ്‌ട്രീമിലെ ബഗുകൾ പരിഹരിക്കുന്നതിന് വീണ്ടും നിയോഗിച്ചാൽ, ഒരു പരിഹാരം ബാക്ക്‌പോർട്ടുചെയ്യുന്നതിന് പകരം, അവർക്ക് പൊതുവായ ആനുകൂല്യത്തിനായി 10 വ്യത്യസ്ത ബഗുകൾ പരിഹരിക്കാം അല്ലെങ്കിൽ നിർദ്ദേശിച്ച അവലോകനത്തിൽ ചേരാം. മാറ്റുകയും ബഗ്ഗി കോഡ് കേർണലിൽ ഉൾപ്പെടുത്തുന്നത് തടയുകയും ചെയ്യുക. കോഡ് പരിശോധിക്കുന്നതിനും വിശകലനം ചെയ്യുന്നതിനുമായി പുതിയ ടൂളുകൾ സൃഷ്‌ടിക്കുന്നതിനും റിസോഴ്‌സുകൾ വിനിയോഗിക്കാവുന്നതാണ്, അത് വീണ്ടും വീണ്ടും ഉയർന്നുവരുന്ന പിശകുകളുടെ പൊതുവായ ക്ലാസുകൾ നേരത്തേ കണ്ടെത്തുന്നതിന് അനുവദിക്കുന്നു.

കേർണൽ ഡെവലപ്‌മെന്റ് പ്രക്രിയയിൽ നേരിട്ട് ഓട്ടോമേറ്റഡ്, ഫസ്സിംഗ് ടെസ്റ്റിംഗ്, തുടർച്ചയായ ഇന്റഗ്രേഷൻ സിസ്റ്റങ്ങൾ ഉപയോഗിക്കൽ, ഇമെയിൽ വഴിയുള്ള ആർക്കൈക് ഡെവലപ്‌മെന്റ് മാനേജ്‌മെന്റ് ഉപേക്ഷിക്കൽ എന്നിവയും കീസ് കുക്ക് നിർദ്ദേശിക്കുന്നു. നിലവിൽ, പ്രധാന ടെസ്റ്റിംഗ് പ്രക്രിയകൾ വികസനത്തിൽ നിന്ന് വേർപെടുത്തുകയും റിലീസുകൾ രൂപപ്പെട്ടതിന് ശേഷം സംഭവിക്കുകയും ചെയ്യുന്നതിനാൽ ഫലപ്രദമായ പരിശോധന തടസ്സപ്പെടുന്നു. പിശകുകളുടെ എണ്ണം കുറയ്ക്കുന്നതിന് വികസിപ്പിക്കുമ്പോൾ, റസ്റ്റ് പോലുള്ള ഉയർന്ന തലത്തിലുള്ള സുരക്ഷ നൽകുന്ന ഭാഷകൾ ഉപയോഗിക്കാനും കീകൾ ശുപാർശ ചെയ്യുന്നു.

അവലംബം: opennet.ru