Sandbox Linux dan Fil-C

 (fil-c.org)
1 poin oleh GN⁺ 2025-12-14 | 1 komentar | Bagikan ke WhatsApp
  • Keamanan memori dan sandboxing adalah konsep keamanan yang saling independen, dan keduanya harus dimiliki untuk membentuk sistem pertahanan yang kuat
  • Fil-C adalah implementasi aman memori untuk C/C++, yang menjamin keamanan hingga tingkat system call Linux dan dapat digunakan bahkan pada komponen sistem seperti OpenSSH
  • Dalam proses mem-porting sandbox berbasis seccomp-BPF milik OpenSSH ke Fil-C, pembatasan pembuatan thread dan penyesuaian filter seccomp menjadi tantangan utama
  • Untuk pengelolaan thread latar belakang pada runtime Fil-C, ditambahkan API zlock_runtime_threads() untuk mengendalikan perilaku thread di dalam sandbox
  • Fil-C mengimplementasikan sinkronisasi penerapan pemanggilan prctl ke semua thread runtime, agar no_new_privs dan filter seccomp diterapkan secara konsisten ke seluruh proses

Hubungan antara keamanan memori dan sandboxing

  • Keamanan memori dan sandboxing adalah dua lapisan keamanan yang berbeda; hanya memiliki salah satunya tidak memberikan perlindungan yang lengkap
    • Contoh aman memori tetapi tidak di-sandbox: program Java yang dapat menimpa file melalui input pengguna
    • Contoh di-sandbox tetapi tidak aman memori: program dengan hak terbatas yang ditulis dalam assembly
  • Sandbox nyata juga memiliki celah struktural, seperti mengizinkan komunikasi dengan proses broker
  • Karena itu, menggabungkan keamanan memori dan sandboxing adalah pendekatan pertahanan terbaik

Menggabungkan Fil-C dan sandbox OpenSSH

  • Fil-C adalah implementasi aman memori untuk C/C++, yang mempertahankan keamanan pada tingkat system call Linux
    • Runtime Fil-C dapat berjalan bahkan pada komponen sistem level rendah seperti init dan udevd
    • OpenSSH berjalan normal di atas Fil-C dan memanfaatkan sandbox seccomp-BPF
  • Di Linux, OpenSSH membangun sandbox dengan alat berikut
    • chroot untuk membatasi akses filesystem
    • Menjalankan proses sebagai pengguna/grup sshd
    • setrlimit untuk membatasi pembukaan file dan pembuatan proses
    • Filter seccomp-BPF untuk hanya mengizinkan system call yang diperbolehkan
    Iklan
  • Fil-C pada dasarnya mendukung chroot dan pergantian pengguna, tetapi setrlimit dan seccomp-BPF dapat berbenturan dengan perilaku runtime sehingga memerlukan penyesuaian tambahan

Kontrol thread pada runtime Fil-C

  • Runtime Fil-C menggunakan thread latar belakang untuk garbage collection, dan akan menghentikan serta memulainya kembali secara otomatis bila diperlukan
  • Sandbox setrlimit milik OpenSSH bertujuan melarang pembuatan proses baru, sehingga pembuatan thread oleh runtime dapat melanggar tujuan tersebut
  • Untuk mengatasinya, API zlock_runtime_threads() ditambahkan ke <stdfil.h>
    • Runtime segera membuat thread yang dibutuhkan, lalu menonaktifkan penghentian otomatis setelahnya
    • Dipanggil di fungsi ssh_sandbox_child milik OpenSSH sebelum pemanggilan setrlimit atau seccomp-BPF

Penyesuaian filter seccomp OpenSSH

  • Setelah zlock_runtime_threads() diterapkan, sebagian besar fitur sandbox tetap bekerja seperti semula
  • Perubahan berikut dilakukan pada filter seccomp
    • Saat terjadi pelanggaran, diatur ke SECCOMP_RET_KILL_PROCESS agar thread latar belakang Fil-C juga ikut dihentikan
    • MAP_NORESERVE ditambahkan ke daftar yang diizinkan untuk mendukung allocator memori Fil-C
    • Pemanggilan sched_yield diizinkan karena digunakan dalam implementasi lock milik Fil-C
    Iklan
  • Pemanggilan futex untuk sinkronisasi di Fil-C sudah diizinkan, sehingga tidak memerlukan perubahan tambahan

Cara kerja implementasi prctl di Fil-C

  • Saat memasang filter seccomp, OpenSSH menggunakan dua pemanggilan prctl
    • PR_SET_NO_NEW_PRIVS untuk mencegah perolehan hak tambahan
    • PR_SET_SECCOMP, SECCOMP_MODE_FILTER untuk mengaktifkan filter
  • Masalahnya, prctl hanya berlaku pada thread yang memanggilnya, sehingga ada risiko thread runtime Fil-C lainnya tetap tanpa filter
  • Untuk mencegah hal ini, Fil-C menggunakan API filc_runtime_threads_handshake() agar penerapan dilakukan secara tersinkron ke semua thread runtime
    • Menjamin setiap thread melakukan pemanggilan prctl yang sama
    • Jika ada beberapa thread pengguna, Fil-C memunculkan error keamanan Fil-C untuk memperkuat perlindungan

Kesimpulan

  • Menggabungkan keamanan memori dan sandboxing adalah kombinasi keamanan yang paling kuat
  • Fil-C mengintegrasikan sepenuhnya sandbox berbasis seccomp milik OpenSSH sambil tetap menjaga keamanan memori tanpa menurunkan tingkat perlindungan
  • Dengan memanfaatkan Fil-C di lingkungan Linux, keamanan tingkat sistem dan keamanan tingkat bahasa dapat diperoleh secara bersamaan

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-14
Komentar Hacker News

  • Bertanya-tanya kenapa tidak ada penyebutan tentang landlock

  • Ada pendekatan kompilasi hibrida C → WASM → C
    Dengan cara ini, interaksi dengan OS bisa dikendalikan sepenuhnya, sambil melakukan sandboxing akses memori seperti WASM, tetapi secara teknis tetap dipertahankan sebagai kode C
    Materi terkait bisa dilihat di RLBox

    • Sandbox WASM tidak menjamin soundness program
      Memori masih bisa dirusak, hanya saja cakupannya dibatasi di dalam sandbox
      Sistem seperti SECCOMP bersifat birokratis karena semua kebijakan interaksi harus didefinisikan secara sangat rinci
      Sebaliknya, Fil-C mengambil pendekatan di mana bahasa dan runtime-nya sendiri berusaha menjamin perilaku program yang benar
      Binary Fil-C adalah executable biasa, jadi tetap bisa dipakai bersama sandbox seperti SECCOMP
      Linux butuh 20 tahun untuk membuat antarmuka prctl, jadi untuk melihat hal serupa di WASI sepertinya harus menunggu sekitar 10 tahun lagi
    • RLBox adalah teknologi sandboxing, bukan teknologi keamanan memori
      Bahkan di dalam sandbox pun masih bisa tercipta alur eksekusi yang aneh

  • Penulis Fil-C memang pandai membuat penemuan yang menarik secara teknis, tetapi ada kekhawatiran apakah implementasinya sudah cukup tervalidasi
    Disebutkan bahwa program setuid bisa dikompilasi dengan Fil-C, tetapi bagian yang memodifikasi ld.so bisa berisiko
    Aplikasi setuid harus ditulis dengan sangat defensif terhadap variabel lingkungan, file descriptor, rlimit, sinyal, dan sebagainya
    Bagian-bagian seperti ini masih belum matang, jadi ada risiko jika dipakai di infrastruktur nyata
    Meski begitu, menguji codebase dengan Fil-C mungkin bisa menemukan bug yang menarik

    • Saat ini sedang menguji apakah ada cara untuk menjebol Fil-C
    • Kalau memang benar-benar khawatir, sebaiknya lakukan eksperimen sendiri dan bagikan hasilnya
    • Tujuannya adalah membuat runtime cukup transparan sehingga auditing bisa dilakukan
      Modifikasi ld.so hanyalah perubahan kecil untuk mengajarkan layout libc
      Bug getenv terkait setuid juga sudah diperbaiki menjadi secure_getenv
      Dalam kritik tadi ada sebagian kebenaran dan sebagian FUD
    • Sikap penulis Fil-C yang menanggapi kritik secara kurang kooperatif cukup disayangkan
      Dalam kondisi data race, pointer dan capability di Fil-C bisa tidak selaras
      Hal ini bisa menyebabkan pelanggaran keamanan memori
      Penulis menyangkalnya, tetapi membandingkannya dengan Java tidak tepat
      Teknologinya hebat, tetapi sikap penulis menurunkan tingkat kepercayaan

  • WASM adalah sandbox sekaligus lingkungan eksekusi, dan tergantung cara penggunaannya, bisa memberi tingkat keamanan memori tertentu
    Jika C dikompilasi ke WASM, bug-nya tetap ada, tetapi dampaknya menjadi terbatas
    Karena itu, menggolongkan WASM sebagai teknologi sandboxing memang tepat, tetapi sebagai lingkungan eksekusi ia punya kemungkinan yang lebih luas

    • Pada akhirnya WASM adalah teknologi sandboxing
      Bug di modul B bisa membaca data modul A
      Artinya, WASM tak lebih dari pengganti sandbox proses ringan
    • Ucapan “tergantung cara dipakai” itu sendiri adalah bukti bahwa WASM tidak sepenuhnya aman
      Tentang C pun kita bisa bilang “aman tergantung cara dipakai”
    • WASM tidak memahami model memori C, jadi tidak bisa mengimplementasikan proteksi seperti Fil-C
      WASM memang mencegah runtime escape, tetapi tidak mencegah pelarian memori di dalam program itu sendiri

  • Meminta perbandingan Fil-C dengan Rust

    • Keduanya sama-sama hebat, tetapi pendekatannya berbeda
      Fil-C cocok untuk memperkuat program C yang sudah ada dengan fokus pada kompatibilitas dan keamanan
      Rust bagus untuk codebase baru yang membutuhkan keamanan statis dan kinerja
      Fil-C punya sedikit penurunan performa, tetapi berguna untuk kode C yang sudah ada seperti ffmpeg, nginx, sudo, dan lain-lain
      Rust unggul dalam multithreading dan sistem tipe
    • Fil-C memperkenalkan GC sehingga bisa menimbulkan penurunan performa
      Tujuannya adalah menjamin keamanan memori, bukan memperbaiki desain bahasa
      Pesaingnya lebih dekat ke D, Nim, dan Go daripada Rust
    • Fil-C menggunakan pemeriksaan runtime untuk mendeteksi akses memori yang tidak aman lalu menghentikan program
      Rust mencegahnya saat compile time
      Kedua pendekatan ini ortogonal, dan ke Rust pun bisa ditambahkan pemeriksaan runtime ala Fil-C

  • MicroVM makin populer
    Menarik bagaimana Fil-C bisa memanfaatkannya

    • Mungkin perlu sedikit porting, tetapi sebagian fitur microVM bisa juga dibawa ke userland aman-memori milik Fil-C

  • Berharap proyek ini mendapat lebih banyak perhatian
    Akan bagus jika alat inti seperti sudo atau polkit bisa didistribusikan secara aman-memori

  • Berharap pemanfaatan sandboxing juga makin banyak di bahasa yang aman-memori
    Disayangkan bahwa bahkan di Rust atau Go pun sandbox level OS jarang dipakai dengan baik

    • Seccomp lemah dalam portabilitas dan komposabilitas
      Sulit dikonfigurasi per pustaka, dan sensitif terhadap versi kernel maupun implementasi libc
      Input di balik pointer seperti path file juga tidak bisa difilter, jadi ada batasannya
      Karena itu, biasanya harus dikonfigurasi langsung di tingkat aplikasi
    • Rust hampir tidak punya runtime, jadi cocok untuk sandboxing
      Sebaliknya, runtime Go besar sehingga sulit dibuat aman seperti Fil-C

  • Bertanya apa bedanya Fil-C dengan Address Sanitizer (ASan) milik clang
    Jika hanya sebatas memunculkan panic saat runtime, bukankah sulit menyebutnya sebagai “aman-memori”?

    • ASan bagus untuk menangkap bug, tetapi tidak menjamin keamanan memori yang sepenuhnya
      Ada bug tertentu yang tidak bisa dideteksi
      Karena memakai pendekatan “red zone” di sekitar memori, pendeteksian kadang bergantung pada keberuntungan
    • Jika kesalahan memori bisa dihentikan dengan panic sebelum menimbulkan dampak, itu juga bisa dianggap sebagai keamanan memori
      Keamanan memori bukan berarti “tidak pernah crash”, melainkan “akses yang salah tidak bisa menimbulkan efek”

  • Bertanya mengapa tidak memakai VM penuh sebagai sandbox

    • VM adalah sandbox yang hebat, tetapi aplikasi seperti Chrome atau OpenSSH memerlukan pemisahan hak akses
      Satu proses mem-parsing input tanpa hak istimewa, sementara proses lain berjalan dengan hak lebih tinggi
      Kedua proses itu berkomunikasi lewat IPC
      Memakai VM memang meningkatkan keamanan, tetapi overhead-nya besar dan fitur seperti GPU atau akses file jadi rumit
      Karena itu, umumnya sandbox level OS lebih rapi
    • VM memang menyelesaikan sebagian besar masalah, tetapi akselerasi grafis desktop masih sulit
      GPU harus dialokasikan secara khusus, dan Qubes pun hanya terhubung lewat X11 forwarding sehingga tanpa akselerasi