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 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.