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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
