The SELinux security module provides a set of helper functions that are used extensively by the SELinux hook implementations. This section provides an overview of these helper functions. More detailed descriptions of individual helper functions are provided in the appropriate hooks section.
For most SELinux security data structures defined in include/objsec.h, the SELinux module provides a primitive alloc_security and free_security helper function, e.g. task_alloc_security and task_free_security. These helper functions are used by the alloc_security and free_security hook functions, which may contain additional processing beyond the basic initialization performed by these helpers.
Each primitive alloc_security helper function allocates a security structure of the appropriate type, sets a back pointer to the kernel data structure, initializes the security information, and sets the object security field to refer to this new security structure. Each primitive free_security helper function clears the security field and frees the security structure.
The SELinux security module defines initialization helper functions for certain security structures (e.g. inode_doinit, superblock_doinit, etc). These initialization helper functions are called by certain SELinux hook functions, and are discussed further in later sections.
A set of helper functions on kernel objects and permissions are provided that dereference the security fields, set up auxiliary audit data, and then invoke the access vector cache (AVC) to perform the permission check with the right set of parameters. These helper functions simplify the code for many of the hook functions that perform permission checks. A few examples of these functions include task_has_perm, inode_has_perm, and may_create.
Although these helper functions can be convenient, hook functions are free to directly call the AVC to perform permission checks. This is done in a couple of cases. First, some permission checks involve a security identifier (SID) that is not associated with a kernel object, e.g. a SID specified by an application using the SELinux API calls or a SID obtained from the security server for an object that is about to be created. Second, some operations require multiple permission checks to be performed that are based on some of the same SIDs. In the latter case, using the helper functions would cause redundant processing in order to extract the same SIDs multiple times.