Calls to Security Hook Functions

**Figure:** The `vfs_mkdir` kernel function with one security hook call to mediate access and one security hook call to manage the security field. The security hooks are marked by`<->`.
$\begin{figure}\begin{center} \begin{footnotesize} \begin{verbatim}int vfs_mkdi... ...de); } return error; }\end{verbatim}\end{footnotesize}\end{center}\end{figure}$

As discussed in the previous subsection, LSM provides a set of calls to security hooks to manage the security fields of kernel objects. It also provides a set of calls to security hooks to mediate access to these objects. Both sets of hook functions are called via function pointers in a global security_ops table. This structure consists of a collection of substructures that group related hooks based on kernel object or subsystem, as well as some top-level hooks for system operations. Each hook is defined in terms of kernel objects and parameters, and care has been taken to avoid userspace pointers.

Figure 3 shows the vfs_mkdir kernel function after the LSM kernel patch has been applied. This kernel function is used to create new directories. Two calls to security hook functions have been inserted into this function. The first hook call, security_ops->inode_ops->mkdir, can be used to control the ability to create new directories. If the hook returns an error status, then the new directory will not be created and the error status will be propagated to the caller. The second hook call, security_ops->inode_ops->post_mkdir, can be used to set the security field for the new directory's inode structure. This hook can only update the security module's state; it cannot affect the return status.

Although LSM also inserts a hook call into the Linux kernel permission function, the permission hook is insufficient to control file creation operations because it lacks potentially important information, such as the type of operation and the name and mode for the new file. Similarly, inserting a hook call into the Linux kernel may_create function would be insufficient since it would still lack precise information about the type of operation and the mode. Hence, a hook was inserted with the same interface as the corresponding inode operation.

An alternative to inserting these two hooks into vfs_mkdir would be to interpose on the dir->i_op->mkdir call. Interposing on internal kernel interfaces would provide equivalent functionality for some of the LSM hooks. However, such interposition would also permit much more general functionality to be implemented via kernel modules. Since kernel modules have historically been allowed to use licenses other than the GPL, an approach based on interposition would likely create political challenges to the acceptance of LSM by the Linux kernel developers.