Implementing SELinux as a Linux Security Module | ||
---|---|---|
<<< Previous | Next >>> |
The SELinux System V Inter-Process Communication (IPC) hook functions manage the security fields and perform access control for System V semaphores, shared memory segments, and message queues. This section describes these hooks and their helper functions.
The ipc_security_struct
structure contains
security information for IPC objects. This structure is defined as follows:
struct ipc_security_struct { struct kern_ipc_perm *ipc_perm; security_class_t sclass; u32 sid; }; |
Table 26. ipc_security_struct
Field | Description |
---|---|
ipc_perm | Back pointer to the associated kern_ipc_perm .
|
sclass | Security class for the IPC object (see the Section called ipc_alloc_security and ipc_free_security). |
sid | SID for the IPC object. |
Likewise, the msg_security_struct
structure
contains security information for IPC message objects. This structure
is defined as follows:
struct msg_security_struct { struct msg_msg *msg; u32 sid; }; |
The ipc_alloc_security and
ipc_free_security helper functions are the
primitive allocation functions for the security structures for
semaphores, shared memory segments, and message queues. The kernel
data structures for these objects share a common substructure,
kern_ipc_perm
, and the security field is
located in this shared substructure; a single set of helper functions
can be used for all three object types. A new IPC object inherits its
SID from the creating task. The security class for the IPC object is
passed by the caller; it will be one of
SECCLASS_MSGQ
, SECCLASS_SEM
,
or SECCLASS_SHM
.
The ipc_alloc_security helper function is called by the following allocation hook functions:
selinux_sem_alloc_security
selinux_shm_alloc_security
selinux_msg_queue_alloc_security
create
permission between the current task and
the IPC object. Hence, these hook functions have the unusual property
of being used both for allocation and a permission check. Using two
separate hooks for this purpose would be cleaner but inefficient,
since they would both be called at the same point.The ipc_free_security function is called upon a permission denial by the allocation hook functions as well as by the following deallocation hook functions:
selinux_sem_free_security
selinux_shm_free_security
selinux_msg_queue_free_security
The msg_msg_alloc_security and msg_msg_free_security helper functions are the primitive allocation functions for the security structures for individual messages on a message queue. These helper functions provide all of the processing for the selinux_msg_msg_alloc_security and selinux_msg_msg_free_security hook functions. These helper functions simply provide the standard processing for primitive allocation functions, and initialize the message SID to the unlabeled SID.
This section describes the helper and hook functions for controlling
general IPC operations. Although the allocation functions do perform a
create
permission check, they are not listed
here since they were discussed in the previous section.
This helper function sets up the auxiliary audit data information and calls the AVC to check whether the current task has a particular permission to an IPC object. The explicit passing of the security class of the IPC object is a legacy of the earlier handling for pre-existing objects prior to SELinux initialization via precondition functions and could be removed, using the sclass field from the security structure instead.
This hook function is called from the kernel
ipcperms function, so it is called prior to all
IPC operations that will read or modify the IPC object. This hook
function checks unix_read
and/or
unix_write
permission to the IPC object based on
the flag, as shown in Table 28. These
permissions provide a coarse-grained equivalent to the Unix
permissions, whereas the other IPC hooks check finer-grained
permissions. These coarse-grained permission checks are not strictly
necessary, but ensure that all IPC accesses are mediated by the
policy.
When a task attempts to obtain an IPC object identifier for an existing object via one of the *get calls, the kernel calls the corresponding associate hook function for the object type. The SELinux IPC associate hook functions are:
selinux_sem_associate
selinux_shm_associate
selinux_msg_queue_associate
associate
permission
between the current task and the IPC object.This hook function checks permissions before performing an operation on the specified semaphore; the specific permission is determined by the operation being performed. The permissions required for each operation are shown in Table 29.
This hook function checks permissions for semaphore operations. It
always checks read
permission between the current
task and the semaphore. If the semaphore value is being altered, it
also checks write
permission between the current
task and the semaphore. Notice that these permissions are different
from the unix_read
and
unix_write
permissions checked by
selinux_ipc_permission.
This hook function checks permissions before performing an operation on the specified shared memory region; the specific permission is determined by the operation being performed. The permissions required for each operation are shown in Table 30.
This hook function checks permissions for shared memory attach
operations. It always check read
permission
between the current task and the shared memory object. If the
SHM_RDONLY
flag was not specified, then it also
checks write
permission between the current task
and the shared memory object. Notice that these permissions are
different from the unix_read
and
unix_write
permissions checked by
selinux_ipc_permission.
This hook function checks permissions before performing an operation on the specified message queue; the specific permission is determined by the operation being performed. The permissions required for each operation are shown in Table 31.
This hook function is called by the msgsnd system call to check the ability to place an individual message on a message queue. It performs three permission checks, involving the current task, the message queue, and the individual message. These checks are shown in Table 32. This hook function also sets the SID on the message if it is unlabeled. It calls the security_transition_sid interface of the security server to obtain a SID based on the SID of the task and the SID of the message queue.
This hook function can be called by either the msgsnd system call (for a pipelined send) or by the msgrcv system call to check the ability to receive an individual message from a message queue. Hence, the receiving task may not be the current task and is explicitly passed to the hook. This hook function performs two permission checks, involving the receiving task, the message queue, and the individual message. These permission checks are shown in Table 33. It is important to note that an error return from this hook simply causes the individual message to be ignored in the same manner as if it had the wrong message type. Hence, access denials on individual messages are not propagated to the calling process and may cause the calling process to block waiting for messages that are accessible.
<<< Previous | Home | Next >>> |
File Hook Functions | Socket Hook Functions |