On Tue, 2018-10-09 at 10:21 -0700, Matthew Garrett wrote: > On Mon, Oct 8, 2018 at 3:40 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > On Mon, 2018-10-08 at 13:19 -0700, Matthew Garrett wrote: > > > We trust that the filesystem will return us accurate binaries and > > > hashes, but we don't the binaries themselves may not be trustworthy - > > > we want the same level of audit trail associated with their execution > > > that we'd have for something run off local disk. We could certainly > > > rearchitect our filesystems to generate audit events themselves, but > > > we'd be duplicating functionality that already exists in the kernel. > > > > I'm really not comfortable with the FUSE filesystem calculating the > > file hash being used by IMA. Adding FUSE i_version support would have > > been better, instead of returning the actual file hash. Based on a > > mount option and the i_version, the kernel could then decide whether > > or not to limit re-calculating the file hash. > > Well, there's a performance benefit as well - reading 500MB > executables over the network is time consuming and otherwise mostly > unnecessary. Given two solutions that have the same properties in > terms of which components we need to trust, why not pick the one > that's faster? With the existing cover letter, the purpose of this patch set should be to address the performance of calculating the file hash on trusted local FUSE mounted filesystems, not remote filesystems or fs-verity filesystems. Mimi
