Networking in NSA Security-Enhanced Linux

The system_u user and object_r role are default values for system objects. It wouldn't make any sense for a port to have a real user or role; it's not owned by anyone and it doesn't initiate any actions that require a verdict from SELinux.

A socket is labeled by its associated inode and is categorized as either a generic socket or one of the following socket subclasses:

Subclasses of sockets can be distinguished in security policy, providing for fine-grained control and flexibility over different network protocols:

allow lpd_t printer_port_t:tcp_socket name_bind;

This rule allows only a TCP socket created in the lpd_t domain to bind to a port of type printer_port_t.

IPv4 and IPv6 ports are labeled implicitly within the kernel, as specified by policy. The format for labeling port types is:

portcon protocol { port number | port range }
        context

The following defines a security context for labeling the standard printer port:

portcon tcp 515 system_u:object_r:printer_port_t

Each network interface (netif) is labeled with a security context, as specified in policy. Network interfaces are labeled as follows:

netifcon interface context default_msg_context

The default_msg_context parameter is intended to be used for labeling messages arriving on the interface, but is not currently used.

Here are some examples of netif labeling in policy:

netifcon eth0 system_u:object_r:netif_intranet_t [...]
netifcon eth1 system_u:object_r:netif_extranet_t [...]

Under SELinux, a node refers to an IPv4 or IPv6 address and netmask. It allows host and network addresses to be labeled with security contexts via policy.

The format for labeling nodes is:

nodecon address mask context

Here are examples of labeling localhost addresses:

nodecon 127.0.0.1 255.255.255.255
        system_u:object_r:node_lo_t
nodecon ::1   ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
        system_u:object_r:node_lo_t

Access-control hooks are implemented for every socket system call, allowing all socket-based network protocols to be mediated by SELinux policy. A few hooks are used only for housekeeping, but otherwise, hooks generally are used to check one or more access-control permissions.

As there are a large number of generic socket controls, see Table 1 for the relationships between the hooks, socket system calls and permissions.

Internally, the socket() system call is decomposed into two hooks. The selinux_socket_create hook is used to check whether the process can create a socket of the type requested. The selinux_socket_post_create management hook is used to assign a security label and socket class to the newly allocated inode associated with the socket.

The SELinux permissions also abstract the way system calls and other operations are viewed from a security point of view. Note, for example, that the getattr permission is used for the getsockname() and getpeername() system calls. They are seen to be equivalent security-wise by SELinux. Similarly, all of the sendmsg()- and recvmsg()-based system calls are reduced for security management purposes into simply read and write. For the curious, the code behind these hooks can be found in the 2.6 kernel, in security/selinux/hooks.c.

As sockets are also files, they inherit some of the access controls associated with files. Table 2 lists the file-specific hooks and permissions inherited by sockets.