On Mon, 8 Oct 2001, Chris Wright wrote: > * jmjonesat_private (jmjonesat_private) wrote: > > > > I still don't think it's necessary to be able to extricate LSM *if* it is > > part of the actual kernel tree. The cost for the dummy calls is just not > > that high (a sign, IMHO, that the "minimal impact" objective has been well > > addressed.) They also are located in many interesting spots, and may have > > uses other than the claimed purpose. > > you can be sure some people will complain about any negative impact. we may > be sold that lsm overhead is not unreasonable, but if the overhead > becomes an issue for acceptance we will have to address it. > I agree, except that I see the impact in the case of no-module as being trivial. There *IS* an impact, but the value to the entire Linux community of having LSM there seems to more-than-balance the cost. I am not sure that I can't be argued away from that belief, but I also think that, if I can, then it might be that LSM is too expensive. Quite honestly, I think LSM is just sucking up a trivial amount of the CPU advancement additional speed for a valid purpose. Admittedly, without LSM the total "speed" of the kernel would be higher, but I'm not AT ALL convinced it's not worth the cost. There are valid arguments for a "no-security" kernel, and I'd hoped that LSM would consider THIS as being a valid concern, but, as is, LSM doesn't suck enough "power" to make the cost "significant" in my view. > > On a more hopefully helpful note, would it be acceptable to build a > > conditional that converts the hooks containing logic in the dummy/capable > > module to direct calls to the relocated code in one swoop DIRECTLY, > > without the indirection of the security_ops structure, or is it > > necessary to put that logic BACK on the "flip of a switch."? > > > > #ifndef LSM_OUT > > #then > > hook(...) > > #else > > cap_hook(...) > > #endif > > this is what i was talking about. this is less trivial than lsm on/off > because it has dependencies on the capabilities module code. it isn't > the end of the world, it's just more difficult to get right, that's all. > ;-) I think it's no more difficult to get "right" than "base" LSM. If an LSM enabled kernel is operating, it should be *exactly* the same, security-wise, as the kernel that's being patched. The "assumption" has been that the kernel with null-plugs is the same as the kernel without LSM altogether. If it is not, then there's a failure in the design methodology. I haven't looked at the most recent patches, but I'd hope that there is some guarentee that these "defaults" persist. If LSM can show that the kernel with these direct (or booted indirect) calls is functionally the same as a kernel without them, the cost of these calls is offset by the value of having a call there, and I don't see it as being a counter-sale problem... I can even argue, trivially, that the placement of the "not-different" hooks is advantageous. This technique seems most reasonable to me, at this point, unless somebody can envision an argument against it from the "kernel community" that changes my mind. > -chris > J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Oct 08 2001 - 14:40:45 PDT