[redhat-lspp] [RFC] Trusted Networking Additions

[Venkat Yekkirala]

On the inbound, secmark seems fine (as also the socket access to the skb per
secmark), but on the outbound, wouldn't it be logical to take the secmark
from the socket (or in the forward case from the forward iptables rules) and
perform a check of the secmark against the node/netif.

> -----Original Message-----
> From: Stephen Smalley [mailto:sds at tycho.nsa.gov]
> Sent: Thursday, June 01, 2006 7:12 AM
> To: James Morris
> Cc: Karl MacMillan; Chad Hanson; Darrel Goeddel; RedHat LSPP; Venkat
> Yekkirala
> Subject: Re: [redhat-lspp] [RFC] Trusted Networking Additions
> 
> 
> 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
>