Matt Block wrote: > For stacking modules, it seems that the multiplexor approach > is much cleaner and more powerful than a chaining approach. Regardless of which approach is chosen, the hard-core requirement is that security modules must be explicitly willing to cooperate with each other. There are many security papers that describe lots of pitfalls of attempting to combine security policies. It just doesn't work in general, so any multiple-module activity has to be coordinated some how. > It appears (from language like, "pass it down the chain") > that the original recommendation was for a sort of linked > list of modules- this, of course, will cause hell when the > admin decides to unload a module in the middle of the chain, > particularly if there is no way to pass the requirements > of that module around (so as to rip the appropriate stuff > out of the security blob). It also offers no clear way > to add a module once the chain has been established. Depending on the modules in question, those kinds of administrative changes may not even be supported. > My (probably naïve) question is, "why must the LSM be aware > of this at all?" Hopefully, the LSM interface, per se, will be aware of as little of it as possible. The modules must be aware of each other, and not step on each other's toes. > Not being a kernel hacker of any great > talent or experience, I've always sort of thought that a > module can do anything any other kernel code can do. That's not quite true. The module interface defines the symbols that get exported to the module: these are the data and functions the module can conveniently access. The module has R/W access to the entire kernel address space, but doesn't necessarily know the address of every kernel object it might want to access. This makes "all kernel space" a security vulnerability for hostile modules, but not a useful paradigm for safe programming. Exporting sufficient symbols is the goal of the LSM project. > It > may put a significant burden on the poor sod who writes the > multiplexor, but why would it be particularly difficult for > the multiplexor module to detect when another module attempts > to register(), add the appropriate cruft to the blob, and > get on with life? Would it require the multiplexor to unregister > and re-register? Would that be really really bad? It woudn't be bad. The discussion is about the particulars of the stacking mechanism, the contents of the blobs, etc. > Why is the sky blue? Because of the refractive index of oxygen and nitrogen ... that was a rhetorical question, wasn't it? :-) > I've also sort of always held the notion that the whole > point of a kernel module interface is to allow for simple > and quick runtime configuration of a kernel. That's one use of it. Another is to separate code maintenance, so that the people who maintain the core kernel don't have to (say) know much about USB devices, or (in our case) elaborate security models. There is utility in a kernel module that is intended to be compiled in or loaded at boot time, and has no capability at all to be dynamically unloaded. > That is, the > whole idea seems to be building small (kernel-space) tools > for small jobs, and combining them to suit a need. Yup. WireX has three or four modules we want to deploy. Composing tools is a powerful way to get complex stuff done. > Aside > from some small performance gain in not having to follow > hooks around, it's not clear to me what advantage a giant, > monolithic kernel module has over, say, a giant, monolithic > kernel. The main advantage is that Linus doesn't want to think about giant security modules, he wants it to be someone else's problem. > That LSM hooks should support as many modules as > require them without too much fuss _seems_ pretty central. > What am I missing? Uh, nothing with respect to the big picture. But the Devil is in the details. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org _______________________________________________ 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 : Wed May 23 2001 - 11:19:47 PDT