Linux çekirdeği topluluğu, önemli bir dönüm noktasından geçiyor. Güvenlik açıklarının nasıl raporlandığı ve yönetildiği konusunda kapsamlı bir inceleme.Bu durum büyük ölçüde yapay zeka araçlarının kod denetimine doğrudan etkisinden kaynaklanmaktadır. Bu sistemlerin yaygın olarak benimsenmesi, güvenlik uyarılarının hacmini önemli ölçüde artırmış, ancak aynı zamanda ciddi bir tekrarlama, gürültü ve bakımcılar için ek bir yük sorununu da ortaya çıkarmıştır.
Projenin kilit isimlerinden Linus Torvalds, projeyi şu şekilde tanımlayacak kadar ileri gitti (şu metinde): Linux 7.1-rc4 sürüm notlarıÇekirdeğin özel güvenlik listesini şu şekilde tanımlayın: Yapay zekâ destekli raporların yoğunluğu nedeniyle durum "neredeyse tamamen yönetilemez" hale geldi.Bu raporların çoğu mükerrerdi veya yanlış sınıflandırılmıştı. Buna karşılık, proje Linux 7.1'e entegre edilmiş yeni bir doküman yayınladı; bu doküman, gerçek bir güvenlik açığının ne olduğunu ve yapay zeka modelleri kullanılarak oluşturulan raporların nasıl ele alınması gerektiğini yeniden tanımlıyor.
Yinelenen raporlar nedeniyle güvenlik listesi aşırı yüklendi.
Torvalds, Linux 7.1'in geliştirilmesiyle ilgili son açıklamalarında, güvenlik açığı e-posta listesinin giderek daha fazla kullanılmaya başlandığı konusunda uyarıda bulundu. Önemli duyuruların çok sayıda gereksiz raporla karıştığı bir darboğaz.Sorun sadece miktar değil, aynı otomatik araçları kullanan farklı kişilerin tam olarak aynı bulguları sunmasıdır.
Açıkladığı gibi, geliştiriciler mesajları gerçekten alması gereken kişilere iletmek veya hatanın zaten düzeltildiğini açıklamak için çok zaman kaybediyorlar. Çekirdek dallarında günler veya haftalar önce düzeltildiBazılarının "e-posta seline" benzettiği bu durum, kaynakların yeni ve ciddi güvenlik açıklarına odaklanmak yerine, mükerrer kayıtları netleştirmeye ayrılmasını zorunlu kılıyor.
HAProxy üzerindeki çalışmalarıyla tanınan deneyimli bir kararlı çekirdek geliştiricisi olan Willy Tarreau, açıklayıcı şekiller sağladı: Sadece birkaç yıl önce, özel posta listesine haftada iki ila üç rapor geliyordu.Oysa şu anda günlük olarak beş ila on rapor işleniyor. Bunların çoğu yapay zeka destekli analizlerden geliyor ve bunlar bazen gerçek sorunlara işaret etse de, pratik olmayan formatlarda ve ilgili ek bilgiler sağlamadan geliyor.
Torvalds yapay zekâya karşı değil, onun kötüye kullanılmasına karşı çıkıyor.
Görünüşte farklı olsa da, Torvalds şunu açıkça belirtti: Yapay zekanın geliştirme ve denetim aracı olarak kullanımına karşı değildir.Kendisi de çalışmalarında bu tür sistemleri kullandığını kabul ediyor, ancak bunların sorumlu ve ölçülü bir şekilde kullanılması gerektiğinde ısrar ediyor.
Topluluğa gönderdiği mesajlarda, yapay zeka araçlarının gerçekten yardımcı olduklarında "harika" olduklarını, ancak sorun yarattıklarında ise problem haline geldiklerini vurguladı. “gereksiz acı ve faydasız hayali çalışma”Başka bir deyişle, otomatik bir modelin olası bir güvenlik açığına işaret etmesi, güvenlik kanallarını yeterince doğrulanmamış veya teknik bağlamdan yoksun raporlarla doldurmayı haklı çıkarmaz.
Torvalds, yapay zekayı hata bulmak için kullanan herkesin sadece ham sonucu iletmemesi gerektiğini, ancak Çekirdek dokümantasyonunu okuyun, tehdit modelini anlayın ve mümkün olduğunca bir yama sağlayın veya en azından etkisine dair sağlam bir açıklama sunun.Amaç, insanların otomatikleştirilmiş işlere değer katması, araç ile e-posta listesi arasında sadece aracı rolü üstlenmemesidir.
Linux 7.1'deki yeni kurallar: güvenlik açığı nedir, nedir değil?
Bu duruma yanıt olarak, çekirdek projesi Linux 7.1'de daha ayrıntılı dokümantasyon eklemiştir. Hangi hataların güvenlik açığı olarak değerlendirilmesi gerektiği ve hangilerinin olağan kanallar aracılığıyla ele alınması gereken basit hatalar olduğu sorusu akla geliyor.Willy Tarreau tarafından yazılan metin, zaten çekirdeğin Git ağacının bir parçası ve Linux 7.1-rc4 sürümünden önce kullanıma sunulmuş durumda.
Bu kılavuz basit bir fikirden yola çıkıyor: Çoğu hata özel güvenlik listesi üzerinden yönlendirilmemelidir.Bunun yerine, bu sorunlar kamuya açık geliştirme e-posta listelerinde açıkça ele alınmalıdır. Sorunların kamuoyu önünde tartışılması daha fazla değerlendiriciyi çeker, daha fazla kullanım senaryosunu kapsar ve genellikle daha yüksek kaliteli çözümlere yol açar.
Belgede, Linux'un zaten bir özelliğe sahip olduğu belirtiliyor. açıkça tanımlanmış tehdit modeliBu, bir güvenlik açığının özel olarak ele alınıp alınmayacağına karar verilirken temel referans noktası olarak hizmet vermektedir. Güvenlik açığı, düzgün yapılandırılmış bir üretim sisteminin sahip olmaması gereken yetenekleri bir saldırgana kazandıran, makul ölçüde istismar edilebilir ve önemli sayıda kullanıcı için gerçek bir tehdit oluşturan bir açık olarak tanımlanır.
Pratikte, sorunları keşfedenler kendilerine hatanın şu olup olmadığını sormaya davet edilirler: Bu, tipik bir ortamda güven sınırını gerçekten aşıyor.Cevap hayır ise, önerilen yaklaşım kısıtlı güvenlik kanalı yerine genel posta listelerini (LKML ve alt sistem özel posta listeleri gibi) kontrol etmektir. Yine de kılavuz, bir dereceye kadar ihtiyatlı olmaya izin veriyor: şüphe durumunda, gerçek bir güvenlik açığının gözden kaçmasına izin vermektense, şüpheli bir raporu özel olarak incelemek tercih edilir.
Metnin bir diğer önemli noktası da şudur ki Sıradan hataları özel posta listesine göndermek, bunların daha hızlı düzeltilmesini sağlamaz.Tam tersine, bu durum güvenlik ekibinin gerçekten kritik arızaları önceliklendirmek için ihtiyaç duyduğu zaman kaybını artırır. Bu kanalı küçük sorunlarla doldurmak, sunucular, bulut altyapısı ve endüstriyel cihazlar da dahil olmak üzere Linux tabanlı sistemlerin genel korumasını nihayetinde kötüleştirir.
Tehdit modeli: ayrıcalıkların ayrılması ve dışlanan durumlar
Yeni dokümantasyon, ihlal edilmesi tehdit olarak değerlendirilen güvenceleri listeleyen temel tehdit modelini güncelliyor ve detaylandırıyor. öncelikli dikkat gerektiren bir güvenlik sorunuBunlar arasında kullanıcı alanı ve çekirdek arasındaki ayrım, süreçler arası bellek izolasyonu, ptrace kısıtlamaları, IPC ve ağ mekanizmalarının izolasyonu ve CAP_SYS_ADMIN, CAP_NET_ADMIN veya CAP_SYS_PTRACE gibi hassas yeteneklerle ilgili korumalar yer almaktadır.
Özellikle, CONFIG_USER_NS gibi ayarların yetkisiz kullanıcıların izole ortamlar oluşturmasına olanak tanıdığı kullanıcı ad alanlarına özel önem verilmektedir. Proje, bu hususu beklemektedir. Bu örnekler küresel sistemi tehlikeye atamaz.Bu nedenle, söz konusu izolasyonun herhangi bir şekilde ihlal edilmesi güvenlik açısından önem kazanır.
/proc/kmsg, perf veya debugfs gibi hata ayıklama arayüzleri de analiz edilir; bu mekanizmalar aracılığıyla hassas bilgilere erişmenin riskli olduğu göz önünde bulundurulur. Yönetici tarafından açıkça yetkilendirilmedikçe engellenmelidir.Aksi takdirde, saldırıları iyileştirmek veya ayrıcalıkları yükseltmek için kullanılabilecek verilerin sızdırılması riski vardır.
Bu garanti tanımının yanı sıra, kılavuz ne tür sorunların söz konusu olduğunu da açıklığa kavuşturuyor. Bunlar otomatik olarak güvenlik açığı olarak etiketlenmemelidir.Bu kategori, güncelliğini yitirmiş çekirdek dallarındaki hataları, yönetici tarafından seçilen güvenli olmayan derleme seçeneklerini, sysctl veya dosya sistemlerindeki yanlış izinleri, hata ayıklama için ayrılmış işlevleri (LOCKDEP, KASAN, FAULT_INJECTION) ve hazırlık alanlarındaki deneysel kodları içerir.
Gerektiren kusurlar Aşırı ayrıcalıklar, gerçek dünya kullanımından çok uzak laboratuvar senaryoları, manipüle edilmiş donanım, yönetilemez sayıda deneme Ya da aklı başında hiçbir yöneticinin üretim ortamında uygulamayacağı yapılandırmalar. Benzer şekilde, açık bir güvenlik açığı bulunmayan veri sızıntıları ve genellikle fsck gibi araçlar tarafından ele alınan dosya sistemi görüntülerindeki belirli sorunlar, güvenlik kanalının temel kapsamı dışında kalmaktadır.
Yapay zekâ destekli bulgular: özelden kamuya
Güncellemedeki en dikkat çekici değişikliklerden biri, yapay zeka yardımıyla keşfedilen hatalara yaklaşım biçimidir. Belgelerde şu ifade yer almaktadır: Otomatik analiz yoluyla tespit edilen hatalar esasen kamuya açık olarak değerlendirilmelidir.İlk gönderi özel posta yoluyla yapılsa bile.
Bunun sebebi tamamen pratiktir: Güvenlik ekibinin son deneyimleri, bu tür hataların sıklıkla meydana geldiğini göstermektedir. aynı anda birkaç araştırmacının elinde Benzer araçlarla deneyler yapan kişiler de var. Aynı durumu anlatan, biçimde ufak farklılıklar gösteren birçok e-postanın saatler içinde gelmesi yaygın bir durum; bu da uzun süreli gizlilik beklentisini gerçekçi olmaktan çıkarıyor.
Bu yeni gerçeklik, Torvalds'ı şu argümanı öne sürmeye yöneltiyor: Bu bulguları, bir yama bulunana kadar saklanması gereken sırlar olarak ele almak mantıklı değil.Eğer sıradan bir yapay zeka bunları bulabiliyorsa, potansiyel saldırganlar da dahil olmak üzere diğer aktörlerin de aynı sonuca ulaşabileceğini varsaymak mantıklıdır. Bunları "ayrıcalıklı güvenlik açıkları" olarak etiketlemek yalnızca ek iş yükü getirir ve koordinasyonu zorlaştırır.
Bu, tüm teknik detayların filtrelenmeden yayınlanmasının önerildiği anlamına gelmez. Kılavuz, yapay zeka kullanılarak tespit edilen durumlarda, Hata için çalışan bir oyuncu henüz paylaşılmadı. (Hatayı tetikleyen adımların veya kodun tam sırası). Uygun yaklaşım, bu materyalin mevcut olduğunu belirtmek ve bakımcıların düzeltmeyi doğrulamak için gerekli gördükleri takdirde bunu özel olarak talep etmelerine izin vermektir.
Bu yaklaşımla proje, iki ilgi alanını birleştirmeyi amaçlamaktadır: bir yandan, Başkalarının zaten bildiği bulguları özel listeye ekleyerek gereksiz yere kalabalıklaştırmaktan kaçının.Öte yandan, risk azaltma önlemleri alınmadan önce herkese istismar için bir "reçete" sunmamak önemlidir. Medya oynatıcı, hem hata ayıklama hem de etki değerlendirmesi için değerli bir araç olarak kabul edilir, ancak asgari kontroller olmadan dağıtılırsa hassas bir konu olarak da değerlendirilir.
Yapay zekâ tarafından oluşturulan raporlar için kalite gereksinimleri
Yeni dokümantasyon, yapay zeka destekli raporların nasıl yazılması gerektiğine dair ayrı bir bölüm ayırıyor. Bakım ekiplerinden gelen tekrarlayan şikayet, bu raporların çoğunun yanlış gelmesidir. Gereksiz açıklamalarla dolu, aşırı şişirilmiş ve temel verilere yeterince odaklanılmamış.Bu durum, metnin okunmasını ve sınıflandırılmasını zorlaştırmaktadır.
Öncelikle raporların aşağıdaki şekilde olması rica olunur: kısa, net ve anlaşılır bir şekildeEkip, e-posta listelerinde zincirleme yanıtlar için uygun olmayan Markdown, süslemeler veya karmaşık yapılar gibi formatların kullanılmasını önermez. Amaç, mesajı iletirken veya alıntı yaparken hiçbir bilginin kaybolmaması ve metnin okunamaz bir blok haline gelmemesidir.
İçerik konusunda, öncelikle şunlarla başlamanız önerilir: Etkilenen dosya veya alt sistemi, etkilenen sürümleri ve hatanın gözlemlenebilir etkisini belirten basit bir özet.Buradan itibaren detaylar eklenebilir, ancak her zaman hızlı bir okuma sağlayarak arızanın öncelikli mi yoksa küçük sorunlar kategorisine mi girdiğine karar vermenizi kolaylaştırmak amacıyla yapılır.
Bir diğer önemli husus ise etkinin nasıl tanımlandığıdır. Çekirdek geliştiricileri, yapay zeka tarafından oluşturulan birçok raporun... Teorik sonuçları abartma eğilimindedirler.Projenin gerçek tehdit modeline uymayan varsayımsal senaryoları bir araya getirmek yerine, katılımcılardan karmaşık saldırı anlatıları oluşturmak yerine, standart olarak yapılandırılmış bir sistemde bir kullanıcının hangi ek yetenekleri kazanabileceğini somut olarak açıklamak gibi doğrulanabilir gerçeklere bağlı kalmaları isteniyor.
Kılavuz, mümkün olan durumlarda yapay zeka aracının kendisinin Linux tehdit modeli dokümantasyonunu önceden okuması gerektiğini bile öne sürüyor. vardığı sonuçları, proje tarafından daha önce belirlenmiş kriterlerle uyumlu hale getirmek.Amaç, yanlış anlamaları azaltmak ve otomatik raporlamanın, sınırlı etkiye sahip bir hatayı gerçek bir dayanağı olmadan sözde kritik bir güvenlik açığına dönüştürmesini önlemektir.
Otomasyon çağında oyuncular, yamalar ve sağduyu
Belgeleme, arızanın nasıl açıklanacağına ek olarak, daha pratik yönlere de odaklanmaktadır: Yapay zeka destekli oyuncu ve yama üretimi ve doğrulamasıBirçok modern araç, hatayı tetikleyen küçük test programları veya komut dosyaları oluşturabilir ve hatayı düzeltmek için kod değişiklikleri önerebilir, ancak bunu her zaman güvenilir bir şekilde yapmazlar.
Çekirdek, rapor göndermeden önce, Araştırmacı, oynatıcının anlatıldığı gibi çalıştığını bizzat doğrulamalıdır.Eğer işlem dizisi hataya neden olmazsa veya yapay zeka tekrarlanabilir bir yöntem üretemezse, raporun geçerliliği ciddi şekilde tehlikeye girer. Bu doğrulama yapılmadan bulguların yayınlanması yalnızca gereksiz bilgi kirliliğine yol açar ve bakımcıların zamanını boşa harcar.
Yama güncellemeleriyle ilgili olarak, metinde birçok yapay zekanın daha da iyi hale geldiği vurgulanıyor. Etkisini değerlendiren kod yazmakBu nedenle, bu araçların kullanıcılarının yalnızca sorunu belirlemelerini değil, aynı zamanda bir çözüm önermelerini de istemeleri teşvik edilmektedir. Bununla birlikte, sonucun geliştirme e-posta listelerine gönderilmeden önce manuel olarak incelenmesi ve test edilmesi gerektiği vurgulanmaktadır.
Kılavuz, yamanın test edilemediği durumlarda, bunun nedeninin bağımlılıklarından kaynaklanması halinde, kesin ve nettir. egzotik donanımlar, neredeyse yok olmuş ağ protokolleri veya son derece nadir yapılandırmalarEğer bir güvenlik açığı yalnızca kimsenin kolayca doğrulayamayacağı kadar sınırlı bir ortamda ortaya çıkıyorsa, büyük olasılıkla ilgili güvenlik açığı kategorisine girmiyordur ve özel kanalın zamanını tüketmemelidir.
Bir düzeltme önerirken, proje kullanıcılara bunun etiket de dahil olmak üzere standart çekirdek yama gönderme yönergelerine uyması gerektiğini hatırlatır. “Düzeltmeler:” ifadesi, hataya neden olan belirli commit'i belirtir.Ayrıca sağduyuyu kullanmak da önerilir: Eğer etkilenen dosya bir yıldan fazla süredir değişmemişse ve tek bir kişi tarafından yönetiliyorsa, eski donanım sürücüleri veya kullanım dışı kalmış dosya sistemleri gibi çok az gerçek kullanıcısı olan bir bileşenle karşı karşıya olabiliriz.
Bu durumlarda öneri açıktır: eğer sorun önemsizse, kolayca tespit edilebiliyorsa ve tipik ortamlarda belirgin bir etkisi yoksa, En mantıklı yaklaşım, konuyu doğrudan kamu geliştirme listeleri aracılığıyla ele almaktır. ve güvenlik için ayrılmış listede yer almıyor. Bu şekilde, en hassas kaynaklar potansiyel olarak ciddi sonuçlar doğurabilecek olaylar için ayrılmış oluyor.
Fuzzing döneminden yapay zeka çığlığına: Özgür yazılımlar için dersler
Mevcut durum, Syzkaller gibi fuzzing araçlarının ortaya çıkmaya başladığı dönemi bir nebze hatırlatıyor. Çekirdeği, tespit edilen hatalara ilişkin raporlarla yarı otomatik bir şekilde bombardımana tutmak.O dönemde, topluluk, sürekli gelen bu bulgular akışını günlük çalışmalarını aksatmadan kendi gelişim sürecine entegre etmeyi öğrenmek zorundaydı.
Yapay zekâda da benzer bir durum yaşanıyor, ancak farklı bir ölçekte. Artık sadece hatalara neden olan girdilerin üretimi otomatikleştirilmiyor, aynı zamanda... Raporların hazırlanması, kodun statik analizi ve yama önerilerinin sunulması.Bu, hata bulmayı hızlandırır, ancak doğru şekilde filtrelenip önceliklendirilmezse, e-posta sayısını, paralel tartışmaları ve çekirdek ekibinin neler yapabileceğine dair beklentileri de kat kat artırır.
Linux ekosistemi içinde bile bu olgunun değerlendirilmesinde bazı nüanslar mevcuttur. Önemli bir çekirdek geliştiricisi olan Greg Kroah-Hartman, şu noktaya dikkat çekmiştir: Yapay zekâ tarafından oluşturulan raporlar, neredeyse her zaman işe yaramaz olmaktan hızla geçerli katkılar haline geldi.Bu daha iyimser bakış açısı, Torvalds'ın çok sayıda mükerrer kayıt ve güvenlik listesindeki aşırı yüklenme konusundaki endişesiyle birlikte varlığını sürdürüyor.
Bu pozisyonlar bir çelişki olmaktan ziyade, birbirini yansıtmaktadır. aynı evlat edinme sürecinin iki tarafıBir yandan yapay zeka gerçek sorunları bulmak için çok faydalı olabilir; diğer yandan, birçok kişi aynı araçları aynı kod üzerinde çalıştırıp sonuçları filtrelemeden gönderirse, ortaya çıkan birleşik etki yönetilmesi zor bir "uyarı fırtınası" olur.
Sorumlu otomasyon kullanımına bir örnek olarak, Kroah-Hartman'ın kendisi, çekirdeği taramak, yamalar oluşturmak, bunları test etmek ve projenin standart iş akışını takip ederek göndermek için özel sistemler yayınlamıştır. Buradaki kilit nokta, bu durumlarda, Geliştirici, tüm yaşam döngüsü boyunca teknik sorumluluğun tamamını üstlenir.Bir aracın ne ürettiğini kontrol etmeden doğrudan iletmek yerine.
Linux 7.1'i çevreleyen tüm hareket, yapay zekayı reddetmekten çok uzak, aksine onu destekleyen bir projeyi ortaya koyuyor. Otomasyonun güvenliğe zarar vermek yerine güvenlik lehine çalışacak şekilde süreçlerini uyarlıyorlar.Güvenlik açığı olarak kabul edilen durumlar için daha katı kriterler belirleyerek, doğrulanabilir düz metin raporları gerektirerek ve yapay zekanın yama oluşturma ve test etme süreçlerine katkıda bulunmasını teşvik ederek, çekirdek, bakımcıların zamanını korumayı, gereksiz bilgileri azaltmayı ve çabaları üretim sistemlerini gerçekten tehlikeye atabilecek hatalara odaklamayı amaçlamaktadır.