Section 10.3. Network and Socket Object Labeling
10.3. Network and Socket Object LabelingNetwork and socket objects are labeled using policy statements and initial SIDs; there is no mechanism for program-requested labeling. We use several policy labeling statements to label network and socket objects. Table 10-2 lists all the network and socket-specific labeling statements and the relevant object classes.
10.3.1. Network Interface Labeling (netifcon)Network interfaces are labeled with the network interface security context statement (netifcon) or with the netif initial SID. For example, consider the following statement: netifcon eth0 system_u:object_r:netif_t system_u:object_r:packet_t This statement provides the security context for the network device eth0 as system_u:object_r:netif_t (that is, the first security context) and the default label for packets received on this interface as system_u:object_r:packet_t (that is, the second security context). The default packet label is not currently used and is awaiting support for per-packet labeling. The full syntax for the netifcon statement is shown in the sidebar on page 146. The network interface name, eth0 in this example, is the same interface as understood by the ifconfig(8) command. Note Per-packet labeling, which allows finer-grained control over networking, was part of the initial implementation of SELinux but was not included when SELinux was merged into the Linux kernel as an LSM module. There was concern over the invasiveness and performance impact of many of the fine-grained network controls, particularly those that would result in additional access checks on the processing of every packet. As a result, some SELinux network controls, such as per-packet labeling, were not included. Work is ongoing to re-create these features in a way acceptable to the Linux kernel community leveraging other technologies such as Netfilter and IPsec. Any network interface that is not labeled with a netifcon statement is labeled with the netif initial SID security context.
10.3.2. Network Node Labeling (nodecon)Node objects are labeled with the node security context statement (nodecon) or the node initial SID. The nodecon statement labels node objects by subnet and network mask. Recall from Chapter 4 that the node object class represents network nodes by IP address. For example, consider the following statement: nodecon 127.0.0.1 255.255.255.255 system_u:object_r:node_lo_t This statement indicates that all nodes with the IPv4 address 127.0.0.1 and the subnet mask 255.255.255.255 (that is, exactly one host, 127.0.0.1 or localhost) are labeled with the security context system_u:object_r:node_lo_t. The full syntax for the nodecon statement can be seen in the sidebar on page 148. The nodecon statement supports IPv4 addresses, like the example above, and IPv6 addresses. For example, consider the following statement: nodecon ::1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff system_u:object_r:node_lo_t This nodecon statement is the IPv6 equivalent of the previous IPv4 example for specifying localhost. The nodecon statement supports inexact matches in addition to exact matches. For example, the following statement matches an entire subnet: nodecon 192.168.0.0 255.255.255.0 system_u:object_r:node_intranet_t The example statement above would match all hosts on the 192.168.0.0 subnet for a Class C network. Node security context statements are automatically ordered by the policy compiler so that more specific statements are matched first, similarly to how genfscon statements work. This convention allows the policy to contain nodecon statements with overlapping IP address ranges and resolve the conflicts naturally. For example, consider a policy with the following statements: nodecon 192.168.0.0 255.255.0.0 system_u:object_r:node_intranet_t nodecon 192.168.1.0 255.255.255.0 system_u:object_r:node_webserver_t In this example, the nodecon statement with the partial IP address 192.168.0.0 is more general than a statement with the partial IP address 192.168.1.0. The automatic node security context statement ordering ensures that all addresses in the 192.168.1.0 subnet (for example, 192.168.1.100) will match the second statement and receive the type webserver_t while all other addresses in the 192.168.0.0 subnet (for example, 192.168.2.1) will match the first statement. The currently available policies do not make extensive use of node labeling, generally labeling only localhost and all other nodes. For example, these statements are representative of the IPv4 nodecon statements for most general-purpose policies: nodecon 127.0.0.1 255.255.255.255 system_u:object_r:node_lo_t nodecon 0.0.0.0 255.255.255.255 system_u:object_r:node_inaddr_any_t This strategy is used to remove the need for customizing the policy based on local network settings. Many custom-built policies for specific applications tend to reengineer the network policy to afford better control of the network. All nodes without a matching nodecon statement are labeled with the node initial SID security context.
10.3.3. Network Port Labeling (portcon)Socket objects representing ports are labeled with the port security context statement (portcon) or the port initial SID. The portcon statement labels ports based on protocol and port number or range. For example, consider the following statement: portcon tcp 80 system_u:object_r:http_port_t This statement shows that the portcon statement syntax requires the protocol (tcp or upd), the port number or range, and a security context. Notice that the statement does not end in a semicolon. The full syntax for the port security context statement is in the sidebar on page 150. The above statement labels the TCP port 80 with the security context system_u:object_r:http_port_t. It is common for portcon statements to overlap when using port ranges. For example, consider the following statements: portcon tcp 80 system_u:object_r:http_port_t portcon tcp 1-1023 system_u:object_:reserved_port_t Both of these portcon statements match TCP port 80. In the case of overlap, the first matching statement is used. In this example, TCP socket objects associated with network port 80 would receive the security context system_u:object_r:http_port_t, whereas any other port between 1 and 1023 would receive the security context system_u:object_:reserved_port_t. This method of resolution makes policy maintenance simpler by allowing the insertion of a broad labeling statement that can be overridden over time by inserting more specific statements. When a new, specific statement is inserted the original initial statement does not need to be changed. Unlike the nodecon statements, which are ordered by specificity, the portcon statements are matched in the order specified in the policy. This means that it is possible to order portcon statements in a way that a statement would never be matched. In this case, the policy compiler issues a warning. Network ports that do not match any portcon statements are labeled with the port initial SID. What may not be clear from our discussion of the portcon statement so far is what objects are actually being labeled. You might have noticed from Chapter 4 that there is no object class specifically for ports. Permissions relating to ports are access checks against socket objects labeled with the port type. The socket object instance used to check port permissions is distinct from the socket object instance used for communication by the process, which is labeled with the type of the creating process. For example, assume that TCP port 80, which is normally used for HTTP traffic, is labeled http_port_t. Allowing a process of type httpd_t to receive TCP data on this port would require permission on a TCP socket labeled with the process type and permission on a TCP socket with the type http_port_t. To illustrate, the rules to allow only the receipt of the TCP data (via the recv_msg permission on the tcp_socket object class), would look like the following: allow httpd_t self : tcp_socket recv_msg; allow httpd_t http_port_t : tcp_socket recv_msg; These rules clearly show the two tcp_socket object instances. Table 10-2 shows which permissions on which socket object classes are checked on objects labeled with the port type.
10.3.4. Socket LabelingSockets created by processes using the socket(2) system call inherit their security context from the creating process. Sockets used to check the permissions associated with ports are discussed above with the portcon statement. For example, a process with the security context system_u:system_r:httpd_t would create sockets with the same security context. This means that to allow this domain type to send and receive using a TCP socket, an allow rule similar to the following would be required: allow httpd_t self : tcp_socket { read write send_msg recv_msg };This example illustrates how the TCP socket object is labeled; additional permissions are required for realistic usage of sockets. The labeling of all socket objects created by userspace processes, including local sockets such as Netlink and UNIX domain sockets, are labeled in this way. Sockets created by the kernel are labeled with the security context of the kernel initial SID. |
EAN: 2147483647
Pages: 154