* David Wheeler (dwheelerat_private) wrote: > > I definitely believe in warning/protecting admins from > accidentally making misconfigurations. But if an > administrator KNOWS that the given module can be stacked > underneath some other module, then let 'em. Just to be clear, the admin (other than loading the module) has no control (over the typical module) over how it's loaded -- primary or secondary. That's all handled by the module_init() code. Of course a module could support a parameter that allows it to chose how it regitsters, but this is not likely. > The problem that I see is that right now, what exactly > does a module writer call when they're inserted? > Do they call register_security(), or mod_reg_security()? yes ;-) The current way is simple. Call register_security(). If that fails you know there is a primary module loaded already. If you are ok with loading as a secondary, you can call mod_reg_security(). If that succeeds, you are a secondary module, otherwise, you would error out. > It seems better to say "always call register_security()". The early version of register_security() automagically did mod_reg_security() if the primary registration failed. We took this out to let the module author have full control over the registration. > If you think it's critical for a module to say > "I prefer not to be stacked", then I guess that could be > incorporated in the call (directly or indirectly via security_ops). This kind of information should not be in the security_ops. > That way, all modules are in theory stackable as long > as the higher-level stacking modules properly account for > their behavior. I understand your intention, but I'm still not convinced that we a) want to make it super simple to stack, and b) that we don't already have the pieces needed. > In short, is it the job of every LSM module to limit stacking by > the primary module, or is it the primary stacking module's job > to figure out what can be stacked and how? The primary module is in charge of deciding whether it will allow secondary modules to register with it (by the mod_register interface it exports). And it is up to the module to decide if it would like to try and stack with the primary module. IOW, the current interface allows a very simple wrapper that does if (can't register_security()) if (can't mod_reg_security()) bail; > I suggest that individual LSM modules shouldn't worry about > the stacking issue at all (where possible) if they aren't > the primary module. Said another way, LSM modules should leave the > entire stacking problem _completely_ in the hands of the > primary module if they aren't the primary module. I agree to an extent. I simply assert that there is some value is letting a module chose not to be register as a secondary. > After all, an author of a given LSM module can't anticipate > all possible stacking combinations - so let's not make modules > assume that all stackings are illegeal. Actually, this is the kind of assumption that I'd prefer. There is enough infrastructure to allow stacking fairly simply, but you need to think about it just enough that you should decide who you chose to stack with. > It's not clear to me that a multiplexor could really > "account for it properly", since it doesn't have the > information it needs to detect this problem. Actually, It's simple. Keep a stack of security ptrs. Swap out for the module specific ptr before you ask the module's opinion and iterate through the module stack. > I don't think a multiplexor by itself could really > "deal" with the problem; it's not going to swap data field > values around on every hook call! Instead, I view this > as a way to document usage and detect possible problems. OK, so the bitmask is a possible optimization for the case where the module doesn't use a field and you are trying to stack with an arbitrary module that you don't know much about. I guess this is still falling into the category where I'm not convinced of the need. What might be nice is an arbitrary multiplexor module ;-) </hint> > Out-of-date code > is always an issue, but I don't think it'd be a big deal > in this case, since I would expect that an LSM module > would only rarely start using new data fields it hadn't > used before once it's ready for prime time. I guess I'd buy that ;-) > I do agree that it adds some complexity, which may not > be worth it. I think this field is less important, and > could added later more easily than changing the > registration interface. Okay cool, so we agree we don't need this feature just yet ;-) thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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 : Thu Jul 18 2002 - 18:42:56 PDT