[redhat-lspp] [RFC] Trusted Networking Additions

[Stephen Smalley]

On Wed, 2006-05-31 at 17:28 -0400, James Morris wrote:
> On Wed, 31 May 2006, Chad Hanson wrote:
> 
> > 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
> 
> I'm not sure exactly what you're getting at here, but the whole point of 
> secmark is that you can use _any_ attribute of the packet for labeling, 
> including node, interface, or anything matchable via iptables.

Yes, I don't see why we need to revive SELinux node/netif checks, and
that would largely undo the benefits of secmark.
 
> So, there's no longer any node or port semantics in SELinux wrt packets, 
> as the selection and labeling phase is entirely performed in iptables.
> 
> e.g. you can select packets with:
> 
>  port 80 and eth0, and label them as external_httpd_packet_t
> 
> 
> or,
> 
>  port 80 and eth1 and 10.3.4.0/24 as internal_httpd_packet_t
> 
> > good example.  The secmark mechanism allows only a single label per port,
> 
> No, it depends on the iptables selectors.  The following rules are 
> exclusive:
> 
> iptables -t mangle -A INPUT -p tcp --dport 80 -i eth0
> iptables -t mangle -A INPUT -p tcp --dport 80 -i eth1
> 
> and can be labeled distinctly.
> 
> 
> > 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.
> 
> I think we need to keep these labeling mechanisms separate.
> 
> Secmark is a "local" labeling mechanism, where only attributes of packets 
> are used as selectors.
> 
> The xfrm labeling is a distributed labeling scheme, where labels on 
> network traffic represent the security contexts of _endpoints_, i.e. 
> domains on different systems which are communicating.  Not the packets 
> themselves.  This is an important distinction.

Hmm...well, another way of looking at it is that the xfrm labeling is
just leveraging a different attribute of the packet as a selector,
namely the security association, and these are all just ways of
classifying the security properties of the packet based on what
information we have available (whether it is the label information
supplied by the peer as in the IPSEC or NetLabel approaches or whether
it is the packet header information supplied by the peer as in the
iptables approach).   It would be nice if all three approaches could
boil down to just setting skb->secmark (with some prioritization among
them) and then applying a single per-packet send/recv check between the
socket SID and the skb secmark.    The PASSSEC options could then be
implemented in a uniform way based on skb->secmark as well.

-- 
Stephen Smalley
National Security Agency