On Thu, 25 Oct 2001, Emily Ratliff wrote: > A bunch of info about writing modules has been posted to the mailing list > in the past month or so that I found quite valuable while looking at > creating a module. I've pulled some it together. I was considering > creating a new document since the goal sentence of lsm.tmpl doesn't > indicate that you plan to include module writing instructions, but there > isn't enough material to justify a new document. I don't see any reason to not add such information to lsm.tmpl. Just FYI, we are currently writing documentation for the SELinux security module, and it discusses how SELinux dealt with many of these issues, so it may be a helpful resource when it is ready for release. Some specific comments about the current content: > +<para> > +Be careful about raising semaphores in hook functions because some are > +called from interrupts. Check <function>in_interrupt()</function> prior to > +trying to take a semaphore and abort or take some other action if the > +function was called from an interrupt. Source: Greg K-H, Stephen Smalley > +</para> See the safe_down function defined and used by the SELinux security module for semaphores in code that can be called from interrupt context or process context. Also, on a similar note, see the SAFE_ALLOC flag used by the SELinux security module for kmalloc in code that can be called from either context. These were actually contributed by James Morris. > +<para> > +If your module is loadable at any arbitrary time, it must walk the process > +table to handle process that were created before the module was loaded if > +the module has an expectation that it is handling all processes. > +Source: Stephen Smalley > +</para> Actually, I don't think that this is the best approach. The SELinux security module uses precondition functions, as I've discussed on the list (and in our new documentation). Trying to traverse the entire system state and set the security fields for all pre-existing processes and objects is difficult at best (consider: an open file descriptor might be queued on a Unix domain socket awaiting receipt) and is likely to have races. > +<para> > +The restrictive hooks can be de facto made into authoritative hooks, if the > +call to capable returns success (0). The newly authoritative hooking function > +may need to calculate the value that capable would have calculated to determine > +the correct return value. Sources: Stephen Smalley, Chris Wright, Casey > +Schaufler, Richard Offer > +</para> Actually, after further discussion on the list, it was determined that this isn't true. Restrictive+capable is not as expressive as authoritative. Certain capabilities are used both to override DAC logic and as the only control for certain operations, so you can't just grant them unless we place a restrictive hook after every capable call. > +<para> > +Modules that anticipate stacking with other modules are recommended to > +utilize a magic number field as the first part of their security blob, so > +that the stacked hook functions can easily identify their respective blobs. > +Source: Stephen Smalley, Lachlan McIlroy, Greg K-H > +</para> If you merely want to stack with the dummy plug or the capabilities plug, you don't need to do this, since they don't use the security fields. The SELinux security module is set up to stack with either of these modules. For more general stacking, you really need a common security object header with a module id field and a list field so that you can chain objects and each module can find its appropriate object. We don't do that yet in SELinux. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 : Fri Oct 26 2001 - 05:35:40 PDT