This section describes miscellaneous hook functions that do not fit into one of the prior sections.
This hook function is called by the kernel to determine whether a particular Linux capability is granted to a task. After calling the secondary security module to perform the ordinary Linux capability test or superuser test, this hook function calls the task_has_capability helper function to check the corresponding SELinux capability permission. Hence, the Linux capability must be granted by both the secondary security module and by SELinux.
This hook function is called by the kernel to get the capability sets
associated with a task. It first checks
permission between the current and target tasks. If this permission
is granted, it then calls the secondary security module to obtain the
capability sets, since SELinux does not maintain this information.
Note that the returned capability sets are not modified to remove
capabilities that would be denied by SELinux.
This hook function is called by the kernel to check permission before
setting the capability sets associated with a task. It calls the
secondary module to allow it to apply the normal Linux capability
checking logic, and then checks
between the current and target task. SELinux does not perform any
checks on the individual capabilities being set, since it revalidates
each capability on use in the selinux_capable
This hook function is called by the kernel to set the capability sets associated with a task. It simply calls the secondary module to set the capability sets, since SELinux does not maintain this information.
This hook function is called to perform permission checking and to set the effective capability set in the control buffer for a netlink message when the message is sent. The function first calls the secondary module to initialize the effective capability set based on the sending task. It then calls the AVC to compute the set of capabilities that would be allowed by SELinux and intersects this set with the effective capability set in the control buffer. Finally, if the policy supports the fine-grained netlink classes and permissions, this hook function calls selinux_nlmsg_perm to apply further permission checks based on a mapping of netlink message types to read and write information flows (i.e. observing information or modifying information).
This hook function is called to check permission when a netlink
message is received that requires privilege. It checks the effective
capability set associated with the netlink message to see if
CAP_NET_ADMIN is set.
This hook function is called to check permissions and perform accounting when allocating a mapping. It was initially made into a security hook to avoid generating spurious audit messages upon checking CAP_SYS_ADMIN to determine whether to reserve some memory. The hook function calls the secondary module's capable function to check whether the task has CAP_SYS_ADMIN, and if so, it calls the AVC to check whether SELinux would allow this capability as well, using an interface that avoid audit generation. The function then calls the kernel __vm_enough_memory function with a flag indicating whether the capability was granted.
The selinux_sysctl hook function checks
permission for the current task to access a sysctl entry. It calls
the selinux_proc_get_sid helper function to
obtain the SID associated with the sysctl entry based on the
proc_dir_entry tree. This is also used by
inode_doinit_with_dentry for other procfs inodes,
as discussed in the Section called inode_doinit, selinux_d_instantiate. If no match is found,
then the hook function defaults to the sysctl initial SID.
The hook function then performs a permission check based on the requested operation, treating the sysctl entry as a directory for search operations and as a file for read or write operations on a variable. Table 40 shows the permission checks associated with each requested operation.
The selinux_syslog hook function checks that the
current task has permission to perform a given system logging command.
3 (read last kernel messages) and
10 (return size of log buffer), the
syslog_read system permission is checked. For
operations that control logging to the console, the
syslog_console system permission is checked. All
other operations (including unknown ones) are checked with
syslog_mod system permission.