Documentation additions

ratliffat_private

Hi,

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've attached it below as
a patch onto lsm.tmpl, so that you can see the kinds of information that I
am talking about. I am open to changing it around into whatever format you
think is best. I tried to attach attribution to the people who asked and
answered and chimed in on the email threads where the info comes from. Let
me know if I missed anyone or if I missed the earlier threads where the
info presented the first time.

There needs to be a longer section about how to stack modules and the
pitfalls of doing so.

So, add this info to lsm.tmpl or create a new document?

Emily

-- 
Emily Ratliff
IBM Linux Technology Center, Security

--- Documentation-orig/DocBook/lsm.tmpl	Thu Oct 25 18:37:08 2001
+++ Documentation/DocBook/lsm.tmpl	Thu Oct 25 17:36:43 2001
@@ -268,4 +268,52 @@

 </sect1>

+
+<sect1 id="tips"><title>Tips and Tricks for Writing Modules</title>
+
+<para>
+There has been a volume of helpful information passing through the
+lsm mailing list that wasn't getting written down anywhere permanent.
+The goal of this section is to preserve some of that valuable information
+in a more accessible format and to provide some information about how to
+start to write a loadable security module.
+</para>
+
+<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>
+
+<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>
+
+<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>
+
+<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>
+
+<para>
+Module writers are encourage to use the convention that the magic number
+is the first 32 bits of the MD5 hash of the module name to minimize the
+frequency of magic number collisions. Source: David Wheeler
+</para>
+
+</sect1>
+
 </article>


_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
