On Thu, 2005-11-17 at 08:46 -0600, Serge E. Hallyn wrote: > Quoting Stephen Smalley (sds@private): > > Another obvious question: since slim directly makes calls to evm and > > look at its data structures, and is placed under evm in the tree, what > > does any of this have to do with the stacker? You could just as easily > > have the slim hooks call evm in all cases where needed, > > My impression in the past was that SLIM is just an example module, > and they expect others to be written on top of EVM. However it does > look like SLIM requires evm always be loaded. Still I think the reason > to stack is so that you can load multiple modules on top of EVM. >From looking at the code, what I see is that: a) EVM and IMA are acting as support modules to SLIM, and in neither case is the composition presently transparent despite the stacker, and b) if I wanted to use EVM to support any other module (like SELinux), I'd need to likewise provide partial direct coupling in the same manner as SLIM, and 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 d) direct integration of SLIM and EVM would likewise yield reduced complexity and overhead (e.g. avoiding redundant getxattr calls, reducing potential inconsistencies, simplifying locking). > > and likewise > > couple other LSMs with evm as desired through direct calls rather than > > using the stacker. The composition isn't truly transparent in any > > event. > > Here I disagree - evm independantly verifies the integrity of files and > xattrs. Seems useful when stacked with several modules. For digsig, it > can ensure that the kernel, modules, and digsig keys are ok. For > selinux, it can verify the types. There seems to be absolutely no > reason to require selinux to directly control evm. 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. Further, it appears that even tighter integration with EVM is needed in order to avoid the redundant processing and potential inconsistencies created by the current weaker coupling. EVM can certainly serve as a support module to a variety of other modules (SLIM, SELinux, ...) while still being directly called by those modules - those modules are consumers of the services provided by EVM. Using stacker for part of the composition while using direct calls elsewhere only seems to confuse the interaction. I also find it a bit troubling that neither EVM nor SLIM seem to use the stacker correctly, leaving them open to race conditions on task and inode security setup. This isn't an argument about the merits of stacker by itself; it is an argument about whether EVM/SLIM/IMA are an effective motivating example for stacker. As far as I can see, they are not. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Thu Nov 17 2005 - 07:30:31 PST