fs-verity Memverifikasi File Read-Only Saat Data Dibaca

Hash file biasa sering diperiksa sebelum sebuah file dipercaya. fs-verity pada Linux memindahkan sebagian pekerjaan integritas tersebut ke filesystem. Setelah verity diaktifkan pada regular file di filesystem yang mendukungnya, file menjadi read-only dan data diperiksa terhadap Merkle tree yang tersimpan ketika data dibaca.

Batas mekanisme ini sengaja dibuat sempit. fs-verity dapat mendeteksi data yang tidak lagi cocok dengan digest yang diterapkan pada verity file. Autentikasi digest terhadap identitas tepercaya atau kebijakan rilis merupakan keputusan terpisah. Pemisahan tersebut menjaga primitive integritas agar tidak dianggap sebagai kebijakan trust perangkat lunak yang lengkap.

Aktivasi verity mengikat file pada konten tetap

Userspace mengaktifkan fitur melalui FS_IOC_ENABLE_VERITY. Operasi ini membangun Merkle tree, menyimpan metadata verity pada lokasi yang ditentukan filesystem, lalu menandai file sebagai verity file. Ioctl memakai file descriptor read-only, sementara pemanggil harus memiliki akses tulis pada inode dan tidak boleh ada proses yang sedang membuka file untuk ditulis.

Setelah aktivasi berhasil, konten file tidak dapat ditulis atau di-truncate. Pembatasan tersebut tidak memberikan seluruh semantik immutable flag Linux pada inode. Metadata masih dapat berubah, dan file masih dapat di-rename, dibuat hard link, atau dihapus.

Batas ini relevan bagi sistem deployment. fs-verity melindungi konten yang direpresentasikan inode verity tertentu; mekanisme tersebut tidak menjamin sebuah pathname akan selamanya menunjuk ke inode itu. Consumer tepercaya yang memerlukan artefak terautentikasi juga harus menentukan cara memilih file dan menolak pengganti yang tidak terlindungi.

Digest mengikat lebih dari sekadar root hash

Data file dibagi menjadi blok lalu di-hash. Kumpulan hash ditempatkan ke dalam blok dan di-hash kembali sampai tersisa root Merkle tree. Struktur ini memungkinkan kernel memverifikasi blok data yang diminta melalui jalur dari blok tersebut menuju root tanpa menghitung hash seluruh file pada setiap akses.

Nilai yang diukur dari luar adalah fs-verity file digest, bukan raw Merkle root. Linux menghitung digest itu atas descriptor yang memuat field seperti ukuran file, algoritma hash, informasi ukuran blok, salt, dan root hash. Pengikatan parameter tersebut menghindari ambiguitas yang masih tersisa jika hanya root tree yang digunakan.

Userspace dapat mengambil digest yang sedang diterapkan melalui FS_IOC_MEASURE_VERITY. Operasi ini tidak perlu membaca ulang seluruh file, sehingga digest dapat dipakai sebagai identifier stabil untuk kebijakan, audit, atau verifikasi signature.

Verifikasi berada pada jalur pembacaan data

Pada filesystem berbasis page cache, fs-verity memverifikasi data sebelum folio terkait tersedia sebagai konten page cache yang valid. Penempatan ini mencakup pembacaan biasa serta akses melalui memory mapping, bukan hanya melindungi satu interface syscall.

Jika verifikasi data gagal, pembacaan normal pada region terkait gagal dengan EIO. Akses melalui memory mapping dapat menghasilkan SIGBUS. Data cache yang sudah diverifikasi tidak perlu mengulangi pekerjaan yang sama, dan blok Merkle tree yang telah diverifikasi juga dapat di-cache untuk mengurangi penelusuran tree berulang.

Direct I/O tidak diizinkan melewati jalur tersebut. Pada verity file, operasi itu jatuh kembali ke buffered I/O, sedangkan DAX tidak didukung karena pemetaan langsung persistent storage akan melewati model verifikasi.

Integritas saja tidak menetapkan provenance

Penyerang yang dapat mengganti file biasa sekaligus expected hash yang tidak terautentikasi dapat membuat kedua nilai tetap cocok. fs-verity tidak menghapus persoalan trust tersebut. Digest memerlukan sumber autentikasi ketika sasaran keamanan mencakup penggantian berbahaya, bukan hanya korupsi tidak disengaja.

Salah satu desain memakai userspace tepercaya yang mengambil fs-verity digest lalu memeriksanya terhadap metadata rilis bertanda tangan atau nilai terautentikasi lain. Framework integritas Linux juga dapat memakai properti fs-verity. IMA dapat memakai digest fs-verity untuk appraisal, sedangkan IPE dapat membuat keputusan kebijakan berdasarkan properti digest atau signature fs-verity.

Linux juga menyediakan dukungan signature bawaan opsional untuk fs-verity. Fasilitas tersebut memverifikasi signature yang terkait dengan file digest menggunakan key yang tersedia bagi kernel. Dokumentasi kernel menegaskan bahwa fitur ini sendiri bukan kebijakan autentikasi lengkap: sistem tetap memerlukan kebijakan yang mewajibkan file relevan dilindungi dan diautentikasi.

Pemisahan tersebut berguna. Verifikasi Merkle menjawab apakah byte yang dibaca masih cocok dengan komitmen file. Kebijakan autentikasi menentukan apakah file yang terikat pada komitmen itu memang layak dipercaya sistem.

Perlindungan konten tidak mencakup seluruh properti inode

fs-verity digest mengidentifikasi konten file dan parameter yang digunakan konstruksi verity. Digest tersebut secara umum tidak mengautentikasi metadata inode yang dapat berubah seperti owner, mode, timestamp, atau extended attribute arbitrer.

Desain keamanan yang bergantung pada properti tersebut memerlukan kontrol tersendiri. Sebagai contoh, verifikasi byte executable tidak membuktikan bahwa permission direktori, ownership, label, atau resolusi pathname di sekitarnya tetap berada pada keadaan yang dimaksud.

Cakupan yang sama menjelaskan perilaku copy. Merkle tree dipelihara sebagai metadata verity milik filesystem dan tidak diekspos sebagai konten file biasa. Menyalin verity file dengan semantik copy normal menghasilkan file baru dengan byte yang sama, tetapi tujuan tidak otomatis mewarisi status verity. Tooling deployment perlu mengaktifkan atau memulihkan perlindungan yang diperlukan pada tujuan secara eksplisit.

fs-verity dan dm-verity melindungi unit berbeda

Keduanya menggunakan verifikasi Merkle tree, tetapi objek yang dilindungi berbeda. dm-verity bekerja pada block device read-only dan sesuai untuk image filesystem immutable. fs-verity bekerja pada file individual yang dapat berada di filesystem read-write.

Perbedaan ini mendukung artefak yang diperbarui secara independen. Package manager atau application loader dapat mempertahankan filesystem writable sambil menempatkan executable, package, atau data file tertentu di bawah verifikasi per-file. Bagian filesystem lain tidak menjadi read-only hanya karena satu file memakai fs-verity.

Kedua mekanisme juga dapat hadir bersama dalam desain trust yang lebih luas. Image sistem read-only dapat memakai dm-verity, sedangkan konten yang dipasang secara independen pada storage writable memakai fs-verity beserta kebijakan autentikasi yang sesuai dengan konten tersebut.

Kapabilitas filesystem dan kernel tetap menjadi bagian kontrak

fs-verity merupakan support layer yang diintegrasikan filesystem, bukan properti yang otomatis tersedia pada setiap filesystem yang di-mount. Dokumentasi Linux saat ini mencantumkan ext4, f2fs, dan btrfs sebagai filesystem yang mendukungnya, dengan persyaratan dan format penyimpanan metadata verity yang spesifik untuk masing-masing filesystem.

Aplikasi yang bergantung pada mekanisme ini perlu memperlakukan keberhasilan aktivasi dan measurement sebagai state keamanan yang dapat diamati. File konfigurasi yang meminta fs-verity bukan bukti bahwa artefak tertentu sudah terlindungi. Error, filesystem yang tidak didukung, opsi yang tidak kompatibel, dan provisioning yang belum lengkap harus tetap terlihat bagi lapisan kebijakan.

Klaim fs-verity paling kuat ketika tetap presisi: file read-only yang terlindungi terikat pada digest yang diterapkan, lalu data file diperiksa terhadap komitmen tersebut saat memasuki penggunaan. Provenance, trust pathname, kebijakan metadata, trust key, dan otorisasi tetap menjadi bagian terpisah dari model keamanan sistem.