From: David Safford (safford@private)
Date: Thu Nov 17 2005 - 14:31:06 PST

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