This subsection describes the control requirements for each Linux system call that provides a service implemented by the network component. The control requirements specify the permissions that must be granted for the system call to successfully execute. In the following tables, the control requirements for each system call are specified, where each control requirement is described by the class, permission, source SID (SSID), and target SID (TSID) used in a permission check. Since multiple calls may have the same requirements, more than one call may be listed in the leftmost column of a single table entry. In this case, all of the requirements in that table entry apply to all of the calls.
In the tables, network interface classes and SIDs are abbreviated by netif. A socket permission check uses the class of the socket being accessed, so the socket class in the tables may be any appropriate socket object class. Socket SIDs are abbreviated by so. Since a single call may involve multiple sockets, socket SIDs may be prefixed with a distinguishing identifier, such as listen_, client_, server_, or dst_.
Table 27 shows the control requirements for system calls used to perform connection-oriented communication. For each of these calls, permission is required to invoke the call on the socket, i.e. the listen, connect, accept, write, and read permissions. For Unix stream sockets that are bound in the file system namespace, the client process must be granted search permission to the directories in the path and write permission to the socket file in order to use connect.
On the server node, the newconn permission must be granted between the listening socket and the newly created server socket, and the acceptfrom permission must be granted between the server and client sockets. For TCP, these permissions are checked when the server receives the client's SYN packet on a listening socket. On the client node, the connectto permission must be granted between the client socket and the server socket. For TCP, this permission is checked when the client obtains the label of the server socket from the server's SYN-ACK packet. If a TCP simultaneous open occurs, then both nodes check connectto permission when they receive the other node's SYN packet. The appropriate connection permission (connectto or acceptfrom) must be revalidated when traffic is sent or received on an established connection, since a policy change may revoke permission for the connection. In this case, the connection must be reset. For TCP, on each node, the appropriate tcp_send and tcp_recv permissions must be granted for the network interface and the peer node.
For Unix stream sockets, the connectto permission check is redundant with the acceptfrom permission check, since the connection is local. Nonetheless, both permission checks are performed to maintain consistency with the TCP controls. The network control requirements for Unix stream sockets only differ from the TCP requirements in that there is no equivalent for the tcp_send and tcp_recv permission checks.
There is also an additional file control requirement for Unix stream or datagram communication, the receive requirement on file descriptions. As explained in the file system control design, open file descriptions must be labeled and controlled. The receive permission must be granted between the receiving process and each open file description received through Unix stream or datagram communication.
|
The control requirements for connectionless communication are shown in Table 28. As with the connection-oriented calls, permission is required to invoke each call on the socket, i.e. the connect, write, and read permissions. For Unix datagram sockets that are bound in the file system namespace, the client process must be granted search permission to the directories in the path and write permission to the socket file in order to use connect, sendto, or sendmsg.
On the sending node, the sendto permission must be granted between the source and destination sockets, and the send_msg permission must be granted between the source socket and the message. For AF_INET sockets, by default, the any_socket initial SID is used as the destination socket SID in the sendto permission check, since the sending node does not know the SID of the destination socket. On the receiving node, the recvfrom permission must be granted between the destination and source sockets, and the recv_msg permission must be granted between the destination socket and the message. For IPv4 traffic, on each node, the appropriate udp_send and udp_recv permissions, or the rawip_send and rawip_recv permissions, must be granted for the network interface and the peer node.
For Unix datagram communication, the SID of destination socket is known when the sendto permission check is performed, so it is used in the check. The sendto permission check is redundant with the recvfrom permission check, since the communication is local and since the actual destination socket SID is used in the sendto permission check. Nonetheless, both permission checks are performed to maintain consistency with the UDP and raw IP controls. The network control requirements for Unix datagram communication only differ from the UDP requirements in that there is no equivalent for the udp_send and udp_recv permission checks. As with Unix stream communication, there is the additional receive(fd) file control requirement when receiving file descriptors.
|
The control requirements for the other socket calls are shown in Table 29. The create permission must be granted in order to create a socket with the socket call. The other calls all require permission to invoke the call on an existing socket, e.g. the getattr permission. For AF_INET sockets, if the bind call is invoked with a port number outside of the range used to automatically bind sockets, then the name_bind permission must be granted between the socket and the port number. For AF_UNIX sockets, if the bind call is invoked with a name in the file system namespace, then the name_bind permission must be granted between the socket and the socket file.
|
The control requirements for the ioctl commands are shown in Table 30. The commands for manipulating the attributes of a network interface are controlled through the setattr and getattr permissions on each network interface. The remaining commands are controlled through system permissions.