Re: [RFC][PATCH 2/3] SLIM

From: Stephen Smalley (sds@private)
Date: Thu Nov 17 2005 - 09:27:55 PST


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.

> 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
> 
> 	EVM uses LSM as it does now
> 	SLIM registers itself with EVM
> 		which events are of interest
> 		which data to send
> 	When EVM does bprm_check, for instance, it calls the
> 		appropriate SLIM function and sends it the
> 		already evaluated file and xattr properties
> 	SELinux registers itself with EVM
> 	When EVM does d_instantiate, it sends the selinux context
> 		integrity info to an selinux hook.
> 
> 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.

We then end up with only one new LSM here (SLIM) and two support
libraries.  At which point the only motivator for stacker is combining
SLIM and SELinux without directly coupling them.
  
-- 
Stephen Smalley
National Security Agency



This archive was generated by hypermail 2.1.3 : Thu Nov 17 2005 - 09:21:40 PST