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 capget
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 capset
permission
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
hook.
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.
For operations 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.