David Wagner wrote: >Greg KH wrote: > > >>Then lets deal with that problem when those modules crawl out into the >>light. >> >> >Is it going to be any easier to change the interface later? >It seems like if we're going to change the interface, now is the time. >(Of course, it seems to be an open question whether there is any >need to change the interface.) > Exactly: if there is going to be a need to change the interface, and we know about it now, then changing it now instead of later saves a lot of effort and confusion. So lets discuss it on its merrits, instead of shoving it aside just 'cause the train hasn't hit us yet :) Greg makes an interesting point on performance. While I believe that most modules will be stacked with something like Capabilities and/or OWLSM, the likely case is going to be that only one of those modules (the big policy engine) is going to use sys_security(). Furthermore, the total number of modules stacked into a kernel is likely to also be small (single digit). The amount of time the Stacker module spends polling is going to be fairly small. On the other hand, it is this kind of thinking that gave the Linux kernel a scheduler that linearly scanned the process ready list, and had to be upgraded when Linux went into the big time. It is also this polling business that I am calling "ugly". IMHO, this kind of polling is only called for if the results of the poll are going to change between one scan and the next (e.g. polling the ready status of I/O hardware). Greg is correct that there is no code that uses this feature, but that's tautological: there is no such code because the feature doesn't exist. Imagining that scenario is not hard. Suppose that OWLSM grows more policies (I have a student considering adding the "no ptrace for root" policy to OWLSM). Suppose that the list of "cute" policies that OWLSM grows so large that people want the ability to turn some of them off. Now suppose that you want to do this at run-time, i.e. when running this application (e.g. Courier mail server) disable that policy (e.g. hard-link following). Now we have OWLSM wanting to use sys_security, and share it with the SELinux/LIDS/SubDomain big-ass policy engine. Now we have a situation where using the facility is not just plausible, but IMHO probable. I can see the advantages of this interface change pretty clearly. Talk to me about costs. Does it confound something in the kernel implementation? Does it cause some other interface weirdness (e.g. Stacker really *does* need to poll the modules dynamically)? Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 Aug 26 2002 - 09:43:38 PDT