Kees Cook, kernel.org saytının keçmiş baş sistem administratoru və hazırda Android və ChromeOS-un təhlükəsizliyini təmin etmək üçün Google-da işləyən Ubuntu Təhlükəsizlik Qrupunun rəhbəri, nüvənin sabit filiallarında mövcud səhvlərin aradan qaldırılması prosesindən narahatlığını ifadə edib. Hər həftə sabit filiallara yüzə yaxın düzəliş daxil edilir və növbəti buraxılışda dəyişiklikləri qəbul etmək üçün pəncərə bağlandıqdan sonra minə yaxınlaşır (təmizləyicilər pəncərə bağlanana qədər düzəlişləri saxlayırlar və " -rc1” yığılanları birdən dərc edirlər), bu həddən artıq çoxdur və Linux nüvəsinə əsaslanan texniki qulluq məhsulları üçün çoxlu əmək tələb edir.
Keysin fikrincə, nüvədə səhvlərlə işləmə prosesinə lazımi diqqət yetirilmir və nüvədə bu sahədə əlaqələndirilmiş iş üçün ən azı 100 əlavə tərtibatçı çatışmır. Əsas nüvə tərtibatçıları müntəzəm olaraq səhvləri düzəldirlər, lakin bu düzəlişlərin üçüncü tərəflər tərəfindən istifadə edilən kernel variantlarına köçürüləcəyinə zəmanət yoxdur. Linux nüvəsinə əsaslanan müxtəlif məhsulların istifadəçilərinin də cihazlarında hansı səhvlərin düzəldildiyini və hansı nüvənin istifadə edildiyini idarə etmək imkanı yoxdur. Nəhayət, istehsalçılar məhsullarının təhlükəsizliyinə cavabdehdirlər, lakin sabit nüvə budaqlarında düzəlişlərin dərc edilməsinin çox yüksək intensivliyi ilə bir seçim qarşısında qaldılar - bütün düzəlişləri portla, seçici olaraq ən vacib olanları köçürün və ya bütün düzəlişlərə məhəl qoymayın. .
Optimal həll yalnız ən vacib düzəlişləri və zəiflikləri köçürmək olardı, lakin bu cür səhvləri ümumi axından təcrid etmək əsas problemdir. Yaranan problemlərin ən çoxu yaddaş və göstəricilərlə işləyərkən böyük diqqət tələb edən C dilindən istifadənin nəticəsidir. Vəziyyəti daha da pisləşdirmək üçün, bir çox potensial zəiflik yamaqları CVE identifikatoru ilə təmin edilmir və ya yamaq dərc edildikdən bir müddət sonra CVE identifikatoru təyin edilir. Belə bir mühitdə istehsalçılar üçün kiçik düzəlişləri mühüm təhlükəsizlik məsələlərindən ayırmaq çox çətindir. Statistikaya görə, zəifliklərin 40%-dən çoxu CVE təyin edilməzdən əvvəl düzəldilir və orta hesabla düzəlişin buraxılması ilə CVE-nin təyin edilməsi arasındakı gecikmə üç aydır (yəni, əvvəlcə düzəliş kimi qəbul edilir). adi bir səhv, lakin yalnız bir neçə aydan sonra zəifliyin düzəldildiyi aydın olur).
Nəticədə, zəifliklər üçün düzəlişləri olan ayrı bir filial olmadan və müəyyən bir problemin təhlükəsizlik bağlantısı haqqında məlumat almadan, Linux nüvəsinə əsaslanan məhsul istehsalçılarına davamlı olaraq bütün düzəlişləri ən son sabit filiallardan köçürmək qalır. Amma bu iş çox əmək tələb edir və məhsulun normal fəaliyyətini poza biləcək reqressiv dəyişikliklərin yaranması qorxusu səbəbindən şirkətlərdə müqavimətlə üzləşir.
Xatırladaq ki, Linus Torvaldsa görə bütün səhvlər vacibdir və zəifliklər digər xəta növlərindən ayrılmamalı və ayrıca yüksək prioritet kateqoriyasına aid edilməməlidir. Bu fikir onunla izah olunur ki, təhlükəsizlik məsələlərində ixtisaslaşmış olmayan adi bir tərtibatçı üçün düzəliş və potensial zəiflik arasındakı əlaqə aydın deyil (bir çox düzəlişlər üçün yalnız ayrıca audit onların təhlükəsizliklə əlaqəli olduğunu başa düşməyə imkan verir. ). Linusun sözlərinə görə, Linux paylamalarında nüvə paketlərinin saxlanmasına cavabdeh olan komandaların təhlükəsizlik mütəxəssisləri ümumi yamaq axınından potensial zəifliklərin müəyyən edilməsinə cəlb edilməlidir.
Kees Cook hesab edir ki, ləpə təhlükəsizliyini ağlabatan uzunmüddətli xərclə təmin etməyin yeganə həlli şirkətlər üçün düzəlişlərin yerli nüvə qurğularına daşınması ilə məşğul olan mühəndisləri əsas nüvədə (yuxarıda) düzəlişləri və zəiflikləri qorumaq üçün birgə, əlaqələndirilmiş səylərə köçürməkdir. ). Mövcud formada bir çox istehsalçı öz məhsullarında ən son kernel versiyalarından istifadə etmir və düzəlişləri evdə dəstəkləyir, yəni. Məlum olub ki, müxtəlif şirkətlərdəki mühəndislər eyni problemi həll edərək bir-birinin işini təkrarlayırlar.
Məsələn, hər birində eyni düzəlişləri təmin edən bir mühəndis olan 10 şirkət, yuxarı axındakı səhvləri düzəltmək üçün həmin mühəndisləri yenidən təyin edərsə, o zaman bir düzəlişi dəstəkləmək əvəzinə, ümumi fayda üçün 10 fərqli səhvi düzəldə bilər və ya təklif olunanların nəzərdən keçirilməsinə qoşula bilər. dəyişikliklər edir və buggy kodunun nüvəyə daxil edilməsinin qarşısını alır. Resurslar həmçinin təkrar-təkrar yaranan ümumi səhv siniflərinin erkən aşkarlanmasına imkan verən kodun sınanması və təhlili üçün yeni alətlərin yaradılmasına da həsr oluna bilər.
Kees Cook həmçinin birbaşa nüvə inkişaf prosesində avtomatlaşdırılmış və qeyri-müəyyən testlərdən daha fəal istifadə etməyi, davamlı inteqrasiya sistemlərindən istifadə etməyi və e-poçt vasitəsilə arxaik inkişaf idarəçiliyindən imtina etməyi təklif edir. Hal-hazırda effektiv testin aparılmasına əsas sınaq proseslərinin inkişafdan ayrılması və buraxılışlar formalaşdıqdan sonra baş verməsi mane olur. Açarlar həmçinin səhvlərin sayını azaltmaq üçün inkişaf etdirərkən Rust kimi daha yüksək təhlükəsizlik səviyyəsini təmin edən dillərdən istifadə etməyi tövsiyə edir.
Mənbə: opennet.ru