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