Chris, >* Serge E. Hallyn (hallyn@private) wrote: >> LSM hooks can also be used for performance measurements, to aid an audit >> subsystem, etc. And with LSM's like bsdjail and securelevel, stacking with >> SELinux is still useful even though all are purely security modules. >Only valid use is for access control (and I'll agree it can aid audit). Although we're using the LSM hooks for access control, we are also using them for other functions as well, such as attestation, as described in "Attestation-based Policy Enforcement for Remote Access" (ACM CCS, October 2004), and signed executables verification. With capabilities, you're now up to 4 different usages. >> > I don't think arbitary composition of security models is a service that >> > the Linux kernel should provide. >> >> Here we fundamentally disagree. Something which can be unsafe for some if >> improperly used, but useful for others, should not therefore be disabled. >Problem is showing it's useful enough to make a change. The biggest >issue I see is that the current scheme is tough to code for both ways. >The module has to make a choice how to code itself w.r.t. stacking and >accessing it's security labels. Correct me if I'm wrong, but the issue isn't the difference in coding the loading of the module itself, but in accessing the security data pointers. Personally, I think it is really important to be able to share the hooks and the associated security data pointers in a logical and coherent fashion. For this reason, it makes sense to have stacker be the hook owner and all LSM security modules writing to it. None of the LSM security modules, other than perhaps Stacker, should be builtin, but should be loaded in the initrd. Mimi Zohar
This archive was generated by hypermail 2.1.3 : Thu Oct 28 2004 - 13:32:55 PDT