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. > Using SLIM as an example, it appears that SELinux would have to make > direct calls to EVM regardless of whether or not we use stacker. Dave, I think I see how we would cause evm to check all security.selinux xattrs, but could you explain the simplest way that we could cause it to halt the system in the case of a violation? I guess ideally we would in fact have interaction, so that evm could mark any files with corrupt selinux xattrs as type integrity_violated_t or something. > This isn't an argument about the merits of stacker by itself; it is an Well, indirectly it is :-) > argument about whether EVM/SLIM/IMA are an effective motivating example > for stacker. As far as I can see, they are not. 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? -serge
This archive was generated by hypermail 2.1.3 : Thu Nov 17 2005 - 08:53:18 PST