The LSM interface is implemented as a structure of callback methods, security_ops. A security module is responsible for implementing the callbacks according to the security policy it is enforcing. At boot time the security_ops structure is initialized with default callbacks, which implement traditional superuser semantics.
The security module can be built as a dynamically loadable module or statically linked into the kernel. It is initialized either at module load time for dynamically loaded modules or during do_initcalls() for statically linked modules. During this initialization, the security module must register its callbacks with the LSM framework by calling register_security(). A module should call unregister_security() when it is unloaded to return the security_ops structure to its default superuser policy.
The LSM framework is aware of only one primary security policy at any time. Once a security policy is registered with the LSM framework, subsequent attempts to register new security policies will fail. In some cases it is appropriate to compose security policies, as noted in Section 2. LSM allows modules to stack with each other, however, the framework remains aware of only a single security_ops structure. In order to register additional security policies, the subsequent modules register with the primary module using mod_reg_security(). This allows the LSM framework to remain simple, pushing the policy which defines composition into the primary security module.