On Tuesday, February 22, 2011 8:31:50 AM Steffen Klassert wrote: > On Wed, Feb 16, 2011 at 03:57:27PM -0500, Paul Moore wrote: > > On Mon, 2011-02-14 at 14:21 +0100, Steffen Klassert wrote: > > > As it is, we require the security context of a labeled SA to be the > > > same as the security context of the originating flow. On a nontrivial > > > selinux policy the security context of the flow of kernel generated > > > packets, like echo reply packets, are usually not equal to the > > > security context of the labeled SA. So it is not possible to send > > > such packets in this case. The fact that the security context of a > > > labeled SA must be the same as the security context of the originating > > > flow can also lead to problems if an outgoing SA is used for packet > > > forwarding and for locally generated traffic. > > > > > > This patch fixes this by removing this equality check. Instead we > > > ask the access vector cache if the security context of the SA is > > > compatible to the security context of the IPsec policy. This > > > partially reverts commit 67f83cbf081a70426ff667e8d14f94e13ed3bdca > > > > > > Signed-off-by: Steffen Klassert <steffen.klassert@xxxxxxxxxxx> > > > > I think understand the problem you're running up against, and if I'm > > understanding it correctly it is an inherent problem with the labeled > > IPsec design - not something that we can fix. > > Hm, I think we need to get this to work. Echo reply packets are just > one thing. Also other icmp messages can't be send. For example path mtu > discovery can't work with labeled IPsec. And have you tried to use > labeled IPsec on IPv6 networks? Kernel generated icmp messages are > quite important here. Yes, several years ago I worked on the IPsec stack for a commercial UNIX OS and we had to basically allow all IPv6/ICMP in the SPD so that router/neighbor discovery would work correctly. I believe that the specifications have now evolved to allow type/code which would make this a bit easier now. Why not just create a SPD rule that would send these ICMP packets over a traditional, unlabeled SA? Am I missing something that would require them to be sent over a labeled SA? > > The core issue is that with labeled IPsec the packets themselves are not > > labeled, the SAs are labeled instead. This means that in order to > > accurately convey peer labels over the network you need to ensure that > > the flow's label matches the SA label; this is why there is a direct SID > > to SID comparison in the code. Failing to match a flow to the > > associated SA will result in data being mis/relabeled which is a big > > no-no. > > I still don't understand why this is necessary, would'nt it be also > ok to enforce this with a policy rule? I have to think a bit longer > about that... Think about it some more and let me know if you are still having problems. It is absolutely critical that the SA's label matches the peer's label _exactly_. Once you understand how labeled IPsec conveys peer labels across the network, you will understand why this is so important. -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
