Sebuah proses dapat lolos dari pemeriksaan permission filesystem biasa tetapi tetap menunggu sebelum operasi filenya selesai. Permission event fanotify Linux memungkinkan monitoring group mencegat operasi terpilih dan mewajibkan listener user space mengembalikan respons izinkan atau tolak. Mekanisme ini menyisipkan titik keputusan sinkron ke jalur akses, bukan sekadar melaporkan aktivitas setelah operasi terjadi.

Perbedaan tersebut membuat fanotify relevan bagi produk keamanan yang memerlukan inspeksi konten atau evaluasi policy di dekat waktu akses file. Mekanisme ini juga menciptakan dependensi yang tidak dimiliki sistem notifikasi biasa: kernel dapat menahan proses lain pada permission event sementara user space menentukan hasilnya.

Permission event berbeda dari notifikasi biasa

Sebagian besar event fanotify bersifat informasional. Listener menerima metadata yang menggambarkan aktivitas seperti open atau modifikasi, tetapi operasi itu sendiri tidak bergantung pada respons terhadap notifikasi tersebut.

Permission event memiliki semantik berbeda. Event mask seperti FAN_OPEN_PERM, FAN_ACCESS_PERM, dan FAN_OPEN_EXEC_PERM mewakili operasi yang keputusannya dapat melibatkan listener. Fanotify group yang dikonfigurasi untuk menangani permission menerima event, mengevaluasinya, lalu menulis fanotify_response yang membawa FAN_ALLOW atau FAN_DENY.

Jalur kontrolnya bersifat sinkron:

proses meminta operasi file
            |
  pemeriksaan kernel biasa
            |
 permission event fanotify
            |
   listener user space
       /          \
 FAN_ALLOW     FAN_DENY
     |             |
 lanjut          tolak

Fanotify tidak menggantikan discretionary access control, ACL, Linux Security Modules, restriction mount, atau pemeriksaan lain. Mekanisme ini menambahkan boundary keputusan lain pada cakupan event dan mark yang dikonfigurasi.

Mark menentukan permukaan intersepsi

Sebuah fanotify group tidak otomatis memediasi setiap file pada mesin. fanotify_mark() menetapkan objek dan event mask yang terkait dengan group. Mark dapat menargetkan objek yang didukung seperti filesystem atau mount, sesuai aturan API dan dukungan kernel untuk tipe mark serta event yang dipilih.

Cakupan ini merupakan bagian dari properti keamanan. Daemon yang memantau satu mount tidak dapat mengklaim enforcement policy pada mount yang tidak terkait. Exclusion dan ignored mask juga dapat mengubah pengiriman event. Permukaan enforcement efektif merupakan irisan antara konfigurasi group, mark, event mask, dukungan filesystem, dan operasi yang benar-benar dilakukan.

Topologi path juga berpengaruh secara operasional. Daemon policy dapat menilai file berdasarkan nama, tetapi event terikat pada objek kernel yang dicapai oleh akses. Rename, bind mount, namespace, dan path alternatif dapat membuat model policy berbasis pathname saja tidak lengkap meski pengiriman event berfungsi dengan benar.

File descriptor event menjadi capability ke objek

Untuk permission event yang menyediakan file descriptor objek, metadata yang dibaca dari descriptor fanotify memuat fd yang merujuk ke objek terkait. Listener dapat memeriksa descriptor tersebut alih-alih membuka ulang pathname yang mungkin telah berubah antara pembuatan event dan evaluasi policy.

Properti ini mengurangi race yang umum pada scanner file. Membuka ulang path yang dilaporkan membuat lookup kedua yang dapat mengarah ke objek berbeda setelah rename atau replacement. Inspeksi melalui descriptor dari event menjaga evaluasi tetap terikat pada objek yang terkait dengan event tersebut.

Descriptor tetap memerlukan pengelolaan lifecycle yang disiplin. Listener harus menutup descriptor event setelah pemrosesan. Kebocoran satu descriptor per event dapat menghabiskan resource proses atau sistem dan mengubah kontrol keamanan menjadi masalah availability.

Pathname masih dapat berguna sebagai konteks policy, tetapi pathname tidak boleh diam-diam dianggap sebagai identitas objek ketika keputusan memerlukan identitas objek yang stabil.

Respons melepaskan operasi yang tertahan

Struktur respons mengaitkan keputusan dengan file descriptor event. Respons konseptual minimal memiliki bentuk berikut:

struct fanotify_response response = {
    .fd = event_fd,
    .response = FAN_ALLOW,
};

write(fanotify_fd, &response, sizeof(response));

Kode produksi harus memvalidasi record event, menangani I/O parsial atau gagal dengan benar, menutup descriptor, dan menerapkan policy yang disengaja untuk kondisi error. Cuplikan tersebut hanya menunjukkan ikatan antara descriptor event dan keputusan.

Respons allow berarti fanotify tidak memblokir operasi itu pada titik keputusan permission tersebut. Respons ini bukan grant yang mengesampingkan penolakan kernel sebelum atau sesudahnya. Respons deny menolak operasi yang dimediasi melalui boundary fanotify.

Perbedaan ini mencegah asumsi policy yang berbahaya: scanner tidak dapat memakai FAN_ALLOW untuk menciptakan akses yang sebelumnya tidak dimiliki caller.

Availability listener menjadi bagian dari availability akses

Mediasi sinkron mengikat latensi akses file pada listener. Jika evaluasi policy memerlukan hashing file besar, menghubungi service lain, menunggu storage, atau melakukan parsing mahal, proses peminta tetap tertahan selama keputusan tersebut.

Arsitektur keamanan karena itu mencakup boundary availability. Listener yang macet dapat menahan operasi yang tercakup. Listener yang mengonsumsi event terlalu lambat juga dapat menghadapi tekanan queue. Fanotify menyediakan pelaporan queue overflow, dan deployment perlu memperlakukan overflow sebagai event state policy, bukan sekadar kehilangan telemetri biasa.

Tidak ada policy kegagalan yang tepat untuk semua sistem. Scanner malware yang melindungi eksekusi dapat memilih penolakan ketika hasil yang dapat diterima tidak tersedia. Service yang memprioritaskan availability dapat menerima kondisi fail-open yang lebih sempit. Pilihan itu merupakan policy deployment dan harus eksplisit; API fanotify tidak mengubah kegagalan operasional menjadi jawaban keamanan universal.

Listener sendiri juga menjadi infrastruktur sensitif. Scheduling, resource limit, perilaku restart, dan dependency graph miliknya dapat memengaruhi setiap proses yang operasinya berada di dalam permukaan mediasi.

Inspeksi konten memiliki boundary waktu keputusan

Memegang descriptor event memberi listener referensi stabil ke objek, tetapi tidak otomatis membekukan isi file yang mutable. Aktor lain dengan authority yang sesuai mungkin dapat memodifikasi file selama inspeksi berlangsung atau setelah keputusan allow diberikan.

Batas ini mempersempit klaim yang dapat dibuat dari scanning saja. Keputusan allow dapat menyatakan bahwa listener menerima state yang dievaluasi berdasarkan asumsi sinkronisasinya. Keputusan tersebut tidak secara inheren membuat file immutable selama sisa lifetime-nya.

Sistem yang membutuhkan properti lebih kuat memerlukan mekanisme lain untuk mengikat konten yang disetujui dengan penggunaan berikutnya. Storage read-only, mekanisme integritas, artefak deployment immutable, atau koordinasi khusus aplikasi dapat mempersempit jendela mutasi. Mekanisme yang tepat bergantung pada objek dan threat model.

Boundary yang sama berlaku pada metadata. Policy berbasis owner, label, atau konteks path harus memperhitungkan properti mana yang dapat berubah secara concurrent dan referensi kernel mana yang tetap stabil selama evaluasi.

Identitas event dan identitas proses perlu diperlakukan terpisah

Metadata fanotify dapat mengidentifikasi proses yang terkait dengan event, tetapi process identifier dan object descriptor mewakili jenis identitas yang berbeda. PID numerik bukan nama principal permanen; lifetime proses dan penggunaan ulang PID membuat keputusan tertunda yang hanya bergantung pada nilai numerik tersimpan menjadi rapuh.

Konfigurasi fanotify modern dapat meminta information record tambahan ketika didukung, termasuk record yang dirancang untuk memperbaiki penanganan referensi proses. Aplikasi sebaiknya mendasarkan authorization pada data identitas dan fitur kernel yang benar-benar diminta serta diterima, bukan menyimpulkan jaminan lebih kuat dari PID biasa.

Hal ini sangat relevan ketika listener mendelegasikan evaluasi policy ke komponen lain. Hanya meneruskan pathname dan PID melalui pipeline asynchronous yang panjang dapat membuang referensi stabil yang membuat event awal bernilai.

Mediasi permission lebih sempit daripada sandbox lengkap

Fanotify bekerja pada event filesystem yang didukung. Mekanisme ini bukan mesin policy system call umum dan tidak membatasi akses network, IPC, pembuatan proses, operasi memory, atau interface kernel arbitrer. Bahkan di domain filesystem, enforcement hanya mencakup tipe event dan objek yang dipilih group.

Deployment yang kuat karena itu memperlakukan fanotify sebagai salah satu komponen enforcement. Policy LSM dapat menerapkan aturan akses mandatory, desain namespace dan mount dapat membatasi visibility, kontrol integritas dapat mengikat state konten, dan fanotify dapat menambahkan keputusan user space ketika inspeksi dinamis diperlukan.

Properti yang bertahan bersifat spesifik: untuk permission event yang tercakup, kernel dapat menahan operasi file sampai fanotify group yang bertanggung jawab mengembalikan keputusan. Kemampuan tersebut berguna karena sinkron dan berorientasi objek, tetapi properti yang sama membuat correctness listener, cakupan, latensi, dan penanganan kegagalan menjadi bagian dari security boundary.

Keamanan Siber Linux Kontrol Akses Filesystem