TRUSTED NETWORKING The following is a brief description of a proposal to enhance SELinux networking for use in trusted environments with a view to leveraging the recent SECMARK additions and other higher level labeling such as that in the xfrm subsystem.
While the recent secamark additions (see http://james-morris.livejournal.com/11010.html) make network policy more expressive and separate labeling and enforcement, the following issues come to mind: - consistency among the various iptables rules per port, node and netif - should inconsistent policies be allowed? - lack of control over forwarded (transient) traffic - which label to use -- there are two labels on the data (secmark, ipsec) - should sshd (or other net aware apps) use the secmark label or the xfrm label? Based on the first two issues, a logical solution is bring back access control on nodes and interfaces in a slightly different manner. Prior to the secmark additions, nodes/interfaces/ports were treated as objects subject to socket access control. Now that there's a secmark on the packet (skb), the secmark could be subject to node and interface access. This would enable one to make sure unclassified data can only be sent to (or received from) the unclassified node/interface. Additionally, these low-level access controls allow for security policy on transient packets. We think this addition provides a higher level of assurance to verify that the iptables rules have been created correctly. The last issue relates to the usage of the different security labels. SSHD is a good example. The secmark mechanism allows only a single label per port, although in trusted communications, many labels could be transmitted across port 22 or 80 for example. This leads into the notion of having a single security marker independent of the labeling mechanism. Multiple markers can lead to confusion, especially from a trusted application perspective. Additionally, multiple security contexts can be confusing when dealing with transient traffic. PROPOSED IMPLEMENTATION On the inbound the packet will default to the unlabeled SID. The packet will then get labeled per iptables/secmark policy, if any. Next, the packet will then get checked against the node and interface in new SELinux local_in and forward netfilter hooks. If this is an IPSec packet, the packet will be relabeled with the association, overriding the current label. The packet will need to be rechecked node/interface checks will need to be repeated (in the IPSEC case) since the label on the packet may have changed. Finally, the socket packet check will then take place in rcv_skb like it currently does. On the outbound, the packet will be labeled with the label of the socket. If IPSEC is involved, the packet would be labeled with the label of the SA (to keep it symmetric/consistent) with the inbound. Otherwise the policy will potentially be using different TE Types for the inbound Vs. the outbound for node/interface checks (xfrm Type in the inbound case and socket Type in the outbound case). The packet is then checked Vs. node/interface. Since the packet is deriving it's label from the socket, the necessity of the socket Vs. packet check in postroute_last would be in question. The forward case would be a combination of portions of the inbound and outbound cases as shown in the following flows. OUTBOUND INBOUND Label pkt with label of sock Check sock --> pkt FORWARD _______________________________________ | | V Label pkt with xfrm label, if any Label pkt with xfrm label, if any (repeat node, netif checks) Check pkt --> Node Check pkt --> Node (local_in/forward hooks) Check pkt --> Netif Check pkt --> Netif (local_in/forward hooks) Check sock --> pkt Label pkt wth secmark per iptables, if none label with unlabeled SID Outstanding issues: 1. potential elimination of secmark of outbound packets 2. potential elimination of the association (sendto, recvfrom) -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
