SELinux provides control over socket IPC through a set of layered controls over sockets, messages, nodes, and network interfaces. Currently, the SELinux prototype only provides labeling and controls for INET and UNIX domain sockets. At the socket layer, SELinux controls the ability of processes to perform operations on sockets. At the transport layer, SELinux controls the ability of sockets to communicate with other sockets. At the network layer, SELinux controls the ability to send and receive messages on network interfaces, and it controls the ability to send messages to nodes and to receive messages from nodes. SELinux also controls the ability of processes to configure network interfaces and to manipulate the kernel routing table.
|
|
Since sockets are accessed through file descriptions, the socket object classes inherit the permissions defined for controlling access to the file object classes. Only a subset of these permissions are meaningful for sockets. Table 6 shows additional permissions that are specifically defined for controlling access to the socket object classes. The connection-oriented service provided by stream sockets requires several additional permissions, as shown in Table 7. Permissions for network interfaces and nodes are shown in Table 8.
Sockets effectively serve as communication proxies for processes in the SELinux control model. Consequently, sockets are labeled with the label of the creating process by default. A process may create and use a socket with a different label to perform socket IPC with a different source security label. A process may set up a listening socket so that server sockets created by connections are labeled with either a specified label or with the label of the connecting client socket to act as a server for multiple labels.
SELinux allows the security policy to distinguish between clients and servers for stream socket connections through the connectto and acceptfrom permissions. SELinux allows the security policy to base decisions on the kind of socket through the use of object classes, and it allows the security policy to base decisions on the message protocol through the per-protocol node and network interface permissions.
SELinux provides control over the association between INET domain sockets and port numbers and the association between UNIX domain sockets and files. Hence, the security policy can restrict the use of port numbers and pathnames for use by particular processes. SELinux also provides control over open file description transfer via UNIX domain sockets.
In SELinux, messages are associated with both the label of their sending socket and a separate message label. By default, this message label is the same as the sending socket label. A process may explicitly label individual messages if the underlying protocol supports message boundaries, i.e. datagram sockets. Messages sent on a stream socket all have the same label, which is the label of the stream socket.
Support for communicating message labels across the network has not yet been implemented in SELinux. The Fluke implementation of the Flask architecture used IPSEC/ISAKMP both to label and protect messages, storing the labeling information in the IPSEC security association. During an ISAKMP negotiation, the appropriate security contexts are sent across the network and the peer obtains SIDs for these security contexts and stores them in its IPSEC security association. When messages are subsequently received that use the IPSEC security association, the messages are validated and then labeled with the SIDs from the association. Similar support will be provided in SELinux using the FreeSWAN [14] IPSEC implementation. Integrating FreeSWAN with the SELinux network mandatory access controls is the next major phase for SELinux development.