On Thu, 2005-11-17 at 12:27 -0500, Stephen Smalley wrote: > On Thu, 2005-11-17 at 10:52 -0600, Serge E. Hallyn wrote: > > Quoting Stephen Smalley (sds@private): > > > c) the direct integration of SLIM and IMA in patches posted by David > > > yielded reduced complexity and overhead in IMA (per David's own > > > description of the IMA patch) than trying to keep IMA completely > > > separate and independent, and > > > > Oh, that's not what I'd gotten from his comments - I thought he meant > > the current approach resulted in reduced complexity versus ima being > > a separate architecture. > > Looking at the code, it looks like IMA has gone from an independent LSM > to being a support library. That makes sense, it is purely mechanism to > support other LSMs, and the policy for using it belongs in those LSMs, > not in IMA itself. This argument seems a bit circular. The efficiency comes from having IMA use existing measurements and labels. This could be done in either way: as loosely coupled stacked LSM, or as a tightly coupled library. IMA was told it was not allowed to be an LSM module, which forced it to be a library. The efficiency came from the sharing, not from the tight coupling as a library. > > > All stacker aims to do is appropriately call each LSM's defined security > > hooks, so that one LSM does not need to fully control the other LSMs. > > I think that part is still valuable. However, a separate integrity > > notifier api to be exported to evm could be interesting. So perhaps > > ... > > This would require a pretty standard, clean set for both the > > events and sets of data of interest... Does this seem feasible? > > No, this is backwards. EVM is mechanism for validation. LSMs may wish > to use it to validate their xattrs. So EVM should become a support > library, just like IMA, that exposes interfaces to allow LSMs to get > validated attributes as a single transaction (and on validation error, > the calling LSM then gets to decide how to handle the error), replacing > their current direct calls to ->getxattr. The calling LSM also has to > call EVM hooks at certain points for management of EVM state. Defining a standard interface for getting validated xattrs makes sense, as any access control module would know how to take advantage of the validation. Tightly coupling this as a library, rather than more loosely as a module, adds the complexity of each LSM having to call the EVM hooks, rather than letting EVM collect state directly through LSM. Wouldn't using EVM as a library also prevent stacking of multiple LSMs, as each would have their own copy of the library code, with resultant synchronization issues? Still I am happy that the discussion is on what is the best way to incorporate integrity validation and attestation, and not on whether or not it is a good idea in the first place :-) dave safford
This archive was generated by hypermail 2.1.3 : Thu Nov 17 2005 - 14:31:53 PST