On Fri, 2018-10-05 at 12:25 -0700, Matthew Garrett wrote: > On Fri, Oct 5, 2018 at 11:18 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > Right, the correct behavior should be not to trust FUSE filesystems, > > but since we don't break userspace there is the > > "ima_policy=fail_securely" boot command line option. > > There seem to be two scenarios: > > 1) You trust FUSE mounts, perhaps because you have some other policy > in place to ensure that only trusted binaries can mount stuff. In this > scenario you already trust that the filesystem will give you > consistent results when you read data from it - In the trusted mount scenario, we trust the data should not change between calculating the file hash and reading the file data, making it similar to other local filesystems. Unlike other local filesystems, however, we can't detect when the file changes. For this reason we need to re-calculate the file hash to measure/appraise the file each time. > it seems reasonable to > also trust it to give you back an accurate hash if you ask for one. Going from trusting the filesystem to behave properly, to trusting the file hash that the filesystem provides is a major leap. We don't do this today for any local filesystem. > 2) You don't trust FUSE mounts, in which case you pass > ima_policy=fail_securely. This patch doesn't change that behaviour. > > I agree that using FUSE in general is incompatible with IMA's goals, > but it's possible to configure systems where you can ensure that only > trustworthy code is involved. In that scenario this patch improves > performance without compromising security. If you trust a FUSE filesystem to not only behave properly, but also to return file hashes, what is the value of measuring/appraising the files? Define a custom policy that doesn't measure/appraise files on FUSE filesystems. Mimi
