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

[Paul Moore <paul moore hp com>]

Venkat Yekkirala wrote:
> The current approach to labeling Security Associations for SELinux purposes
> uses a one-to-one mapping between xfrm policy rules and security associations.
> This doesn’t address the needs of real world MLS (Multi-level System, traditional
> Bell-LaPadula) environments where a single xfrm policy rule (pertaining to a range,
> classified to secret for example) might need to map to multiple Security Associations
> (one each for classified, secret, top secret and all the compartments applicable to
> these security levels).
> 
> This patch set addresses the above problem by allowing for the mapping of a single
> xfrm policy rule to multiple security associations, with each association used in
> the security context it is defined for. It also includes the security context to be
> used in IKE negotiation in the acquire messages sent to the IKE daemon so that a unique
> SA can be negotiated for each unique security context. A couple of bug fixes are also
> included; checks to make sure the SAs used by a packet match policy (security context-wise)
> on the inbound and also that the bundle used for the outbound matches the security context
> of the flow. This patch set also makes the use of the SELinux sid in flow cache lookups
> seemless by including the sid in the flow key itself.

I wonder if this would be more useful if the entire SELinux context was
taken into account and not just the MLS label?  Looking (somewhat
quickly) at the patch you just posted I don't think it would require too
much extra work to make it happen, it looks like you have already added
the full SELinux context to the IPsec selector which I suspect is the
bulk of the kernel-side work.  However, I imagine this would require a
bit more work in racoon/IKE side of things ...

-- 
paul moore
linux security @ hp