On Mon, 2005-07-11 at 09:49 -0400, George Beshers wrote: > 1) Is stacker intended mostly for experimental systems or for > production systems also? I have the impression that there are > concerns in this area. I'd say that submission for inclusion in the mainline kernel implies intent (by the author of stacker) for production use. Whether or not stacking of LSMs is truly appropriate for production systems has been debated previously. > 2) Because Auditing is an integral part of my LSM it is important > that the methods be called even if another module is going to > deny permission --- this is not the semantics of > RETURN_ERROR_IF_ANY_ERROR. It appears that SELinux also > might have a similar concern. > > Come to think of it, an LSM might want to modify its data > structures also. I think stacker has been intentionally constrained in order to reduce concerns about generic stacking/composition. Note also that the issue you raise isn't truly new to stacker - LSM itself is constrained in this manner, as the LSM hooks are not even reached in most cases if there is a DAC denial (or other kinds of basic checking applied prior to the LSM hook call). SELinux only audits its own permission checks, and will generally be the first module (other than stacker, if using stacker) due to its requirement for early initialization. > 4) What are the circumstances where an LSM would need to > modify something other than its own data structures? > In other words, what is the argument for not insisting > that security methods are side-effect free except for there > own data structures? You'd at least need an exception for capability, unless you undertake the work to migrate the capability bitmaps into the security blobs (and decompose apply_creds cleanly in a safe manner). SELinux can also have side effects on data structures other than its own e.g. flushing/resetting various elements of process state upon a security context transition to prevent unauthorized leakage and to help protect the new security context from subversion by the caller. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Jul 11 2005 - 08:50:25 PDT