On Tue, 2019-03-05 at 10:39 -0800, Matthew Garrett wrote: > On Tue, Mar 5, 2019 at 5:19 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > On Mon, 2019-03-04 at 14:10 -0800, Matthew Garrett wrote: > > > I'm not clear on why requiring signed policies is helpful here. If you > > > allow FUSE mounts at all then you need to trust the FUSE filesystem to > > > return good results, in which case you can trust it to return valid > > > hashes. If you don't trust the FUSE filesystem then generating the > > > hash via read doesn't win you anything - the filesystem can return one > > > set of data on the initial IMA hashing, and then return a second set > > > later. Requiring signed policy doesn't change that. > > > > You're defining a new generic file ops "get_hash", but are using FUSE, > > a specific filesystem, as an example. Requiring the IMA policy to be > > signed when using "get_hash", is proof of the sysadmin's agreement to > > bypass actually reading and calculating the file hash. > > We can trust in-kernel filesystems to return reliable information. > Network filesystems have the same issue as FUSE - we're trusting that > the remote endpoint won't give us different information on successive > reads. What's the threat that's blocked by requiring signed policy > here? Today, IMA calculates the file hash by reading the file. If "get_hash" is a generic filesystem ops, then any filesystem could implement it, properly or not. sysadmins shouldn't have to review kernel code to understand the source of the file hash, but should be able to assume that unless they explicitly authorize "get_hash" usage, IMA reads the file and calculates the file hash. Mimi
