On Thu, 2005-11-17 at 17:31 -0500, David Safford wrote: > 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. The sharing makes it tightly coupled, whether as a separate LSM or a library. That's the point - if it is tightly coupled anyway, then it might as well not use stacker. Further, making it tightly coupled improves not only efficiency but also simplicity and ease of analysis, because the interactions are now completely explicit and not hidden by the stacker. > 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. It isn't complex to have the LSM call EVM explicitly; in fact, it is then simpler to analyze the interactions and verify that they are what one desires. The only real "cost" is ensuring that any changes in EVM that affect its interface are tracked in the LSM, but that is not a problem for upstream modules - it is already done for many other kernel interface changes. > 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? I'm using the term "library" loosely here, as we are just talking about a set of kernel functions that can be called by multiple LSMs. Those functions would necessarily have to be built-in to the kernel in order to be useable by SELinux, so they would already be part of the base kernel and accessible to any module (this btw is one of your challenges - getting EVM to work built-in). No duplication. And regardless of whether there is one LSM using these functions or twelve LSMs, they have to deal with 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 :-) In order for this to be deployed, you need to make sure that a single kernel image can be used for: - systems that have supported TPMs where the user wants to employ validation, - systems that do not have supported TPMs or TPMs at all, and - systems that have supported TPMs but the user chooses not to employ validation. Vendors don't want to have to build (and support) multiple kernel images for such variations, just as they didn't want to do so for various modes of operation for SELinux. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Fri Nov 18 2005 - 05:10:14 PST