On Sun, Jan 28, 2018 at 04:49:25PM -0500, Theodore Ts'o wrote: > Speaking as a kernel developer, it makes a more sense to keep things > in the kernel, That should have read, "keep as little as possible in the kernel". Apologies for the bad proofreading. Ultimately, I think the issue is fundamentally philosophical. IMA was designed with a very strong point of view, and assumes that its requirements set was the only thing the that it needed to support. Worse, it seems designed to that you can't easily reporpose for it for different requirements; part of this is because a lot of the policy is in the kernel, opposed to be in userspace. I understand why that's tempting from as security perspective (even if it does make the attack surface much larger). The bottom line is that I don't think fs-verity should be stretched over the procrustrean bed of IMA. And I am *not* asking that IMA change; because of userspace backwards compatibility requirements, I recognize that *that* ship has already sailed. So ultimately, designing something new which is minimal, and which could be *used* by IMA, but which does not *require* IMA may be the best way to move forward from here. - Ted and do as much in userspace as possible --- and if that > means that the Docker client (or the package manager, etc.) needs a > minor change to call the userspace library, that's infinitely > preferable to keeping huge amounts of complexity in non-swappable > kernel memory --- which increases the attack surface of the kernel, > and so on. > > So in my opinion, clean design of the kernel trumps the requirement of > "not one change, not one jot, in the Docker client". > > It could be that the requiremnts of "keep the kernel changes simple" > and "no massive latency at file open time", means that requiremnt sets > of fs-verity and IMA are irreconcilable. Which is fine as far as I'm > concerned. Maybe IMA and fs-verity should be considered orthogonal > solutions. > > - Ted
