Linux'a Landlock Uygulamak

 (blog.prizrak.me)
1 puan yazan GN⁺ 2025-12-01 | 1 yorum | WhatsApp'ta paylaş
  • Landlock, uygulamaların erişebileceği kaynakları açıkça bildirerek çekirdek seviyesinde kendi kendini sandboxlama yapmasını sağlayan bir Linux güvenlik API'sidir
  • Mevcut SELinux veya AppArmor'dan daha basit olup, geliştirici yetkisi olmadan çalıştırma anında politika oluşturup uygulayabilir
  • Politikalar erişilebilir dosya, dizin ve port gibi öğeleri açık izin listesi (allowlist) şeklinde tanımlar; katmanlı kısıtlama ile kademeli güvenlik artırımı sağlar
  • Rust, Go, Haskell gibi dillerde bağlayıcılar bulunur ve GUI uygulamaları, sunucular ve masaüstü süreçleri gibi çeşitli ortamlarda ince ayarlı erişim kontrolü uygulanabilir
  • Linux güvenlik ekosisteminde basit ve pratik bir yetkisiz sandbox aracı olarak, gelecekte masaüstü güvenliğini güçlendiren ana bileşen olarak öne çıkıyor

Landlock Özeti

  • Landlock, Linux uygulamalarının erişebileceği kaynakları açıkça tanımlamasını sağlayan bir API
    • OpenBSD'nin unveil() ve pledge() kavramlarına benzer ve “yalnızca gerekli kaynaklara izin ver, geri kalanını engelle” ilkesine dayanır
  • Mevcut Linux güvenlik mekanizmalarından daha kolay anlaşılan ve entegre edilebilen bir geliştirici dostu savunma katmanı sunar
  • Amacı, Landlock kullanımını teşvik etmek

Çalışma Şekli

  • Linux Security Module (LSM) biçiminde, Linux 5.13'ten itibaren kullanılabilir
  • SELinux veya AppArmor'dan farklı olarak, süreç bazlı geçici kısıtlama (transient restriction) uygulanır
    • Politika çalışma zamanında oluşturulur ve yalnızca mevcut iş parçacığı ile çocuk süreçlere uygulanır; süreç sonlandığında kaybolur
  • Politika bileşenleri
    1. Handled accesses: kısıtlanacak işlem kategorileri (ör. dosya sistemi okuma/yazma)
    2. Access grants: izin verilecek nesnelerin açık listesi
  • Örnek politika
    • /home/user yalnızca okunur
    • /tmp okuma/yazma
    • 2222 portuna bağlanma izni
  • landlock_restrict_self() çağrısı ile bu iş parçacığı ve çocuk süreçler kalıcı olarak kısıtlı alana girer
    • Kısıtlama geri alınamaz, en fazla 16 katman (layer) üst üste eklenebilir
    • Alt katmanlar erişimi daha da azaltabilir ancak üst katmanda kaldırılan yetkiler geri yüklenemez
  • Yetkisiz (unprivileged) çalışma ile, sıradan uygulamalar da kendi sandboxlarını kullanabilir
  • ABI versiyonlama ile eski çekirdeklerde mümkün olan aralıkta çalışır
  • Stackable LSM olduğundan SELinux ve AppArmor ile birlikte kullanılabilir

Kullanım Nedenleri

  • Tahmin edilebilir dosya erişim desenine sahip uygulamalar için uygundur
    • Örn: bir web sunucusunun erişimi yalnızca /var/www/html ve /tmp ile sınırlandırılabilir
  • Yönetici müdahalesi veya sistem genelinde ayar gerekmeyecek, politika doğrudan kod içinde tanımlanabilir
  • Yetki yükseltme olmadan kullanılabilir, çoğu programa kolayca entegre edilebilir
  • Rust, Go, Haskell için bağlayıcılar bulunur, unveil tarzı sarmalayıcı projeler de birçoğu mevcuttur
  • Resmi bir C kütüphanesi henüz yok olsa da, çeşitli gayriresmi uygulamalar kullanılabilir
  • Rust örnek kodunda /usr, /etc, /dev yalnızca okunabilir olarak, /home, /tmp ise okuma/yazma erişimiyle ayarlanır

Linux'ta Sandboxing Durumu ve Gereklilik

  • Linux kullanımıyla birlikte masaüstü odaklı kötü amaçlı yazılımlar da artmaktadır
  • Linux'un görece güvenli olması yapısal güvenlikten değil, pazar payı ve teknik engeller nedeniyle
  • Yaygın dağıtımların sorunları
    • Güvenilmemiş ikililerin çalıştırılabilmesi
    • İnternetten doğrudan betik çalıştırılabilmesi
    • Parolasız sudo kullanımı
    • Standart bir uygulamanın $HOME içindeki hassas dosyalara erişebilmesi
    • X11 ortamında tuş takibi yapılabilmesi
    • Rasgele porta bağlanabilme

Mevcut Güvenlik Araçlarının Sınırlamaları

  • Containerization (Docker, Podman): Hizmet izolasyonu için uygun ama masaüstü uygulamalar için uygun değil, --privileged seçeneğiyle izolasyonun etkisizleştirildiği örnekler vardır
  • Flatpak / Snap: GUI uygulamaları için uygun ama izin kapsamı aşırı geniş, CLI araçları için uygun değil
  • Firejail: Uygulama başına profil gerekir, her çalıştırmada açıkça çağrılması gerekir

Geliştirici Bakış Açısından Mevcut Mekanizmalar

  • seccomp: Güçlü ama yapılandırması karmaşık ve kara liste yaklaşımı kırılgan
  • SELinux: Güçlü ama karmaşık ve yönetici politikası gerekli, çoğu yaygın dağıtımda varsayılan olarak devre dışı
  • AppArmor: SELinux'tan daha basit olsa da yine yönetici profili gerekir, bazı dağıtımlarda devre dışı

Landlock'un Avantaj Özeti

  • Yetkisiz, uygulama odaklı, kolay entegre edilebilir, varsayılan reddetme (deny-by-default)
  • Linux 5.13 sonrası yaygın destek, geri/ileri uyumluluk korunur
  • Mükemmel olmasa da, basit ve bağımsız yetkisiz bir sandbox aracı olarak boşluğu doldurur

Landlock'un Uygulanabilirliği

  • Yüksek ayrıcalıklı daemon süreçleri uzun süre çalışırken Landlock ile erişim alanı sınırlandırılabilir
  • PDF okuyucu, resim görüntüleyici, web tarayıcı, kelime işlemci gibi uygulamaları yalnızca açılmış dosyalara erişecek şekilde sınırlandırabilirsiniz
  • FTP/HTTP sunucuları yalnızca gerekli dosyalara erişecek şekilde yapılandırılabilir
    • Örn: nginx root ile çalışsa bile saldırganın bir kabuk alması durumunda bile politikada olmayan dosyalara erişimi olmaz
  • Supervisor önerisi uygulanırsa, Linux masaüstüne Android benzeri bir yetkilendirme sistemi eklenebilir
    • GUI ve yetki depolama sistemi ile birleştiğinde daha güvenli bir kullanıcı deneyimi mümkün olur

Landlock'ta Devam Eden Özellik Geliştirme

  • Supervise Mode: Kullanıcı alanında erişim izni verme/ret etme etkileşimli kararına dönüşür, Android benzeri izin istemi benzeri davranır
  • Socket Restrictions: Sürecin kullanabileceği soket türleri ve portları üzerinde daha ince kontrol
  • LANDLOCK_RESTRICT_SELF_TSYNC: Kısıtlamayı süreç içindeki tüm iş parçacıklarına yayar
  • LANDLOCK_ADD_RULE_QUIET: Belirli nesneler için denetim log mesajını bastırır
  • LANDLOCK_ADD_RULE_NO_INHERIT: Üst dizin yetkisinin alt dizinlere miras kalmasını engeller, dosya sistemi kontrolünde ayrıntılı ayar sağlar

Özet

  • Landlock, basit ve yetkisiz tabanlı varsayılan reddedici bir sandbox mekanizması
  • Anlaşılması ve entegrasyonu kolaydır ve Linux masaüstü ve uygulama güvenliğini artırma konusunda büyük potansiyele sahiptir
  • Geliştirici, uygulamasına Landlock'u doğrudan ekleyerek güvenlik seviyesini artırabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-01
Hacker News görüşü
  • İstenmeyen telemetriyi engellemek için Landlock kullandım
    C ile basit bir program yazıp yalnızca belirli bir portun dinlenmesine izin verdim, diğer tüm ağ bağlantılarını engelledim
    sandboxer.c örneğine baktım ve dosya erişim kısıtlarına dokunmadan sadece ağı kontrol ettim
    Engellenen bağlantılar dmesg içinde görünüyor; muhtemelen audit özelliği sayesinde
    Bu araç ayrıcalıksız kullanıcı modunda çalışıyor ve konteyner içinde de güvenlik duvarı ayarı olmadan gayet iyi çalışıyor
    Yine de bunun kötü niyetli bir programı tamamen durdurmak için uygun olduğunu düşünmüyorum
    • Kaynak kodunu paylaşabilir misin diye merak ediyorum
  • Landlock kusursuz değil
    Issue #28 ve ilgili mail dizisine bakılırsa, sandbox kurallarının var olmayan dizinlere başvuramaması gibi bir sorun var
    Örneğin ~/.ssh henüz yokken bir kural eklerseniz, dizin daha sonra oluşturulsa bile erişim engellenmiyor
    Yani güvenlik açısından bir açık oluşabiliyor
  • itch.io oyunlarını bwrap ile sandbox içine almaya çalışıyorum
    Bunları en az ayrıcalıkla çalıştırmak epey zahmetli
    “Microlandia” çalışmıyor ama diğer Unity oyunları gayet iyi açılıyor
    Landlock tabanlı araçların çoğalmasını ve böyle işleri kolaylaştırmasını umuyorum
  • Konteyner runtime’larında Landlock’un destek durumunu merak ediyorum
    CRI’lar kendi arayüzlerini tanımlamaya çalışıyor gibi görünüyor ama bu kaçınılmaz olarak çekirdek desteğinin gerisinden gelecektir
    Çoğu altyapı sorumlusunun uygulama bazında sandbox politikalarını bakımını yapacağını sanmıyorum
    Uygulamanın Landlock’u doğrudan kullanması daha gerçekçi görünüyor
    • runc issue ve runtime-spec issue bağlantılarını anarak,
      runtime sistem çağrılarını olduğu gibi geçirirse uygulamanın kendi kendini kilitlemesine güvenmek zorunda kalınacağı sorununu açıklıyor
    • Landlock’un aslında konteyner runtime’ları için değil, başka bir amaca yönelik bir özellik olduğunu düşünüyorum
  • Bir tıbbi cihaz geliştiricisi olarak bu yaklaşım beni çok sevindirdi
    Dahili olarak benzer API’ler kullanarak kritik süreç yönetimi yapıyoruz
    Bu tür araştırmalar düzenlemeye tabi sektörler için de çok faydalı olacaktır
  • “Resmi bir C kütüphanesi yok” denmesi kulağa tuhaf geliyor
    Çekirdek özelliğiyse C API’nin doğal olarak önce gelmesi gerekmez miydi, neden yok merak ediyorum
    • Çekirdeğin temel arayüzü syscall(uapi)’dir
      libc bunun üstüne oturan bir katmandır ve bugün bile libc içinde sarmalayıcısı olmayan pek çok syscall var
    • Burada kastedilen şey glibc ya da musl gibi standart C kütüphaneleri
      İsterseniz header’ları kendiniz yazıp _syscallN makrosuyla çağırabilirsiniz
    • C API olmaması büyük bir sorun değil
      landbox gibi basit bir sarmalayıcı kullanılabilir,
      Rust veya Go da C FFI sunabilir
      Çekirdekteki sandboxer.c örneği yeterince yol gösterici
    • İçeriğin büyük bölümü man7 belgesinde zaten derlenmiş durumda
    • Çekirdek geliştiricileri userland yazılımını doğrudan üretmediği için C API yok
  • Landlock’un yalnızca TCP soketlerini kısıtladığını, UDP veya raw soketleri engellemediğini unutmamak gerekiyor
    • Bu epey büyük bir güvenlik açığı gibi görünüyor. Neden böyle olduğunu merak ediyorum
    • raw soketler yetki gerektirir ve iptables ile UID tabanlı engelleme de yapılabilir
      Landlock’la aynı şey değil ama tamamlayıcı olarak kullanılabilir
    • Yine de oldukça büyük bir delik gibi hissettiriyor
    • Garip bir kısıt ama bunu öğrenmiş olmak iyi oldu
  • Landlock’un /sys ayarları yerine yeni syscall’lar eklemiş olması ilginç
    Muhtemelen ayrıcalıksızlık ilkesi yüzündendir
    seccomp ile Landlock syscall’larını engellemenin mümkün olup olmadığını da merak ediyorum
    Eski seccomp politikaları Landlock numaralarını içermiyorsa SIGSYS oluşabilir mi?
    • Diğer LSM’ler de giderek syscall tabanlı arayüzlere geçiyor
      Dosya sistemi tabanlı API’lerde çok fazla footgun var ve dirfd tabanlı erişim denetimi için syscall daha uygun
      İyi yazılmış seccomp filtreleri -ENOSYS döndürerek bunu basitçe “desteklenmiyor” gibi gösterir
    • seccomp ile Landlock syscall’larını kısıtlamak mümkün ama pratik değeri düşük
      Çünkü Landlock mevcut yetkileri daha da kısıtlar, yeni yetkiler vermez
  • Linux güvenliğine daha yeni ilgi duymaya başladım
    Mac’ten çıkıp tamamen Linux’a geçmeye hazırlanıyorum ve Landlock’un zararlı yazılım savunmasına nasıl katkı sağlayabileceğini merak ediyorum
    Örneğin ~/.ssh erişimini otomatik reddeden bir ortam kurmak istiyorum
    Ayrıca bununla bir uygulama başlatıcısı yapılıp yapılamayacağını da bilmek istiyorum
    • Landlock’un tehdit modeli zararlı yazılımın kendisi değil, normal bir uygulamadaki kod çalıştırma açığıdır
      Amaç, uygulamanın kendi ihtiyaç duymadığı yetkileri kısıtlayarak saldırganın sistemi ele geçirmesini önlemektir
    • ~/.ssh erişimini engellemek gibi şeyler için AppArmor veya SELinux gibi bir MAC modeli gerekir
      Landlock, uygulamanın kendisini ya da alt süreçlerini kısıtlaması gerektiğinde faydalıdır
      Örneğin npm’in post-install betiklerini yalnızca build diziniyle sınırlaması gibi
      OpenBSD’deki pledge gibi, uygulama geliştiricisinin doğrudan kullandığı bir API’dir
      Ancak Linux’ta ekosistem daha parçalı olduğu için benimsenmesi yavaş olacaktır
      Bu arada wrapper veya launcher biçiminde kullanmak daha gerçekçi
    • Paket yöneticisinin build betikleri için politika tanımlaması ya da kullanıcının doğrudan wrapper kullanması gerekir
      Sonuçta sadece program kendi yetkilerini biliyorsa etkili olur
    • Kavram olarak macOS ve iOS’taki sandboxing ile neredeyse aynı
      Uygulama başta ihtiyaç duyduğu kaynakları whitelist’e alır, geri kalan her şeyi engeller
      Amaç kötü niyetli yazılımlara karşı savunma değil, kendi sürecini korumaktır
  • “Resmi bir C kütüphanesi yok” sözü komik geliyor
    Standart kütüphanede zaten syscall varken, ayrıca ayrı bir kütüphaneye gerçekten ihtiyaç var mı?
    man7 belgesi de mevcut
    Buradaki asıl isteğin yalnızca bir soyutlama katmanı olup olmadığını merak ediyorum
    • libc, syscall numaralarını yönetme ve yan etkileri ele alma işini üstlendiği için,
      glibc’nin hâlâ Landlock arayüzü sunmuyor olması şaşırtıcı
      Muhtemelen Linux dışı uyumluluk kaygılarındandır