On Tue, 2019-03-05 at 12:27 -0800, Matthew Garrett wrote: > On Tue, Mar 5, 2019 at 11:51 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Tue, 2019-03-05 at 10:39 -0800, Matthew Garrett wrote: > > > 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. > > But what's the threat? If an attacker is in a position to inject > additional IMA policy then in general they're already in a position to > violate other security assumptions. Admins who have a threat model > that includes an attacker being able to do this are already requiring > signed policy. What's the threat that requiring signed policy for this > specific option mitigates? That might be true, but this "feature" isn't a minor change. It totally changes the IMA measurement list meaning, without any indication of the change in meaning. Mimi
