[redhat-lspp] Re: [RFC] [MLSXFRM 00/04] Granular IPSec associ ations for use in MLS environments

[Stephen Smalley]

On Thu, 2006-06-15 at 16:12 -0400, Chad Hanson wrote:
> If you are wanting to use the CIPSO/NetLabel, why would you desire to use
> labeled IPSEC? Why not just use regular IPSEC along with CIPSO/NetLabel. 

You could establish ranges on the SAs and limit the CIPSO traffic on
that SA to being within that range.

> I did see your post on NetLabel where you stated you would be inclined
> to check if the CIPSO label is consistent with the IPSEC SA.
> 
> So the MLS labeling could look as follows for a packet:
> 
> SECMARK: SystemLow-SystemHigh
> IPSEC:   Unclass-Secret
> CIPSO/NetLabel: Secret
> 
> >From this, if you are willing to check the CIPSO consistency with IPSEC,
> IMHO it makes even more sense to check the IPSEC consistency with SECMARK.
> Or if no labeled IPSEC, check CIPSO directly against SECMARK. These
> consistency checks are what I desire in a routing configuration
> for forwarded traffic. 
> 
> IMHO, both labeled IPSEC and CIPSO at the same time seems to be a
> little overkill.
> 
> Currently, we have a product architecture where labeled packets 
> arrive on a ranged interface and then are forwarded without labels onto an 
> approriate unlabeled network. We would like a consistency check that
> verifies the packet should be allowed to leave the interface based on 
> the transmitted label. 
> 
> This routing ability is the main driver behind our desire to check the
> packet label against the iptables label for consistency on outbound
> traffic.

So, what is the obstacle to implementing such a permission check?  As
long as you are just using the secmark and not reviving the use of
node/netif/port SIDs, I don't see a problem there.

-- 
Stephen Smalley
National Security Agency