Given that LSM set out to satisfy the needs of a collection of other independent projects, it is understandable that the result produced some emergent properties.
Many security models require some way to associate security attributes to system objects. Thus LSM attaches security fields to many internal kernel objects so that modules may attach and later reference the security attributes associated with those objects.
It is also desirable to persistently bind security attributes to files. To do so seamlessly requires extended attribute file system support, which enables security attributes to be bound to files on disk. However, supporting extended attributes is a complex issue, requiring both support for extended attributes in the filesystem [22], and support for extended attributes in the Linux kernel's VFS layer. LSM mediates all VFS extended attribute functions, such as creating, listing and deleting extended attributes. However, extended attribute support is new to the Linux kernel and is not well-supported in all filesystems. Modules that need persistent extended attributes can resort to using meta-files [44,29] when extended attribute support is missing from the filesystem.
In attempting to provide a pluggable interface for security enhancements, it is tempting to consider completely modularizing all security policy decisions, i.e. move all kernel logic concerning access control out of the kernel and into a default module. This approach has significant benefits beyond simple modular consistency: in particular, it would make it much easier to provide authoritative hooks instead of restrictive hooks, which in turn would enable a broader variety of modules (see Section 3).
However, we chose not to modularize all security decisions, for pragmatic reasons. Current Linux access control decisions are not well isolated in the kernel; they are mingled with other error checking and transformation logic. Thus a patch to the Linux kernel to remove all access control logic would be highly invasive. Implementing such a change would almost certainly entail security bugs, which would not be an auspicious way to introduce LSM to the greater Linux community.
Therefore, we deferred the complete modularization of all access control logic. The current LSM implements much less invasive restrictive hooks, providing a minimally invasive patch for initial introduction into the Linux community. Once LSM is well established, we may revisit this decision, and propose a more radical modularization architecture.
Finally, in designing the LSM interface, we were distinctly aware that LSM constitutes an API, and thus must present a logically consistent view to the programmer. The LSM interface constitutes not only the set of hooks needed by the modules we intended to support, but also the logical extension of such hooks, such that the interface is regular. Where possible, special cases were generalized so that they were no longer special.