Sebuah file dapat disimpan pada media yang tingkat kepercayaannya lebih rendah daripada proses yang mengonsumsinya. Menjadikan file tersebut read-only melalui permission bit biasa tidak membuktikan bahwa byte yang kemudian dikembalikan dari storage sama dengan byte yang sebelumnya disetujui. Linux fs-verity menangani batas integritas yang lebih sempit ini pada filesystem yang didukung dengan mengikat pembacaan file yang telah diaktifkan ke Merkle tree dan digest file yang stabil.
Mekanisme ini memiliki dua peran keamanan yang berbeda. Kernel memverifikasi data file terhadap Merkle tree saat data dibaca. Kebijakan terpisah harus menetapkan bahwa digest fs-verity yang dihasilkan memang digest yang dimaksudkan untuk dipercaya oleh sistem. Menganggap kedua peran tersebut sebagai satu jaminan akan melebihkan properti yang diberikan fitur filesystem ini.
Mengaktifkan verity membekukan isi file yang diukur
Userspace mengaktifkan fitur pada regular file dengan FS_IOC_ENABLE_VERITY. Request menentukan parameter seperti algoritma hash, ukuran blok, dan salt opsional. Filesystem membangun Merkle tree, menyimpan metadata verity pada lokasi yang spesifik untuk filesystem, lalu menandai inode sebagai verity file.
Operasi ini memerlukan input yang stabil. Ioctl dijalankan pada descriptor O_RDONLY, pemanggil harus memiliki akses tulis ke inode, dan tidak boleh ada proses yang menahan file dalam keadaan terbuka untuk penulisan saat verity diaktifkan. Setelah operasi berhasil, isi file menjadi read-only. Upaya membuka file untuk penulisan atau melakukan truncate gagal meskipun mode bit biasa sebenarnya mengizinkan operasi tersebut.
Immutability tersebut berlaku pada isi yang diukur, bukan pada setiap properti yang melekat pada inode. Metadata seperti ownership, mode bit, timestamp, dan extended attribute masih dapat berubah. File juga masih dapat di-rename, di-link, atau dihapus. Karena itu, desain otorisasi tidak dapat menyamakan “verity file” dengan pathname yang immutable, record metadata yang immutable, atau objek yang tidak dapat dihapus.
Merkle tree memindahkan verifikasi ke blok yang sedang dikonsumsi
Hash seluruh file secara konvensional memerlukan pembacaan file lengkap untuk menghitung ulang digest. fs-verity membagi isi file menjadi blok dan melakukan hashing ke dalam Merkle tree. Sebuah blok data terhubung melalui rangkaian hash block menuju root hash. Digest file fs-verity diturunkan dari descriptor yang memuat root tersebut beserta properti seperti ukuran file dan parameter hashing.
Ketika blok yang dilindungi masuk ke page cache, filesystem memverifikasi jalur Merkle yang relevan sebelum mengekspos data yang belum diverifikasi sebagai page berstatus up-to-date. Hash block yang telah diverifikasi sebelumnya dapat di-cache, sehingga verifikasi tidak perlu melakukan hashing ulang terhadap seluruh file pada setiap pembacaan.
Posisi verifikasi ini berlaku untuk memory mapping maupun pemanggilan read eksplisit. Verifikasi terintegrasi di bawah interface individual seperti read(), sehingga mmap() tidak dapat sekadar melewati pemeriksaan melalui jalur akses userspace yang berbeda. Filesystem yang didukung juga mencegah direct I/O melewati jalur verifikasi.
Jika data gagal diverifikasi, pembacaan biasa gagal dengan I/O error untuk data yang terdampak, sedangkan akses melalui memory mapping dapat menghasilkan SIGBUS. Mekanisme ini merupakan enforcement saat konsumsi data, bukan sekadar laporan integritas di background.
Tree yang terverifikasi tidak mengautentikasi root miliknya sendiri
Verifikasi Merkle menjawab apakah sebuah blok konsisten dengan root yang terkait dengan verity file. Mekanisme itu sendiri tidak menetapkan bahwa root tersebut mewakili publisher, package, release, atau deployment state yang telah disetujui.
Penyerang yang mampu mengganti file sekaligus metadata integritas yang tidak tepercaya dapat menyajikan objek lain yang tetap konsisten secara internal, kecuali ada komponen tepercaya yang mengautentikasi digest file yang diharapkan. Trust anchor karena itu harus berada di luar pasangan file dan tree yang tidak tepercaya.
FS_IOC_MEASURE_VERITY mengekspos digest yang sedang diberlakukan kernel untuk sebuah verity file. Userspace tepercaya dapat membandingkan digest itu dengan manifest yang telah diautentikasi atau memverifikasi digital signature atas digest tersebut. Linux juga dapat mengintegrasikan digest fs-verity dengan mekanisme kebijakan seperti IMA atau IPE. Built-in signature fs-verity merupakan opsi lain ketika kernel dan kebijakan deployment dikonfigurasi untuk model tersebut.
Batas keamanannya tegas: verifikasi Merkle melindungi konsistensi antara pembacaan dan digest yang diberlakukan; kebijakan autentikasi memberikan otoritas kepada digest tertentu.
Isi read-only lebih sempit daripada identitas objek
Digest mengidentifikasi isi file yang dilindungi dan parameter verity descriptor yang dipakai untuk menurunkannya. Digest tersebut bukan signature serbaguna atas seluruh metadata filesystem.
Perubahan owner, permission mode, timestamp, pathname, atau extended attribute yang tidak terkait tidak mengubah digest isi yang dilindungi. Sistem yang memberikan otoritas berdasarkan properti tersebut memerlukan pemeriksaan terpisah. Sebaliknya, deployment berbasis content address dapat memakai digest sebagai identitas isi yang stabil meskipun pathname berubah.
Perbedaan ini juga memengaruhi replacement attack. Directory entry yang sebelumnya merujuk ke verity file tepercaya dapat kemudian merujuk ke inode lain setelah penghapusan dan pembuatan ulang jika namespace di sekitarnya mengizinkan operasi tersebut. Kode yang mensyaratkan artifact tertentu harus mengautentikasi digest objek yang benar-benar dibukanya, bukan menganggap pathname yang dikenal akan selamanya mengidentifikasi inode yang telah disetujui.
fs-verity dengan demikian melengkapi otorisasi pathname dan permission directory; fitur ini tidak menggantikannya.
Enforcement signature merupakan lapisan kebijakan, bukan properti otomatis
Dukungan kernel dapat memverifikasi built-in PKCS#7 signature yang terkait dengan verity file ketika konfigurasi yang relevan diaktifkan dan certificate tepercaya tersedia pada keyring fs-verity. Sistem juga dapat mewajibkan signature untuk verity file melalui sysctl terkait.
Meskipun demikian, verifikasi signature tidak otomatis membentuk kebijakan lengkap yang menyatakan bahwa setiap executable atau setiap file dalam suatu directory wajib memakai fs-verity. File non-verity berada di luar properti tersebut kecuali komponen atau kebijakan tepercaya lain menolaknya.
Ini merupakan kesalahan batas yang umum pada desain integritas: sebuah mekanisme dapat memvalidasi objek secara kuat setelah objek berpartisipasi di dalam mekanisme, sementara pemilihan objek tetap menjadi tanggung jawab lapisan lain. IMA appraisal, kebijakan IPE, atau logika aplikasi tepercaya dapat menyediakan aturan pemilihan tersebut sesuai deployment.
Signature juga melakukan autentikasi berdasarkan key yang diterima kebijakan. Provisioning, rotasi, revocation key, dan keputusan tentang file mana yang wajib memiliki digest terautentikasi tetap menjadi persoalan keamanan operasional di luar verifikasi Merkle itu sendiri.
Dukungan filesystem menentukan kontrak storage dan akses
fs-verity merupakan support layer yang digunakan filesystem, bukan format yang otomatis diterapkan oleh setiap filesystem yang di-mount. Dokumentasi kernel saat ini mencatat dukungan pada ext4, f2fs, dan btrfs, dengan penyimpanan tree dan descriptor yang spesifik untuk masing-masing filesystem.
Filesystem dan kernel sama-sama harus mengekspos fitur tersebut. Aktivasi verity dapat gagal ketika dukungan kernel tidak tersedia, filesystem tidak mengimplementasikannya, atau feature state filesystem tidak mengizinkannya. Software yang bergantung pada properti ini harus memperlakukan keberhasilan aktivasi atau measurement sebagai bagian dari kontrak deployment, bukan menyimpulkan dukungan hanya dari versi kernel.
Menyalin verity file melalui operasi copy file biasa juga tidak berarti destination mempertahankan state verity. Byte hasil copy dapat identik sementara destination merupakan file writable biasa tanpa enforcement Merkle tree. Pipeline artifact yang mewajibkan fs-verity perlu menetapkan properti tersebut pada destination lalu mengautentikasi digest yang dihasilkan.
Kegagalan integritas mengubah failure mode aplikasi
Karena verifikasi berlangsung saat pembacaan, kerusakan storage atau tampering dapat muncul setelah file berhasil dibuka. Aplikasi tidak dapat menganggap keberhasilan open() menjamin setiap page berikutnya akan tetap dapat dibaca.
Pada buffered read, aplikasi dapat menerima I/O error ketika blok rusak dicapai. Pada akses memory-mapped, proses dapat menerima SIGBUS. Service berumur panjang yang melakukan mapping terhadap database, index, executable, atau payload package yang dilindungi memerlukan kebijakan kegagalan yang memperhitungkan integrity error pada saat akses.
Perilaku ini merupakan konsekuensi langsung verifikasi tingkat blok. File berukuran besar dapat dikonsumsi tanpa hashing setiap byte sebelum penggunaan pertama, tetapi kegagalan integritas ditempatkan pada jalur akses data.
Batas yang bertahan adalah digest, enforcement, dan pemilihan
fs-verity menyediakan relasi yang diberlakukan kernel antara isi file read-only dan digest berbasis Merkle tree. Relasi tersebut bernilai justru karena cakupannya lebih sempit daripada keputusan trust secara umum.
Deployment memperoleh properti authenticity yang lebih kuat hanya ketika tiga bagian bertemu: filesystem memberlakukan pembacaan terverifikasi, mekanisme tepercaya mengautentikasi digest yang diharapkan, dan kebijakan pemilihan objek menolak artifact yang tidak memenuhi persyaratan tersebut. Tanpa bagian kedua, sistem memiliki root yang terverifikasi tetapi belum diautentikasi. Tanpa bagian ketiga, objek pengganti yang tidak dilindungi dapat tetap berada di luar kebijakan verity.
Arsitektur yang dihasilkan memisahkan integritas storage dari otoritas publisher atau deployment. Pemisahan tersebut membuat trust boundary dapat diperiksa: kernel memverifikasi byte terhadap digest file, sedangkan kebijakan menentukan digest mana yang diizinkan membawa otoritas.