Package manager dapat menempatkan executable pada filesystem yang writable, menutupnya, lalu mengharapkan setiap byte yang dibaca kemudian tetap sama dengan objek yang sebelumnya disetujui. Permission biasa dapat menghentikan penulis yang tunduk pada kebijakan, tetapi tidak mengubah isi file menjadi objek dengan identitas kriptografis. Linux fs-verity menyediakan properti yang lebih sempit untuk file individual: setelah verity diaktifkan, data file menjadi read-only dan pembacaan diperiksa terhadap Merkle tree yang berakar pada digest file yang stabil.
Batas ini adalah verifikasi integritas, bukan kepercayaan otomatis. Merkle tree dapat mendeteksi data yang tidak lagi cocok dengan root-nya, tetapi verifier tetap memerlukan ekspektasi terautentikasi atas digest fs-verity yang dihasilkan. Menyatukan dua peran tersebut dapat mengubah mekanisme integritas yang kuat menjadi kebijakan autentisitas yang tidak lengkap.
Aktivasi verity membekukan bidang data
Userspace mengaktifkan fitur melalui FS_IOC_ENABLE_VERITY pada regular file di filesystem yang mengimplementasikan fs-verity. Caller memasok parameter yang mencakup hash algorithm, block size, dan salt opsional. Filesystem membangun serta menyimpan Merkle tree dan verity descriptor, lalu menandai file sebagai verity file.
Transisi ini memiliki syarat ketat pada sisi penulisan. Ioctl dijalankan pada descriptor O_RDONLY, caller tetap memerlukan write access ke inode, dan tidak boleh ada proses yang membuka file untuk penulisan. Writable memory mapping juga mencegah transisi. Syarat ini menjaga file tetap stabil ketika tree dibangun dan mencegah writable descriptor bertahan setelah aktivasi.
Setelah aktivasi berhasil, file tidak dapat dibuka untuk penulisan atau di-truncate. Operasi tersebut sengaja bersifat satu arah untuk inode itu. Penggantian content memerlukan pembuatan file lain dan aktivasi verity pada objek baru, bukan mutasi pada verity file yang sudah ada.
Immutability tersebut berlaku pada data file, bukan seluruh properti inode. Ownership, mode bits, timestamp, dan extended attribute masih dapat berubah. File juga masih dapat di-rename, dibuat hard link, atau dihapus. Desain keamanan yang mengikat authorization pada pathname atau metadata mutable karena itu memerlukan kontrol di luar verity digest.
Digest mengikat lebih dari sekadar root hash
Data file dibagi menjadi block berukuran tetap. Setiap data block di-hash, hash dikemas ke dalam block lalu di-hash kembali, dan proses berlanjut sampai tersisa satu root. Saat pembacaan, kernel dapat memverifikasi data block melalui jalurnya di tree tanpa melakukan hash terhadap seluruh file pada setiap akses.
Identitas yang dapat diukur dari luar bukan sekadar Merkle root tersebut. fs-verity melakukan hash atas descriptor yang mencakup root hash bersama parameter seperti ukuran file, hash algorithm, block size, dan salt. FS_IOC_MEASURE_VERITY mengembalikan fs-verity file digest dalam waktu konstan terhadap ukuran file.
Pengikatan descriptor menutup ambiguitas struktural yang dapat tersisa jika hanya root tree yang dipakai. Katalog tepercaya dengan demikian dapat mengikat artifact yang diharapkan pada digest dari konstruksi fs-verity yang sama, bukan pada kombinasi informal antara ukuran dan tree root yang dikelola terpisah.
Hash algorithm tetap menjadi bagian identitas. Nilai digest tanpa identifier algorithm bukan identitas fs-verity yang lengkap, dan format signature yang dipakai bersama fasilitas ini menyertakan algorithm serta ukuran digest.
Verifikasi berada pada jalur pembacaan
Untuk filesystem berbasis page cache, data diverifikasi sebelum folio terkait tersedia sebagai data yang berstatus up-to-date. Penempatan ini penting karena content file dapat mencapai proses melalui interface selain read(), termasuk memory mapping.
Ketika verifikasi data file gagal, pembacaan biasa dapat gagal dengan EIO; akses melalui mapping mmap() dapat memicu SIGBUS. Mekanisme ini karena itu mengubah perilaku kegagalan runtime. Aplikasi yang memakai verity file memerlukan model error yang memperlakukan kerusakan storage atau kegagalan verifikasi sebagai kemungkinan kegagalan pembacaan, bukan mengasumsikan file immutable yang berhasil dibuka akan selalu dapat dibaca.
Merkle block yang telah diverifikasi dapat di-cache, sehingga kernel tidak perlu menelusuri setiap level dari storage untuk setiap data block yang berdekatan. Optimasi tersebut tidak mengubah trust root: cached hash block hanya berguna setelah diverifikasi melalui jalur yang berakar pada file digest.
Direct I/O tidak dipakai untuk pembacaan verity file karena jalur tanpa verifikasi yang melewati machinery page-cache akan merusak properti tersebut. DAX juga tidak kompatibel dengan verity file. Klaim enforcement bergantung pada seluruh jalur pembacaan data yang didukung melewati verifikasi.
Integritas tidak mengautentikasi digest yang diharapkan
Jika penyerang dapat mengganti data file sekaligus expected digest yang tidak terautentikasi, verifikasi Merkle yang berhasil hanya menyatakan bahwa data baru konsisten secara internal dengan digest baru. Autentisitas memerlukan keputusan kepercayaan terpisah.
Salah satu model menyimpan digest fs-verity yang disetujui dalam metadata userspace tepercaya. Kode tepercaya mengukur file dengan FS_IOC_MEASURE_VERITY, membandingkan hasilnya dengan digest yang disetujui, lalu memperlakukan objek sebagai terautentikasi hanya jika cocok. Batas keamanan mencakup perlindungan katalog tersebut dan kode yang melakukan perbandingan.
Model lain memakai signature atas fs-verity digest. Linux secara opsional dapat menyimpan dan memverifikasi built-in PKCS#7 signature menggunakan certificate pada keyring .fs-verity ketika dukungan kernel terkait aktif. IMA appraisal juga dapat memakai fs-verity digest, sedangkan IPE dapat membuat keputusan kebijakan memakai properti fs-verity.
Mekanisme tersebut bukan pernyataan kebijakan yang dapat dipertukarkan begitu saja. Built-in signature verification membuktikan bahwa key tepercaya yang dikonfigurasi menandatangani sebuah digest, tetapi mekanisme itu sendiri tidak mewajibkan file arbitrer di sistem memakai verity. Deployment tetap memerlukan kebijakan yang menentukan operasi mana yang mensyaratkan verity file terautentikasi.
Penggantian path tetap berada di luar file digest
Verity inode immutable pada datanya, tetapi directory entry bukan pengikatan nama permanen. Aktor dengan privilege atau authorization yang sesuai dapat melakukan unlink lalu menempatkan file lain pada pathname yang sama. Pengganti dapat berupa verity file berbeda atau, tanpa aturan enforcement terpisah, file non-verity.
Hal ini memisahkan identitas content dari identitas pathname. Consumer yang mengautentikasi file berdasarkan digest sebaiknya melakukan pemeriksaan pada objek terbuka yang sama dengan objek yang akan dipakai, atau mengandalkan kebijakan kernel yang menegakkan properti tersebut saat akses. Mengukur satu pathname lalu membuka ulang pathname itu menciptakan kembali race resolusi nama yang tidak diselesaikan fs-verity.
Hard link memperlihatkan perbedaan yang sama dari arah lain. Beberapa nama dapat merujuk pada satu verity inode dan dengan demikian pada data terproteksi yang sama. Digest mengidentifikasi content dalam konstruksi fs-verity; digest tidak mengodekan lokasi directory kanonis.
Penyalinan tidak otomatis mempertahankan state verity
Merkle tree dan descriptor merupakan metadata yang dikelola filesystem dan terkait dengan verity inode. Penyalinan file biasa membaca byte yang telah diverifikasi lalu membuat file biasa baru; operasi itu tidak otomatis membuat verity inode lain dengan metadata setara.
Sistem backup, image building, dan distribusi karena itu memerlukan model provisioning eksplisit. Sistem dapat menyalin byte, mengaktifkan verity pada tujuan, lalu membandingkan digest yang dihasilkan, atau memakai tooling khusus yang mampu memindahkan metadata verity kompatibel dalam kondisi terkontrol.
Batas operasional ini mencegah asumsi yang tampak masuk akal tetapi keliru: payload byte identik tidak berarti state enforcement identik. Filesystem tujuan harus mendukung fs-verity, fitur harus aktif di sana sesuai kebutuhan filesystem tersebut, dan inode tujuan harus masuk ke state verity.
Dukungan filesystem menentukan batas deployment
fs-verity adalah support layer kernel bersama dengan integrasi spesifik filesystem. ext4, f2fs, dan btrfs mendukungnya, tetapi penyimpanan metadata verity pada disk berbeda. Konfigurasi kernel dan feature state filesystem juga menentukan ketersediaan.
Pembagian tersebut relevan terhadap keamanan karena guarantee tidak muncul hanya dari nama ioctl. Aktivasi yang berhasil berarti implementasi filesystem aktif menerima state verity dan mengarahkan pembacaan yang didukung melalui verifikasi. Aplikasi yang mensyaratkan properti ini perlu memperlakukan ENOTTY, EOPNOTSUPP, dan kegagalan aktivasi lain sebagai kegagalan membentuk batas, bukan sebagai kegagalan optimasi opsional.
fs-verity paling tepat ketika klaimnya tetap sempit: data file immutable, verifikasi per-block yang berakar pada digest terukur, dan komposisi eksplisit dengan kebijakan autentisitas tepercaya. Mekanisme ini tidak membekukan metadata inode, tidak mengikat pathname secara permanen, tidak mempertahankan dirinya melalui penyalinan biasa, dan tidak menentukan signer mana yang harus dipercaya. Keputusan di sekeliling mekanisme tersebut menentukan apakah byte terverifikasi juga merupakan artifact yang memang dimaksudkan sistem untuk dieksekusi atau dikonsumsi.