Quoting Stephen Smalley (sds@private): > On Wed, 2005-06-15 at 15:49 -0500, serue@private wrote: > > A long, long time ago, Crispin defined LSM's purpose as: > > > > >> Main goal : we have to design a generic framework to be able to use > > >> better > > >> security policies than the current ones (DAC and capabilities). > > > > > >Sort of. We have to design a generic interface that exports enough > > >kernel > > >functionality to allow security developers to go off and create these > > >better > > >security policy modules. > > > > Since IMA provides support for a new type of security policy, > > specifically remote system integrity verification, I don't see > > where LSM shouldn't necessarily be used. > > IMA isn't an access control model. Also, LSM is overkill for its needs > in many ways (IMA only needs a few LSM hooks) I don't think only needing a few of the hooks should disqualify it - same is true of capability. On the other hand the fact that it always grants permission could be taken to imply LSM is overkill. It seems to come down to a question of aesthetics. > and is inadequate in other > ways (LSM lacks a hook needed by IMA for measuring modules, although one > might argue that there could be benefit in adding such a hook to LSM > itself for access control purposes). True. In fact, since those hooks were originally dropped because there wasn't a user for them, refusing a user because the hooks aren't there would be hillarious! > If you look at the inotify patch, I think that they've moved the dnotify > hooks into a more generic set of fsnotify hooks that are leveraged by > both dnotify and inotify to reduce duplication in the core kernel. The Oh, cool, I actually hadn't noticed that. (Last I checked inotify was in... november?) > same approach could be used for hooks that would be co-located by audit > and LSM or by integrity measurement and LSM. Of course, you don't want In that case it seems to further obfuscate the code, though. We then have a common update hook to just call integrity+LSM hooks, which then call into their own subsystems... Is there a distinct advantage to be gained by separating the two? > to blindly place the integrity measurement hooks at the same locations > if a different placement would be more optimal for your purposes, so > you'd want to give it some thought. That's true, of course. Reiner, would any of the integrity measurement hooks be moved to a better place than the current LSM hooks? Is there a preferred ordering - ie measurement should always happen before the LSM modules, or always after? Either of these would of course be clear reasons to separate IMA into its own subsystem. thanks, -serge
This archive was generated by hypermail 2.1.3 : Wed Jun 15 2005 - 14:46:54 PDT