Menerapkan Landlock di Linux

 (blog.prizrak.me)
1 poin oleh GN⁺ 2025-12-01 | 1 komentar | Bagikan ke WhatsApp
  • Landlock adalah API keamanan Linux yang membuat aplikasi melakukan sandboxing mandiri di tingkat kernel dengan mendeklarasikan secara eksplisit sumber daya yang boleh diakses
  • Dibandingkan SELinux atau AppArmor, Landlock lebih sederhana, dan kebijakan dapat dibuat serta diterapkan saat runtime tanpa hak istimewa pengembang
  • Kebijakan didefinisikan dalam bentuk allowlist eksplisit untuk file, direktori, port, dan lainnya yang boleh diakses, serta memungkinkan penguatan keamanan bertahap melalui pembatasan hierarkis
  • Tersedia binding untuk Rust, Go, Haskell, sehingga kontrol akses yang terperinci bisa diterapkan di berbagai lingkungan seperti aplikasi GUI, server, dan proses desktop
  • Dalam ekosistem keamanan Linux, Landlock mendapat perhatian sebagai alat sandbox tanpa hak istimewa yang sederhana dan praktis, serta dipandang sebagai komponen kunci untuk memperkuat keamanan desktop ke depan

Gambaran umum Landlock

  • Landlock adalah API yang memungkinkan aplikasi Linux mendeklarasikan secara eksplisit sumber daya yang dapat mereka akses
    • Mirip dengan konsep unveil() dan pledge() di OpenBSD, berlandaskan prinsip “hanya izinkan sumber daya yang diperlukan, blokir sisanya”
  • Menyediakan lapisan pertahanan yang ramah pengembang yang lebih mudah dipahami dan diintegrasikan dibanding mekanisme keamanan Linux yang sudah ada
  • Tujuannya adalah memberi pengenalan yang mudah dipahami sekaligus mendorong penggunaan Landlock

Cara kerjanya

  • Berbentuk Linux Security Module(LSM) dan tersedia sejak Linux 5.13
  • Tidak seperti SELinux atau AppArmor, Landlock menerapkan pembatasan sementara tingkat proses (transient restriction)
    • Kebijakan dibuat saat runtime, hanya berlaku untuk thread saat ini dan proses anaknya, lalu hilang saat proses berakhir
  • Komponen kebijakan
    1. Handled accesses: kategori operasi yang akan dibatasi (misalnya baca/tulis sistem file)
    2. Access grants: daftar eksplisit objek yang diizinkan
  • Contoh kebijakan
    • /home/user hanya-baca
    • /tmp baca/tulis
    • Mengizinkan bind ke port 2222
  • Saat landlock_restrict_self() dipanggil, thread tersebut dan proses anaknya secara permanen masuk ke area terbatas
    • Pembatasan tidak bisa dicabut, dan dapat ditumpuk hingga maksimum 16 lapisan (layer)
    • Lapisan bawah dapat lebih mengurangi akses, tetapi hak yang sudah dihapus pada lapisan atas tidak dapat dipulihkan
  • Bekerja secara tanpa hak istimewa (unprivileged), sehingga aplikasi biasa pun dapat melakukan sandboxing mandiri
  • Melalui manajemen versi ABI, Landlock tetap dapat berjalan sejauh mungkin bahkan pada kernel yang lebih lama
  • Sebagai Stackable LSM, Landlock dapat digunakan bersamaan dengan SELinux atau AppArmor

Alasan menggunakannya

  • Cocok untuk aplikasi dengan pola akses file yang dapat diprediksi
    • Contoh: membatasi web server agar hanya dapat mengakses /var/www/html dan /tmp
  • Tidak memerlukan campur tangan administrator atau pengaturan global sistem, karena kebijakan bisa didefinisikan langsung di dalam kode
  • Dapat digunakan tanpa eskalasi hak akses, sehingga mudah diintegrasikan ke sebagian besar program
  • Ada binding untuk Rust, Go, Haskell, dan juga banyak proyek pembungkus bergaya unveil
  • Belum ada pustaka C resmi, tetapi sudah ada beberapa implementasi tidak resmi yang dapat digunakan
  • Contoh kode Rust mengatur /usr, /etc, /dev sebagai hanya-baca, dan /home, /tmp sebagai baca/tulis

Kondisi sandboxing Linux saat ini dan kebutuhannya

  • Seiring meningkatnya penggunaan Linux, malware yang menargetkan desktop juga meningkat
  • Keamanan Linux yang relatif lebih baik lebih disebabkan oleh pangsa pasar dan hambatan teknis, bukan karena keamanan struktural
  • Masalah pada distribusi umum
    • Dapat menjalankan biner yang tidak tepercaya
    • Dapat langsung menjalankan skrip dari internet
    • Menggunakan sudo tanpa kata sandi
    • Aplikasi biasa dapat mengakses file sensitif di dalam $HOME
    • Dapat memantau penekanan tombol di lingkungan X11
    • Dapat melakukan bind ke port arbitrer

Keterbatasan alat keamanan yang ada

  • Containerization (Docker, Podman) : cocok untuk isolasi layanan, tetapi kurang sesuai untuk aplikasi desktop, dan ada kasus isolasi dinonaktifkan melalui opsi --privileged
  • Flatpak / Snap: cocok untuk aplikasi GUI tetapi cakupan izinnya berlebihan, serta kurang cocok untuk alat CLI
  • Firejail: memerlukan profil per aplikasi, dan harus dipanggil secara eksplisit setiap kali dijalankan

Mekanisme yang ada dari sudut pandang pengembang

  • seccomp: kuat tetapi konfigurasi rumit, dan pendekatan blacklist rentan
  • SELinux: kuat tetapi kompleks dan memerlukan kebijakan administrator; pada banyak distribusi dinonaktifkan secara bawaan
  • AppArmor: lebih sederhana daripada SELinux tetapi tetap memerlukan profil administrator, dan dinonaktifkan di sebagian distribusi

Ringkasan keunggulan Landlock

  • Tanpa hak istimewa, berpusat pada aplikasi, mudah diintegrasikan, deny-by-default
  • Didukung luas sejak Linux 5.13, sambil tetap menjaga kompatibilitas maju dan mundur
  • Meski tidak sempurna, Landlock menutup celah sebagai alat sandbox tanpa hak istimewa yang sederhana dan mandiri

Kemungkinan penerapan Landlock

  • Pada proses daemon berhak tinggi yang berjalan lama, Landlock dapat digunakan untuk membatasi cakupan akses
  • Pembaca PDF, penampil gambar, browser web, pengolah kata dan sejenisnya dapat dibatasi agar hanya mengakses file yang dibuka
  • Server FTP/HTTP dapat dikonfigurasi agar hanya mengakses file yang diperlukan
    • Contoh: meskipun nginx berjalan sebagai root, penyerang yang memperoleh shell tetap tidak dapat mengakses file di luar kebijakan
  • Jika usulan Supervisor diterapkan, sistem izin mirip Android dapat diwujudkan di desktop Linux
    • Bila digabungkan dengan GUI dan sistem penyimpanan izin, hal ini dapat menghadirkan pengalaman pengguna yang lebih aman

Pengembangan fitur Landlock yang sedang berlangsung

  • Supervise Mode: menentukan izin/tolak akses secara interaktif dari user space, mirip prompt izin ala Android
  • Socket Restrictions: kontrol rinci atas jenis socket dan port yang dapat digunakan proses
  • LANDLOCK_RESTRICT_SELF_TSYNC: menyebarkan pembatasan ke semua thread dalam proses
  • LANDLOCK_ADD_RULE_QUIET: menekan pesan log audit untuk objek tertentu
  • LANDLOCK_ADD_RULE_NO_INHERIT: mencegah izin direktori induk diwariskan ke bawah, sehingga kontrol sistem file menjadi lebih rinci

Ringkasan

  • Landlock adalah mekanisme sandbox deny-by-default yang sederhana dan berbasis tanpa hak istimewa
  • Mudah dipahami dan diintegrasikan, serta memiliki potensi besar untuk meningkatkan keamanan desktop Linux dan aplikasi
  • Pengembang dapat menerapkan Landlock langsung ke aplikasi untuk memperkuat tingkat keamanannya

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-01
Opini Hacker News
  • Saya memblokir telemetri yang tidak diinginkan dengan Landlock
    Saya menulis program sederhana dalam C agar hanya menerima pada satu port tertentu, lalu memblokir semua koneksi jaringan lainnya
    Saya merujuk ke contoh sandboxer.c, dan hanya mengontrol jaringan tanpa menyentuh pembatasan akses file
    Koneksi yang diblokir terlihat di dmesg, kemungkinan berkat fitur audit
    Alat ini bekerja dalam mode pengguna tanpa hak istimewa, dan juga berjalan baik di dalam kontainer tanpa pengaturan firewall
    Namun, saya rasa ini tidak cocok untuk tujuan memblokir program jahat sepenuhnya
    • Penasaran apakah Anda bisa membagikan source code-nya
  • Landlock tidak sempurna
    Jika melihat isu #28 dan thread email terkait, ada masalah bahwa aturan sandbox tidak bisa merujuk ke direktori yang belum ada
    Misalnya, jika Anda menambahkan aturan saat ~/.ssh belum ada, maka meskipun direktori itu dibuat nanti, aksesnya tidak akan diblokir
    Artinya, bisa timbul celah keamanan
  • Saya sedang mencoba melakukan sandboxing game itch.io dengan bwrap
    Menjalankannya dengan hak minimum ternyata cukup rumit
    “Microlandia” tidak bisa berjalan, tetapi game Unity lain berjalan baik
    Saya berharap akan ada lebih banyak alat berbasis Landlock agar pekerjaan seperti ini jadi lebih mudah
  • Saya penasaran dengan status dukungan Landlock di runtime kontainer
    Sepertinya CRI mencoba mendefinisikan antarmuka mereka sendiri, tetapi pasti selalu tertinggal dari dukungan kernel
    Saya rasa sebagian besar penanggung jawab infrastruktur tidak akan memelihara kebijakan sandbox per aplikasi
    Menurut saya, lebih realistis bila aplikasi menggunakan Landlock secara langsung
    • Sambil menyebut isu runc dan isu runtime-spec,
      dijelaskan bahwa jika runtime begitu saja meneruskan system call, akan muncul masalah harus mempercayai aplikasi untuk mengunci dirinya sendiri
    • Saya rasa Landlock pada dasarnya bukan untuk runtime kontainer, melainkan fitur dengan tujuan lain
  • Sebagai pengembang perangkat medis, saya sangat menyambut pendekatan seperti ini
    Secara internal kami memakai API serupa untuk manajemen proses penting
    Riset seperti ini akan sangat membantu juga di industri yang diregulasi
  • Pernyataan “tidak ada pustaka C resmi” terdengar aneh
    Jika ini fitur kernel, bukankah wajar jika API C hadir lebih dulu; saya jadi bertanya-tanya kenapa tidak ada
    • Antarmuka dasar kernel adalah syscall (uapi)
      libc hanyalah lapisan di atasnya, dan sampai sekarang banyak syscall yang tetap ada tanpa wrapper di libc
    • Yang dimaksud di sini adalah pustaka C standar seperti glibc atau musl
      Anda juga bisa membuat header sendiri dan memanggilnya dengan makro _syscallN
    • Tidak adanya API C juga bukan masalah besar
      Anda bisa memakai wrapper sederhana seperti landbox,
      dan Rust atau Go juga bisa mengekspos C FFI
      Cukup melihat contoh sandboxer.c dari kernel
    • Sebagian besar isinya sudah dirangkum di dokumentasi man7
    • Pengembang kernel tidak langsung membuat perangkat lunak userland, itulah sebabnya tidak ada API C
  • Perlu diperhatikan bahwa Landlock hanya membatasi soket TCP, dan tidak memblokir UDP atau soket raw
    • Itu terlihat seperti celah keamanan yang cukup besar. Saya penasaran apa alasannya
    • Soket raw memerlukan hak akses, dan pemblokiran berbasis UID juga bisa dilakukan dengan iptables
      Memang berbeda dari Landlock, tetapi bisa dipakai secara saling melengkapi
    • Tetap saja terasa seperti lubang yang cukup besar
    • Batasan yang aneh, tetapi untung saya jadi tahu
  • Menarik bahwa Landlock menambahkan syscall baru alih-alih memakai pengaturan /sys
    Mungkin itu karena prinsip tanpa hak istimewa
    Saya juga penasaran apakah syscall Landlock bisa diblokir dengan seccomp
    Jika kebijakan seccomp lama tidak memasukkan nomor Landlock, bukankah bisa memicu SIGSYS?
    • LSM lain juga makin beralih ke basis syscall
      API berbasis filesystem punya banyak footgun, dan untuk kontrol akses berbasis dirfd, syscall lebih cocok
      Filter seccomp yang ditulis dengan baik akan mengembalikan -ENOSYS sehingga hanya terlihat seperti “tidak didukung”
    • Syscall Landlock memang bisa dibatasi dengan seccomp, tetapi kegunaan praktisnya rendah
      Karena Landlock hanya membatasi hak yang sudah ada, bukan memberikan hak baru
  • Saya baru mulai tertarik pada keamanan Linux
    Saya sedang bersiap benar-benar pindah ke Linux dari Mac, dan penasaran seberapa besar Landlock membantu untuk pertahanan terhadap malware
    Misalnya, saya ingin membuat lingkungan yang otomatis menolak akses ke ~/.ssh
    Saya juga ingin tahu apakah ini bisa dipakai untuk membuat peluncur aplikasi
    • Model ancaman Landlock bukanlah malware itu sendiri, melainkan kerentanan eksekusi kode pada aplikasi normal
      Fungsinya agar aplikasi membatasi sendiri hak yang tidak dibutuhkannya, sehingga penyerang tidak bisa mengambil alih sistem
    • Pemblokiran akses seperti ~/.ssh memerlukan model MAC seperti AppArmor atau SELinux
      Landlock berguna saat aplikasi membatasi dirinya sendiri atau proses anaknya
      Misalnya npm membatasi skrip post-install hanya ke direktori build
      Ini adalah API yang dipakai langsung oleh pengembang aplikasi, seperti pledge di OpenBSD
      Namun karena ekosistem Linux terfragmentasi, penerapannya kemungkinan akan lambat
      Untuk sementara, bentuk wrapper atau launcher adalah pendekatan yang lebih realistis
    • Package manager perlu menetapkan kebijakan untuk skrip build, atau pengguna sendiri harus memakai wrapper
      Pada akhirnya ini hanya efektif jika program tahu hak aksesnya sendiri
    • Ini hampir sama persis dengan konsep sandboxing di macOS dan iOS
      Aplikasi pada awal eksekusi menetapkan whitelist sumber daya yang diperlukan lalu memblokir sisanya
      Ini bukan untuk pertahanan terhadap program jahat, melainkan melindungi prosesnya sendiri
  • Ucapan “tidak ada pustaka C resmi” terdengar lucu
    Syscall sudah ada di pustaka standar, jadi apakah benar perlu pustaka terpisah?
    Dokumentasi man7 juga sudah ada
    Saya penasaran apakah maksudnya hanya menginginkan lapisan abstraksi
    • libc berperan menangani nomor syscall maupun efek sampingnya,
      jadi cukup mengejutkan bahwa glibc masih belum menyediakan antarmuka Landlock
      Mungkin alasannya karena masalah kompatibilitas non-Linux