STRUCTURE OBJECT
task_struct Task(Process)
linux_binprm Program
super_block File system
inode Pipe, File, or Socket
file Open File
sk_buff Network Buffer(Packet)
net_device Network Device
kern_ipc_perm Semaphore, Shared Memory
Segment, or Message Queue
msg_msg Individual Message
Table 5-5: Kernel data structures modified by the LSM kernel patch and the corresponding abstract objects
The security_operations structure is the main security structure that provides security hooks for
various operations such as program execution, file system, inode, file, task, netlink, UNIX domain
networking, socket, and System V IPC mechanisms.
Each LSM hook is a function pointer in a global table, security_ops. This table is a
security_operations structure defined in include/linux/security.h. The global
security_ops table is initialized to a set of hook functions provided by a dummy security module that
provides traditional super user logic. A register_security function (in security/security.c) is
provided to allow a security module to set security_ops to refer to its own hook functions, and an
unregister_security() function is provided to revert security_ops to the dummy module hooks.
This mechanism is used to set the primary security module, which is responsible for making the final decision
for each hook.
LSM also provides a simple mechanism for stacking additional security modules with the primary security
module. It defines register_security() and unregister_security() hooks in the
security_operations structure, and provides mod_reg_security() and
mod_unreg_security() functions that invoke these hooks after performing some sanity checking. A
security module can call these functions in order to stack with other modules.
LSM hooks fall into two major categories: hooks that are used to manage the security fields and hooks that
are used to perform access control. Examples of the first category of hooks include the
alloc_security() and free_security() hooks defined for each kernel data structure that has a
security field. These hooks are used to allocate and free security structures for kernel objects. The first
category of hooks also includes hooks that set information in the security field after allocation, such as the
post_lookup() hook in struct inode_security_ops. This hook is used to set security
information for inodes after successful lookup operations. An example of the second category of hooks is the
permission hook in struct inode_security_ops. This hook checks permission when accessing an
inode.
Figure 5-76 depicts the LSM hook architecture in which an LSM hook makes a call to a function that the
LSM module (xyz) must provide, just before the kernel would have accessed an internal object. The module
can either let the access occur, or deny access, forcing an error code return.
148