On Wed, Jan 31, 2018 at 03:40:39PM -0500, Mimi Zohar wrote: > > I see. So anyone else adding security features is required to use the > LSM hooks, but your use case is different? (rhetorical statement) dm-verity does not use LSM. Signed kernel-modules does not use LSM. Ergo, it is not true all security features have to use the LSM hooks. It may be instructive to review why LSM exists[1][2][3][4]. [1] https://lkml.org/lkml/2007/10/1/110 [2] https://lkml.org/lkml/2007/10/1/192 [3] https://lkml.org/lkml/2007/10/1/217 [4] https://lkml.org/lkml/2007/10/2/315 I would presume the authors of dm-verity and signed kernel modules were able to convince Linus that their design was "sane", so he didn't insist they were put behind an LSM hook. I would expect that for fs-verity, a similar standard would apply in order for it to be accepted. > > If someone implements it, yes. If there is a business case where the > > benefits outweighs the costs, and the headcount can be funded, it > > would happen. However, having spent time trying to understand the > > IMA/EVM/LSM/SELinux architecture, I've spent enough time to decide > > it's not something I would do on my own time, for fun. :-) > > I understand you have lots of experience reading and understanding > kernel code, but understanding another subsystem, without ever having > been involved, no matter how well written that code is, takes time to > understand. There is some really well written code in the security > tree, especially considering the constraints put on it. Well, it would also help if the interfaces to those subsystems were accurately documented, and it was clear what documentation was accurate and what wasn't. Certainly documentation in the kernel tree would be helpful, and not just magic cookbook style, "this is how you use 'git commit' and 'git log'", but rather, "this is the low-level data storage model of git" and "this is how the low-level git commands can be used so that other programs can interface with git". To be fair, some of the complexity is caused by the large amounts of generality which was described by Stephen Smalley in [1] when he argued that maybe LSM should go away. But it's the lack of consensus about how to make the tradeoff between between complexity and the threat model should be, and just what the threat model should *be* which causes a dispersion of resources. (For example Fedora uses SELinux, but Debian has recently decided that since it is too hard to make SELinux be configured for desktops/laptops, they will be moving to support AppArmor as the default LSM in the next stable release.) So this is a much larger problem, and it's why I'm trying to avoid getting stuck in this tarbit by following the path trod by dm-verity and signed kernel modules. Cheers, - Ted
