The LSM framework is initialized during the kernel's boot sequence with a set of dummy hook functions that enforce traditional UNIX superuser semantics. When a security module is loaded, it must register itself with the LSM framework by calling the register_security function. This function sets the global security_ops table to refer to the module's hook function pointers, causing the kernel to call into the security module for access control decisions. The register_security function will not overwrite a previously loaded module. Once a security module is loaded, it becomes a policy decision whether it will allow itself to be unloaded.
If a security module is unloaded, it must unregister with the framework using unregister_security. This simply replaces the hook functions with the defaults so the system will still have some basic means for security. The default hook functions do not use the opaque security fields, so the system's security should not be compromised if the module does a poor job of resetting the opaque fields.
As mentioned in Section 3, general composition of policies is intractable. While arbitrary policy composition gives undefined results, it is possible to develop security modules such that they can compose with defined results. To keep the framework simple, it is aware of only one module, either the default or the registered module - the primary module. A security module may register itself directly with the primary module using the mod_reg_security interface. This registration is controlled by the primary module, so it is a policy decision whether to allow module stacking. With this simple interface, basic module stacking can be supported with no complexity in the framework.