next up previous contents
Next: API extensions Up: Design Previous: Permissions   Contents


Control Requirements

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: Control requirements for connection-oriented communication. The tcp_send and tcp_recv permission requirements only apply to TCP traffic, not Unix stream traffic. The receive permission requirement only applies to Unix stream traffic containing file descriptors.
  CONTROL REQUIREMENT(S)
CALL(S) CLASS PERM SSID TSID
listen socket listen current so
  socket newconn so newconn_sid
connect socket connect current client_so
  socket connectto client_so server_so
  netif tcp_send client_so netif
  node tcp_send client_so node
  netif tcp_recv server_so netif
  node tcp_recv server_so node
accept socket accept current listen_so
  socket newconn listen_so server_so
  socket acceptfrom server_so client_so
  netif tcp_send server_so netif
  node tcp_send server_so node
  netif tcp_recv client_so netif
  node tcp_recv client_so node
write, socket write current so
send, socket connectto so peer_so
sendto, socket acceptfrom so peer_so
sendmsg netif tcp_send so netif
  node tcp_send so node
  netif tcp_recv peer_so netif
  node tcp_recv peer_so node
read, socket read current so
recv, socket connectto so peer_so
recvfrom, socket acceptfrom so peer_so
recvmsg netif tcp_send so netif
  node tcp_send so node
  netif tcp_recv peer_so netif
  node tcp_recv peer_so node
  fd receive current fd


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.


Table 28: Control requirements for connectionless communication. The udp_send and udp_recv permission requirements only apply to UDP traffic. The rawip_send and rawip_recv permission requirements apply to any IPv4 traffic other than TCP or UDP. The receive permission requirement only applies to Unix datagram traffic containing file descriptors.
  CONTROL REQUIREMENT(S)
CALL(S) CLASS PERM SSID TSID
connect socket connect current so
write, socket write current so
send, socket sendto so dst_so
sendto, socket send_msg so msg
sendmsg netif udp_send msg netif
  node udp_send msg node
  netif rawip_send msg netif
  node rawip_send msg node
read, socket read current so
recv, socket recvfrom so src_so
recvfrom, socket recv_msg so msg
recvmsg netif udp_recv msg netif
  node udp_recv msg node
  netif rawip_recv msg netif
  node rawip_recv msg node
  fd receive current fd


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.


Table 29: Control requirements for other socket calls.
  CONTROL REQUIREMENT(S)
CALL(S) CLASS PERM SSID TSID
socket socket create current so
bind socket bind current so
  socket name_bind so port
getsockname socket getattr current so
getpeername socket getattr current so
getsockopt socket getopt current so
setsockopt socket setopt current so
shutdown socket shutdown current so


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.


Table 30: Control requirements for ioctl commands.
  CONTROL REQUIREMENT(S)
CALL(S) CLASS PERM SSID TSID
ioctl: TIOC- socket getattr current so
OUTQ,      
INQ      
ioctl: SIOC- netif getattr current netif
GIFADDR,      
GIFBRDADDR,      
GIFDSTADDR,      
GIFNETMASK      
ioctl: SIOC- netif setattr current netif
SIFFLAGS,      
SIFADDR,      
SIFBRDADDR,      
SIFDSTADDR,      
SIFNETMASK      
ioctl: SIOC- system route- current kernel
ADDRT,   _control  
DELRT,      
RTMSG      
ioctl: SIOC- system arp- current kernel
DARP,   _control  
GARP,      
CSARP      
ioctl: SIOC- system rarp- current kernel
DRARP,   _control  
GRARP,      
CSRARP      
ioctl: system net_io- current kernel
device-specific   _control  


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.


next up previous contents
Next: API extensions Up: Design Previous: Permissions   Contents