Eski kernel.org CSO'su ve şu anda Android ve ChromeOS'un güvenliğini sağlamak için Google için çalışan Ubuntu Güvenlik Ekibi'nin lideri Kees Cook, çekirdeğin kararlı dallarındaki hataları düzeltmeye yönelik mevcut süreçle ilgili endişelerini dile getirdi. Her hafta, kararlı dallara yaklaşık yüz düzeltme dahil edilir ve bir sonraki sürümdeki değişiklikleri kabul etmek için pencereyi kapattıktan sonra bine yaklaşır (bakıcılar düzeltmeleri pencere kapatılıncaya kadar tutar ve "-rc1" oluşturulduktan sonra birikmiş olanları bir kerede yayınlamak), bu çok fazla ve Linux çekirdeğini temel alan bakım ürünleri için çok fazla emek gerektiriyor.
Keys'e göre çekirdekteki hatalarla çalışma sürecine gereken özen gösterilmiyor ve çekirdekte bu alanda koordineli çalışma için en az 100 ek geliştirici bulunmuyor. Çekirdek çekirdek geliştiricileri hataları düzenli olarak düzeltir, ancak bu düzeltmelerin üçüncü taraflarca kullanılan çekirdek değişkenlerine taşınacağının garantisi yoktur. Linux çekirdeğini temel alan çeşitli ürünlerin kullanıcılarının, cihazlarında hangi hataların düzeltildiğini ve hangi çekirdeğin kullanıldığını kontrol etme imkanı da yoktur. Satıcılar, ürünlerinin güvenliğinden nihai olarak sorumludur, ancak kararlı çekirdek dallarındaki çok yüksek yama oranı nedeniyle, tüm yamaları desteklemek, en önemlilerini seçerek taşımak veya tüm yamaları göz ardı etmek arasında bir seçim yapmakla karşı karşıya kaldılar.
En iyi çözüm yalnızca en önemli düzeltmeleri ve güvenlik açıklarını taşımak olacaktır, ancak bu tür hataları genel akıştan yalıtmak asıl sorundur. Ortaya çıkan sorunların çoğu, bellek ve işaretçilerle uğraşırken büyük özen gerektiren C dilinin kullanımından kaynaklanmaktadır. Daha da kötüsü, birçok potansiyel güvenlik açığı düzeltmesi CVE tanımlayıcılarıyla birlikte sağlanmıyor veya yama yayınlandıktan bir süre sonra böyle bir tanımlayıcı alınmıyor. Bu koşullar altında üreticilerin küçük düzeltmeleri büyük güvenlik sorunlarından ayırması çok zordur. İstatistiklere göre, güvenlik açıklarının %40'ından fazlası bir CVE atanmadan önce düzeltiliyor ve bir yamanın yayınlanması ile bir CVE'nin atanması arasındaki ortalama gecikme üç ay (yani ilk başta yama ortak bir hata olarak algılanıyor) hata, ancak yalnızca birkaç ay sonra güvenlik açığının giderildiği anlaşılıyor).
Sonuç olarak, Linux çekirdeği tabanlı ürün üreticileri, güvenlik açıklarına yönelik düzeltmelerin bulunduğu ayrı bir şubeye sahip olmadan ve belirli bir sorunun güvenlik bağlantısı hakkında bilgi almadan, tüm düzeltmeleri sürekli olarak yeni kararlı şubelerden aktarmak zorunda kalır. Ancak bu iş çok fazla emek gerektiriyor ve ürünün normal işleyişini bozabilecek gerileyici değişiklikler korkusu nedeniyle şirketlerde dirençle karşılaşıyor.
Linus Torvalds'a göre tüm hataların önemli olduğunu ve güvenlik açıklarının diğer hata türlerinden ayrılıp ayrı, yüksek öncelikli bir kategoriye tahsis edilmemesi gerektiğini hatırlayın. Bu görüş, güvenlik konularında uzman olmayan sıradan bir geliştirici için bir düzeltme ile potansiyel bir güvenlik açığı arasındaki bağlantının açık olmamasıyla açıklanmaktadır (çoğu düzeltme için yalnızca ayrı bir denetim bunların güvenlikle ilgili olduğunu anlamanıza izin verir) ). Linus'a göre, olası güvenlik açıklarını genel yama akışından izole etmek, Linux dağıtımlarındaki çekirdek paketlerinin bakımından sorumlu ekiplerdeki güvenlik ekiplerine kalmış.
Kees Cook, çekirdeğin güvenliğini makul bir uzun vadeli maliyetle korumanın tek çözümünün, şirketlerin yamaları yerel çekirdek yapılarına taşımayla ilgilenen mühendisleri, yukarı akış çekirdeğindeki yamaları ve güvenlik açıklarını korumak için işbirliği içinde ve koordineli bir şekilde çalışmak üzere taşımaları olduğuna inanıyor. Mevcut haliyle birçok üretici, ürünlerinde en son çekirdek sürümünü ve destek düzeltmelerini kendi başına kullanmamaktadır; farklı şirketlerdeki mühendislerin birbirlerinin işini kopyalayarak aynı sorunu çözdüğü ortaya çıktı.
Örneğin, her biri aynı düzeltmeleri destekleyen bir mühendise sahip 10 şirket, bu mühendisleri hataları yukarı yönde düzeltmeye yönlendirirse, bir düzeltmeyi taşımak yerine, ortak fayda için 10 farklı hatayı düzeltebilir veya önerilen değişikliklerin incelemesine katılabilirler. ve Buggy kodunun çekirdeğe dahil edilmesini önleyin. Kaynaklar ayrıca test ve kod analizi için yeni araçlar oluşturmaya da ayrılabilir; bu, erken bir aşamada tekrar tekrar ortaya çıkan tipik hata sınıflarının otomatik olarak tanımlanmasına olanak tanır.
Kees Cook ayrıca otomatik ve bulanıklaştırma testlerinin doğrudan temel geliştirme sürecinde daha aktif kullanılmasını, sürekli entegrasyon sistemlerinin kullanılmasını ve e-posta yoluyla eski geliştirme yönetiminin terk edilmesini öneriyor. Şu anda etkili testler, ana test süreçlerinin geliştirmeden ayrılması ve sürümlerin oluşturulmasından sonra gerçekleşmesi nedeniyle sekteye uğramaktadır. Keys ayrıca hataları azaltmak için Rust gibi daha güvenli dillerin kullanılmasını da önerdi.
Kaynak: opennet.ru