- Linux çekirdeği güvenlik ekibi, bildirilen zafiyetleri mümkün olduğunca hızlı düzeltip herkese açık depoya birleştirir; ayrıca bir duyuru ya da açıklama yapmaz
- Bu ekip, CVE atamasından sorumlu çekirdek CVE ekibinden ayrıdır; herkes bireysel olarak görev yapar ve kurumsal aidiyetten bağımsız çalışır
- Güvenlik hataları, normal hatalarla tamamen aynı şekilde ele alınır ve düzeltildikten sonra ayrı bir "güvenlik yaması" olarak işaretlenmez
- 7 günden uzun gizlilik ambargosu uygulanmaz; düzeltmelerin çoğu hemen herkese açık hale gelir
- Bu yaklaşım, açık kaynak yapısı ve farklı kullanım ortamları dikkate alınarak benimsenmiştir; çekirdek güvenlik müdahalesinde şeffaflığı ve bağımsızlığı korur
Linux çekirdeği güvenlik ekibinin rolü
- Çekirdek güvenlik ekibi, bildirilen olası güvenlik hatalarını sınıflandırıp hızla düzelten geliştiricilerden oluşan bir gruptur
- Bunlar, Kernel Self-Protection Project tarafından yürütülen uzun vadeli önleyici çalışmalardan ayrı olarak reaktif (reactive) güvenlik müdahalesini üstlenir
- Bildirim süreci basit bir metin e-postası ile yürütülür; HTML, ikili ek dosyalar ve şifreleme kabul edilmez
- Şifreli bildirimler, çok alıcılı yapı nedeniyle işlenemez
- Ekip üyeleri, başlıca çekirdek alt sistemlerini temsil eden temel geliştiricilerdir ve işverenleriyle ya da dışarıdakilerle tartışma içeriğini paylaşamazlar
- Bu bağımsızlık sayesinde farklı ülkelerdeki yasal gerekliliklerden (CRA vb.) bağımsız olarak tutarlı müdahale mümkündür
Hata düzeltme süreci
- Bildirilen hata belirli bir alt sistemle ilgiliyse, çözüm için ilgili alt sistem bakımcısı e-posta tartışmasına dahil edilir
- Sorunların tekrar tekrar yaşandığı alt sistemlerde bakımcı, güvenlik ekibi e-posta listesine doğrudan katılabilir
- Muhbir düzeltme yamasını sağlarsa katkısı teslim edilir; sağlamazsa geliştiriciler sorunu kendileri çözer
- Düzeltme tamamlandığında ana çekirdek dalına ve kararlı (stable) sürümlere birleştirilir
Gizlilik ambargosu politikası
- 7 günü aşan gizlilik süresine izin verilmez; düzeltmelerin çoğu hemen yayımlanır
- Düzeltmeden sonra, muhbir isterse dışarıya duyuru yapabilir; ancak güvenlik ekibinin kendisi hiçbir açıklama yapmaz
- CVE ataması daha sonra çekirdek CVE ekibi tarafından yapılır; güvenlik ekibinden ayrıdır
“Hata sadece hatadır” ilkesi
- 2008'de Linus Torvalds, güvenlik hatalarının ayrı işaretlenmemesi gerektiğini açıkça belirtti
- Gerekçesi, "güvenlik düzeltmesi" ayrımının diğer hataların önemini çarpıtmasıydı
- Tüm hata düzeltmeleri aynı derecede önemlidir ve güvenlik, işlev, performans ayrımı yapılmadan hepsi hemen uygulanır
Güvenlik duyurusu olmamasının nedeni
- Çekirdek seviyesindeki neredeyse her hata potansiyel olarak bir güvenlik sorunu olabilir
- Bellek sızıntısı, hizmet engelleme, bilgi sızması gibi farklı biçimleri vardır
- Açık kaynak yapısı gereği geliştiriciler kullanıcının gerçek çalışma ortamını bilemez
- Bir kullanıcı için önemsiz görünen bir düzeltme, başka bir kullanıcı için kritik bir zafiyet olabilir
- Bu nedenle politika basittir
- Bilinen hataları hemen düzelt
- Düzeltilmiş sürümleri mümkün olan en kısa sürede dağıt
- "Düzeltme sorun çıkarabilir" endişesinden ziyade, bilinen bir hatayı olduğu gibi bırakmak daha büyük risk olarak görülür
Donanım güvenliği sorunları
- Spectre, Meltdown örneklerinde olduğu gibi, hem işletim sistemi hem de donanımı kapsayan sorunlarda istisnai bir süreç gerekir
- Bunun için sınırlı, şifreli bir e-posta listesi üzerinden iş birliği yapılmasını sağlayan 'Hardware Security Policy' hazırlanmıştır
- Bu süreç yavaş ve karmaşıktır, ancak son dönemde birçok donanım hatası bu sürece gerek kalmadan çözülmektedir
- İleride CRA yasasının yanıt süresi gereklilikleri nedeniyle uzun süreli gizlilik daha da zor hale gelebilir
Çekirdek güvenlik ekibinin ortaya çıkışı
- 2005 öncesinde resmî bir güvenlik iletişim kanalı yoktu
- Bildirimler yalnızca geliştiriciler arasındaki gayriresmî ağ üzerinden yapılıyordu
- 2005'te Steve Bergman'ın e-posta önerisiyle tartışmalar başladı ve
Chris Wright, güvenlik iletişim bilgisi ve belgeleri ekleyen yamayı hazırladı
- Ardından merkezi e-posta takma adı (security@kernel.org) resmileştirildi
Güvenlik duyurusu ve ön bildirim eksikliği
- Çekirdek güvenlik ekibi hiçbir türde güvenlik duyurusu ya da ön bildirim listesi işletmez
- CVE kimliği ataması çekirdek CVE ekibi tarafından yürütülür; güvenlik ekibi buna dahil olmaz
- Ön bildirim listesi talepleri çoktur, ancak sızıntı riski ve kamusallık ilkesi nedeniyle böyle bir liste yoktur
- Yaklaşım şu şekildedir: "Eğer bir hükümet buna izin veriyorsa, o proje muhtemelen gerçekte kullanılmıyordur."
1 yorum
Hacker News yorumları
Son zamanlarda Linux masaüstünde sanallaştırma deneyimini pürüzsüz hale getiren teknolojiler hızla gelişiyor
GPU sürücüleri Mesa üzerinden native context desteği sunuyor ve Wayland'da misafir–ana makine arasındaki paylaşım özellikleri de iyileşiyor
Eskiden sommelier veya wayland-proxy-virtwl gibi karmaşık protokol ayrıştırmaları gerekiyordu, ama artık wl-cross-domain-proxy projesi bunu düzgün şekilde hayata geçiriyor
Bu özellikleri kullanan VMM'ler arasında muvm, bunları bir araya getiren çözüm olarak da munix var
Duraklatıp aktardıktan sonra yeniden devam ettirerek sanal makineyi taşımak harika olurdu
Bu yüzden Red Hat 2025'te de hâlâ önemli
Bu tür altyapı çalışmaları her zaman gerekli
Red Hat güvenlikle ilgili commit'leri cherry-pick ederken, upstream hangi commit'lerin güvenlikle ilgili olduğunu söylemezse bunu nasıl anlayabilir?
Bazen %100 tam güvenli bir işletim sistemi hayal ediyorum
Belki de anahtar formal verification ya da Rust'tır
Hack'lenmeyeceğinden emin olabilmek isterdim
Sonuçta en büyük zafiyet insanın kendisi
Hatta assembly seviyesine kadar doğrulanmıştı ve Dafny de buradan çıktı
Ama piyasada 'iyi kaliteden çok hızlı dağıtım' öncelikli olduğu için, bu fikirlerin ana akım olması onlarca yıl alıyor
Gerçek izolasyon için sanallaştırma ya da fiziksel ayrım gerekiyor
Bu yüzden “%100 güvenli işletim sistemi” için çok sayıda katkıcı toplamak zor
Yine de bu konuyla ilgileniyorsan çeşitli işletim sistemi geliştirme projeleri var
Güvenlik bitmeyen bir yarıştır
Bu arada 2026 olmuş olmasına rağmen Greg'in kişisel web sitesi hâlâ TLS desteklemiyor
Caddy ile yapılandırmak kolay, ama kişisel blog gibi statik bir sitede şifrelemenin pratik faydası neredeyse yok
Sonuçta alan adı ve IP zaten düz metin olarak görünür durumda, o yüzden çok büyük bir fark yaratmıyor
Eğer gerçekten böyle düşünüyorlarsa CNA'yı kaldırmaları gerekmez miydi?
Ama bazı araştırmacılar sadece CVE sayısını artırmaya meyilli, bu yüzden gerçekte zararsız olan hatalara bile yüksek öncelik vermek istiyorlar
“Bir güvenlik sorununu bildirmek için şifrelemeyi zorunlu kılıyorsanız, bu politikayı yeniden düşünün (burada kastedilen UK hükümeti)”
Bu kısım düpedüz komik
“Hata sadece hatadır” demek fazla basit
root yetkisi gerektiren bir DoS ile yetkisiz bir kullanıcının sistemi ele geçirmesi tamamen farklı şeyler
Bazı hatalar açıkça güvenlik sınırı ihlali yaratır ve bunlar güvenlik hatası olarak sınıflandırılmalıdır
Bu durum Greg'e onlarca yıldır anlatılıyor
Sonuç olarak, en güncel sürümü çalıştırmıyorsan kernel tamamen yamalanmış sayılmaz
CVE'lerden kaçınılıyor ve açık düzeltmeleri commit log'larının içine gizleniyor, saldırganlar da bunu fark ediyor
Bunun neden özellikle vurgulanması gerektiğini anlamıyorum
Müşteriler Docker image'larında kernel ile ilgili yamalar talep ediyor
Oysa Docker kernel'i içermez
Kernel olmadan image dağıtmanın bir yolu olmalı
Tipik base image'lar kernel içermez