David S. Miller wrote: >2) The facilities added to support feature X also helps make > things like Y and Z possible. > A year ago in this forum, there were horrible flame-wars about just how *awful* it was that some evil-doer might do something non-security with LSM. In light of that, we specifically set out to make the LSM interface as small as possible. We specifically excluded features that might have made it more general, but that we could not justify on the basis of "need that to do effective access control." If you don't mind LSM being a *lot* more invasive (touching many more lines of code) then sure, it can be made much more general. D'oh! But then there won't be modules that use it, becuase it will have been just made up out of thin air :) As we wrote in the USENIX Security paper this summer, LSM was a tough design because it had to live in an over-constrained design space: be general enough to support a broad & effective set of security modules, and yet small enough to minimally impact the Linux kernel. That's what we tried to do. But it is a lot tougher (perhaps impossible) to simultaneously meet additional design constraints that the features must be generally useful, that all features must have current users, and that the features must *not* be generally useful. >Things like #2 are the things Al Viro is talking about. > >So instead of "security_ops()->this, security_ops()->that" being >sprinkled merrily all over the VFS, we have something useful to things >outside of LSM such as full file */fd attributes. > We went for "low impact" and "good enough for access control, and no more." Really, we did. It's possible to make LSM a lot cleaner if it is a lot more invasive but we thought that would be unwelcome. Are you really saying we should go make the patch a lot bigger so we can make the hooks prettier? Crispin
This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 01:25:19 PDT