* Mimi Zohar (zohar@private) wrote: > 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. OK, I was really intending to object to performance measurement comment. The framework is really designed to support access control, but the other examples you cite are at least in the security arena. > >> > 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. Yes, it's not the loading that I mean. Coding a single module to cope with being stacked or not stacked (if it uses the security data pointers) is exactly the part that's tough. > 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. This makes sense iff you intend to use more than one module. For the cases where you don't, it's pure overhead. See the problem? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Thu Oct 28 2004 - 12:57:56 PDT