Linux'da güvende olduğunuzdan nasıl emin olabiliyorsunuz?

Cruslan · 16 Nisan 2022

Linux ve açık kaynak dağıtımlarının her şeyi ortadadır. Binlerce insan kodu inceleyebilir, kopyalayabilir ve değiştirebilir. Açık kaynak dağıtımlarda hatalar hızlıca tespit edilebilir ve düzeltilebilir. Birinin bulduğu hatayı istismar etmesi de imkansızdır, o kullanana kadar çoktan düzeltilmiş olacaktır. İçerisine herhangi bir kod gizleyemezsiniz, çünkü o da belli olacaktır. Kapalı kaynak kodlu yazılımlarda açık bulmak kolay değildir, bulan bir kişi kötü niyetliyse ve söylemez ise yıllarca istismar edebilir. Düzeltilmesi de kaynak koda sahip oluşuma bağlıdır.

acv · 16 Nisan 2022

Egoistt dedi:
commit'in kabul edilmediğini iddia etmedim, sadece tek bir commit yüzünden toplam 258 farklı commit inceleme altına alındı ve kalıcı yasaklama getirildi. Bu sistem güvenliğine verilen önemi yeterince açıklıyor.

Güvenliğe yeterince önem verilmediğini iddia da etmedim ki? Arkadaş tam olarak böyle yazmış:

CoffeeCake_AoE dedi:
kernel açık kaynak, böyle bir şey olsaydı tespit edilirdi.

Ama tespit edilmedi. İtiraf ettikten sonra anlaşıldı.

Görünürde zararlı olmayan, fark edilse de bug gibi gözüken kötü amaçlı kod yazma temalı yarışmalar düzenleniyor. MU'daki durum biraz daha farklı olsa da var böyle bir şey ve yapılabiliyor anlayacağın.

Underhanded C Contest - Wikipedia

en.wikipedia.org

Egoistt dedi:
"gizli saklı patchlemek" kavramı güldürdü. Linux, BSD kadar kapalı bir sistem değildir.

Patch'ler açıklamaları ile beraber sunuluyor. Güvenlik düzeltmeleri önlem alınabilmesi için vendörlere yollanıyor. Gizli saklı patchlemekten kasıt bu, açıkların sessiz sedasız kapatılması.

Kapalı veya açık neyden bahsettiğini anlamadım, BSD'nin Linux'a göre neyi daha kapalı onu da anlamadım. Verdiğim kaynakları okumadın herhalde, "ama Linux topluluğu bu açıkları sürekli olarak kapatıyor" yazmışsın. Bu zaten Defence in Depth diye bir anlayışın olmaması, açıklar ile mücade etmede patchlemekten başka bir çözüm aranmamasının sonucu, sorun da tam olarak bu zaten. Sorun diye kastettiğimi övünülecek bir şey gibi yazmışsın.

The kernel is also very lacking in security. It is a monolithic kernel written entirely in a memory unsafe language and has hundreds of bugs, many being security vulnerabilities, found each month . In fact, there are so many bugs being found in the kernel, developers can’t keep up which results in many of the bugs staying unfixed for a long time . The kernel is also decades behind in exploit mitigations and many kernel developers simply do not care enough .

Egoistt dedi:
Çoğu güvenlik açığı exploitlenmeden tespit ediliyor ve hiçbirinden aşağıdaki kadar büyük çapta problemler çıkmadı.

Exploitlenmediğini nereden biliyorsun? Büyük çaplı ses yaratmadığı için mi? Attığın örneklerin çoğu herhangi bir açığı kullanmıyor, kullanıcı hatası ile çalışan zararlı yazılımlar sadece. Son kullanıcıların büyük çoğunluğu Windows kullanırken Petya gibi tanınan zararlı yazılımların çıkmamış olması normal.

Cruslan dedi:
Birinin bulduğu hatayı istismar etmesi de imkansızdır, o kullanana kadar çoktan düzeltilmiş olacaktır.

Hatayı ilk ben buldum, kimseye söylemeden yıllarca istismar ettim. Başka biri daha aynı hatayı bulana kadar nasıl engelleyeceksin?

Cruslan · 16 Nisan 2022

acv dedi:
Hatayı ilk ben buldum, kimseye söylemeden yıllarca istismar ettim. Başka biri daha aynı hatayı bulana kadar nasıl engelleyeceksin?

Kapalı kaynak kodu olsaydı mümkün olabilirdi. Açık kaynak kodlu bir yazılımda çok zor. Bu kodlar çokça kez elden geçiyor, çok fazla kişi tarafından.

Hiçbir sistem 100% güvende değildir ama her şeyin ortada olması çok önemli bir avantaj olarak güvenliliği arttırıyor.

433815 · 16 Nisan 2022

acv dedi:
Ama tespit edilmedi. İtiraf ettikten sonra anlaşıldı.

Edildi.

At least one faulty patch made it into the kernel (in this case it was missing mutex unlock clearly).

Fortunately, kernel maintainer Greg Kroah-Hartman caught the behavior, and chastised the researchers on the Linux kernel developer’s mailing list:

You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Now you submit a new series of obviously incorrect patches again, so what am I supposed to think of such a thing?

acv · 17 Nisan 2022

Cruslan dedi:
Kapalı kaynak kodu olsaydı mümkün olabilirdi. Açık kaynak kodlu bir yazılımda çok zor. Bu kodlar çokça kez elden geçiyor, çok fazla kişi tarafından.

Kabiliyeti yüksek mühendislerin çoğunluğu kurumsal firmalarda mühendislik yapıyor. Mevzubahis firma da Microsoft. Sadece sayı ile karşılaştırmak ne kadar doğru?

Cruslan dedi:
Hiçbir sistem 100% güvende değildir ama her şeyin ortada olması çok önemli bir avantaj olarak güvenliliği arttırıyor.

Güvenilirliği arttırabilir, iş gücünü de arttırabilir ama güvenliği doğrudan arttıran bir faktör değil. Yazılımın mimari olarak zafiyetlere karşı ne kadar korunaklı olduğu ile alakalı daha çok.

Kreato dedi:
Edildi.

Evet edilmiş. Başarısız girişimden neden PoC sunsunlar diye düşünmüştüm, detaylı olarak okumamıştım. Teşekkürler.

Cruslan · 17 Nisan 2022

acv dedi:
Kabiliyeti yüksek mühendislerin çoğunluğu kurumsal firmalarda mühendislik yapıyor. Mevzubahis firma da Microsoft. Sadece sayı ile karşılaştırmak ne kadar doğru?

Az önce bahsedildi zaten. Linux çekirdeği çok geniş bir topluluk içerisinde kullanıyor. Şirketler sunucu sistemlerinde birinci tercih olarak Linux çekirdeğinden güç alan işletim sistemlerinde kullanıyorlar. Microsoft'un sitesi bile arkasında Linux sunucuları barındırıyor. Topluluk ve kullanıcı sayısı çok geniş, tek bir şirket değil yüz binlerce kullanıcı ve yüzlerce şirketin içerisinde bulunduğu bir sistem Linux.

Bahsettiğiniz firma hataları düzeltmek için gelen yama bozuk olduğu için çıkan yama da bozuk olduğu için üçüncü yama getiren bir firma.

acv dedi:
Güvenilirliği arttırabilir, iş gücünü de arttırabilir ama güvenliği doğrudan arttıran bir faktör değil. Yazılımın mimari olarak zafiyetlere karşı ne kadar korunaklı olduğu ile alakalı daha çok. Windows kapalı kaynak bir işletim sistemi fakat mitigasyonlar yönünden Linux'tan ileride.

Güvenilirliliği doğrudan arttıran bir unsur. Şirketler doğrudan sunucularda kullanıyorlar, kullanıcılar bilgisayarlarına kullanıyor, yapay zeka gibi işlevlerde kullanılıyor. Kod sürekli birilerinin elinden geçiyor. Hiçbir şeyi saklayamıyorsunuz. Aynı zamanda açık olduğu için çabucak çözülüyor, birisi çözmezse başkası çözüyor. Bir şirketin eline kalınca altı ay yama bekliyorsunuz, belki yıllarca. Linux çekirdeği sürekli gelişen bir çekirdek, Microsoft yıllardır NT çekirdeğine bel bağlamış durumda, yeni teknolojileri kaldırmıyor. Sürekli yeni yama çıkarıyor hatta çıkan yama da sorunlu olduğu için yeniden yama çıkarılıyor. Güvenilirlik, güvenlik ve güncellik olarak Linux her halükarda önde.

egoistpizza · 17 Nisan 2022

acv dedi:
Güvenliğe yeterince önem verilmediğini iddia da etmedim ki? Arkadaş tam olarak böyle yazmış:

Bunlar tamamen güvenliğe yeterince önem verilmediği iddiaların oluyor:

acv dedi:
Tam tersine Linux çekirdeğinin durumu tam olarak bu. Exploit mitigasyonlarında geriden geliyor, mimari güvenlik zafiyetleri sadece bir bug olarak görülüyor Linux tarafında.

acv dedi:
Bu durum gayet de mevcut. Linux çekirdeği uyumluluk ve performans adına güvenlikten feragat edilen, güvenliği arttırmaya yönelik değişikliklerin upstream'den aynı sebeple reddedildiği bir proje. Bugünlerde de güvenlik açıklarını gizli saklı patchlediklerini duydum. Altta eklediğim kaynakları okuyabilirsin.

acv dedi:
Ama tespit edilmedi. İtiraf ettikten sonra anlaşıldı.

@Kreato 'nun da gösterdiği şekilde, edildi. Yapılan commitlerdeki amaç geçmişte kapatılan açıkları tekrardan exploitable hale getirmekti. Commitler şüpheli bulundu ve araştırma yazısı da olaya bir açıklık getirdi.

acv dedi:
Patch'ler açıklamaları ile beraber sunuluyor. Güvenlik düzeltmeleri önlem alınabilmesi için vendörlere yollanıyor. Gizli saklı patchlemekten kasıt bu, açıkların sessiz sedasız kapatılması.

Bu "sessiz sedasız" veya "gizli saklı" kapatmak değil. Gözetmen ekip içerisinde açıkları kapatmanın usulü budur zaten. Hiçbir problem yok.

acv dedi:
"ama Linux topluluğu bu açıkları sürekli olarak kapatıyor" yazmışsın. Bu zaten Defence in Depth diye bir anlayışın olmaması, açıklar ile mücade etmede patchlemekten başka bir çözüm aranmamasının sonucu

DiD kernelde değil distroda uygulanır. Kernelde DiD uygulamaya çalışmak saçmalıktır ve UNIX filozofisine doğrudan aykırıdır. Kullanıcı özgürlüğü doğrultusunda kişisel önlemlerini alır veya direkt QubesOS benzeri bir sistem kullanır. Kaldı ki kullanıcıların çoğu - Windows gibi delik deşik bir sistemden alışık olmadıkları sürece - DiD sistemlerine ihtiyaç duymaz. Bu da Linux kernelinin ne kadar güvenli olduğunu kanıtlar. Sizin dediğiniz gibi "ama Defence in Depth anlayışı yok" tarzında fikirlere kulak asıp kernel bu yönde geliştirilse ortaya hantal, gereksiz servislerle doldurulmuş bir sistem çıkardı.

acv dedi:
Attığın örneklerin çoğu herhangi bir açığı kullanmıyor, kullanıcı hatası ile çalışan zararlı yazılımlar sadece.

Tüh, o çok sevdiğimiz Windows'umuz koskoca bir ay boyunca EternalBlue'yu patchleyemedi ama Linux kerneli çok güvensiz. WannaCry zaten kullanıcı hatası yüzünden 300K+ bilgisayara yayılmıştı, değil mi?

acv dedi:
Hatayı ilk ben buldum, kimseye söylemeden yıllarca istismar ettim. Başka biri daha aynı hatayı bulana kadar nasıl engelleyeceksin?

Hatayı sen buldun ve elbette sadece sen o kodu görüntüleyebiliyorsun. Yıllar boyunca da kodu incelemek hiç kimsenin aklının ucundan geçmedi, nasıl düşündün bunu?

acv dedi:
Kabiliyeti yüksek mühendislerin çoğunluğu kurumsal firmalarda mühendislik yapıyor. Mevzubahis firma da Microsoft. Sadece sayı ile karşılaştırmak ne kadar doğru?

"Kabiliyeti yüksek mühendis" derken; Red Hat'te çalışanlar 5 yaşında kod yazabilen çocuklar sanırsam. Offensive Security geliştiricileri de hacker kılığındaki lamerlar olsa gerek, saygı duyarım.

acv · 17 Nisan 2022

Cruslan dedi:
Linux çekirdeği çok geniş bir topluluk içerisinde kullanıyor. Şirketler sunucu sistemlerinde birinci tercih olarak Linux çekirdeğinden güç alan işletim sistemlerinde kullanıyorlar. Microsoft'un sitesi bile arkasında Linux sunucuları barındırıyor. Topluluk ve kullanıcı sayısı çok geniş, tek bir şirket değil yüz binlerce kullanıcı ve yüzlerce şirketin içerisinde bulunduğu bir sistem Linux.

Evet, şirketlerin ortak projesi sayılır. Gerçekten kabiliyetli mühendislerin de gözetiminde olan bir çekirdek, o da doğru. Fakat bu çekirdeğin mimari olarak zafiyetlere karşı korunmasız olduğunu değiştirmez. Sadece çekirdekten bahsetmek de doğru değil zira eksikliklerin büyük kısmı userland'de.

Cruslan dedi:
Güvenilirliliği doğrudan arttıran bir unsur. Şirketler doğrudan sunucularda kullanıyorlar, kullanıcılar bilgisayarlarına kullanıyor, yapay zeka gibi işlevlerde kullanılıyor. Kod sürekli birilerinin elinden geçiyor. Hiçbir şeyi saklayamıyorsunuz.

Çekirdek sunucularda ham olarak kullanılmıyor, sanallaştırma ve konteynır çözümleri ile beraber kullanılıyor. Özelleştirilebilir olduğu için sunucuya uygun hale getirilip güvenlikte elle geliştirmeler yapılıyor. Linux hiçbir zaman güvenli hale getirilemez diye bir iddiam yok, Google Android'de de bunu başardı zaten. Özellikle userland tarafında diğer Linux dağıtımlarına nazaran çok büyük güvenlik artısı var.

Cruslan dedi:
Kod sürekli birilerinin elinden geçiyor. Hiçbir şeyi saklayamıyorsunuz. Aynı zamanda açık olduğu için çabucak çözülüyor, birisi çözmezse başkası çözüyor.

Güvenliği hala patchleme hızından ibaret sanıyorsunuz, öyle olmadığını açıklamıştım.

Egoistt dedi:
Bunlar tamamen güvenliğe yeterince önem verilmediği iddiaların oluyor:

Açıkları kapatmak dışında güvenliği arttırmak için bir çabaları yok. Spenger'in sözü de bu şekilde.

Egoistt dedi:
DiD kernelde değil distroda uygulanır. Kernelde DiD uygulamaya çalışmak saçmalıktır ve UNIX filozofisine doğrudan aykırıdır. Kullanıcı özgürlüğü doğrultusunda kişisel önlemlerini alır veya direkt QubesOS benzeri bir sistem kullanır. Kaldı ki kullanıcıların çoğu - Windows delik deşik bir sistemden alışık olmadıkları sürece - DiD sistemlerine ihtiyaç duymaz. Bu da Linux kernelinin ne kadar güvenli olduğunu kanıtlar. Sizin dediğiniz gibi "ama Defence in Depth anlayışı yok" tarzında fikirlere kulak asıp kernel bu yönde geliştirilse ortaya hantal, gereksiz servislerle doldurulmuş bir sistem çıkardı.

Memory corruption açıklarına karşı nasıl bir kişisel önlem alacaksın? Direkt olarak mimariden kaynaklı zafiyetleri çözmenin neresi UNIX felsefesine aykırı? Windows'un delik deşik olduğunu nereden çıkardınız halbuki objektif olarak yapılan bir karşılaştırma attım o kadar Attığım kaynakları okumayacaksanız tartışmanın bir manası yok gerçekten, sadece bir zaman kaybı.

Egoistt dedi:
Tüh, o çok sevdiğimiz Windows'umuz koskoca bir ay boyunca EternalBlue'yu patchleyemedi ama Linux kerneli çok güvensiz. WannaCry zaten kullanıcı hatası yüzünden 300K+ bilgisayara yayılmıştı, değil mi?

İstisna göstermek bir safsata.

Egoistt dedi:
Hatayı sen buldun ve elbette sadece sen o kodu görüntüleyebiliyorsun. Yıllar boyunca da kodu incelemek hiç kimsenin aklının ucundan geçmedi, nasıl düşündün bunu?

Kimsenin aklının ucundan geçmedi demedim, bulamadı dedim. Sıfır gün açıkları henüz bir veya birkaç kişi dışında bilinmeyen açıklardır. Böyle bir şeyin olamayacağını mı iddia ediyorsun şimdi

aliaksandr · 17 Nisan 2022

Tamam Linux dağıtımları açık kaynak ama 20 kişilik ekibin geliştirdiği bir dağıtım var diyelim. Dağıtımın kullanıcıları da tüm dünyada 15.000 kişi olsun. 20 kişilik ekip birden çıldırdı, dedi ki güncelleme ile tüm kullanıcıların bilgisayarına bir keylogger atalım. Güncelleme geldi keylogger yüklendi. Şimdi bu 15.000 kişi olan kullanıcılar da 7/24 dağıtımın kodlarını inceliyor olamazlar olsa dahi her yazılım bilen her dili bilmiyor ve bir işletim sistemi sadece bir programlama dili ile yazılamaz diye biliyorum. Bu kullanıcıların bunu fark etmesi 3 gün sürsün. Sonuçta karşınızda belki suçlayacağınız bir muhatap bile olmayabilir. Ben programlama dili bilmiyorum ben Linux kullansam da anlamam kötü amaçlı kodu mesela. Ben her Linux dağıtımı Windows'tan daha güvenlidir sözüne katılmıyorum. Yukarıda verdiğim örnekte yanlışlar olabilir varsa aydınlatırsanız sevinirim.

egoistpizza · 17 Nisan 2022

acv dedi:
Memory corruption açıklarına karşı nasıl bir kişisel önlem alacaksın? Direkt olarak mimariden kaynaklı zafiyetleri çözmenin neresi UNIX felsefesine aykırı? Windows'un delik deşik olduğunu nereden çıkardınız halbuki objektif olarak yapılan bir karşılaştırma attım o kadar Attığım kaynakları okumayacaksanız tartışmanın bir manası yok gerçekten, sadece bir zaman kaybı.

Tüm bir kernel'in Rust'ta yazılmasını mı savunuyorsun? Memory corruption'ın önlenmesi için ciddi bir yatırım ve zaman gerekli, buna değeceğini de hiç sanmıyorum.

Linux kernelinin güvenliğini eleştirdiğinde BSD ve BSD-like sistemleri savunduğunu ve bu yönde fikirlerinin olduğunu düşünmüştüm. Kusura bakma ama NT'nin güvenli olduğunu öne sürmek saçmalıktan ibaret. Üst üste exploitler saptanıyor ve kapalı kaynak olması nedeniyle o çok sevgili "yüksek kaliteli" mühendislerimizin patchlemesi bir ay veya daha fazla sürebiliyor. Linux tarafı sadece bir araştırmadan yola çıkarak şüphelenip 20+ yıllık 258 commiti hiç düşünmeden kaldırıyor fakat bu yeterli olmuyor. Sonrasında da "kullanıcı sistemini güncel tutmadığı için sorun yaşıyor", "antivirüs kullansaymış" gibi bahaneler öne sürülüyor. Linux kullanıcısı sistemine zararlı bulaştırsa hemen "kernel güvenli değil", Windows kullanıcısı bulaştırsa "bilinçli kullanıcı değilmiş" "önlemini almamış" "antivirüs kullanmıyormuş" gibi bahaneler başlıyor. Pandemiyle beraber sıçrayan ransomware olaylarının hemen hemen hepsi NT tarafında yaşandı ama hiç kimse NT'nin yeterince güvenli olmadığını savunmadı. Herkes kullanıcının "önlemsiz" olduğunu öne sürdü. Bu saçmalıklarla uğraşmak son kullanıcıyı haklı olarak zamanla baydı.

Attığınız kaynakları halihazırda okuyorum ve karşılıklı olmasını umuyorum. Tartışmak zaman kaybıysa tartışmak zorunda değilsiniz. Ben şahsi olarak zevk aldığım için devam ettiriyorum.

acv dedi:
İstisna göstermek bir safsata.

BlueKeep Windows 2000'den Windows 7'ye kadar çok güncel ve donanımlı NT çekirdeğimizde bulunan bir açıktı ve 2019'da patchlendi. Ama elbette ki bu kullanıcı hatasıydı, 19 yıl boyunca neden birinin düzeltmesini beklemiş ki? Kendisi patchleseymiş! İstisnaların bu kadar çok olması üzücü, sıradan devam edelim istersen.

acv dedi:
Kimsenin aklının ucundan geçmedi demedim, bulamadı dedim. Sıfır gün açıkları henüz bir veya birkaç kişi dışında bilinmeyen açıklardır. Böyle bir şeyin olamayacağını mı iddia ediyorsun şimdi

Evet, sıfır gün açıklarıyla dolu etraf. Ama ne tesadüftür ki bu açıkların neredeyse hepsi kapalı kaynak sistemlere ait.

acv dedi:
Büyüüük Linux topluluğunun tamamı Red Hat'te çalışan mühendislerdi zaten, tamam

Linux Foundation ve diğer özgür yazılım kuruluşları çay ocağı aslında. Biz orada dayılarla toplaşıp okey dönüyoruz, yoksa bilmiyor muydun?

Linux'da güvende olduğunuzdan nasıl emin olabiliyorsunuz?

Cruslan

Terapat

acv

Gigapat

Underhanded C Contest - Wikipedia

Cruslan

Terapat

433815

Hectopat

acv

Gigapat

Cruslan

Terapat

egoistpizza

Hectopat

acv

Gigapat

aliaksandr

Megapat

egoistpizza

Hectopat