Description of problem: When labeled ipsec is configured, cannot ping loopback. Version-Release number of selected component (if applicable): I am using lspp 56 kernel with RHEL5 beta1 refresh. How reproducible: All the time. Steps to Reproduce: 1. echo 0 > /proc/sys/net/ipv4/confeth0/disable_policy echo 0 > /proc/sys/net/ipv4/confeth0/disable_xfrm 2. Use setkey to install the labeled ipsec config. My labeled ipsec config is: add 127.0.0.1 127.0.0.1 esp 35590 -m transport -ctx 1 1 "system_u:object_r:ping_t:s0-s15:c0.c1023" -E 3des-cbc "06183223c23a21e8b36c566b"; spdadd 127.0.0.1 127.0.0.1 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0-s15:c0.c1023" -P in ipsec esp/transport//require; spdadd 127.0.0.1 127.0.0.1 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0-s15:c0.c1023" -P out ipsec esp/transport//require; 3. ping 127.0.0.1 Actual results: The ping hangs. Expected results: The ping to succeed Additional info: When I try this exact same config minus the security context, the ping works. Thus I have concluded something is incorrect when using labels. I did not see any avc denied messages in my /var/log/audit/audit.log
I meant to add 2 more things. 1. That I am running selinux in permissive mode. 2. The ping does not hang but comes back with, "connect: No such process". This has led me to believe it cannot find the needed SA, although I have installed the SA. I have also tried this on rhel5 beta2 with lspp56 kernel and get the same results.
In step 1., it should read echo 0 > /proc/sys/net/ipv4/conf/lo/disable_policy echo 0 > /proc/sys/net/ipv4/conf/lo/disable_xfrm
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
----- Additional Comments From latten.com 2006-12-11 20:56 EDT ------- Ok, I figured it out. In selinux_xfrm_state_pol_flow_match() we no longer do a "polmatch" check on the SA and policy. Instead, we do "if (fl->secid != state_sid)" check. This obsoleted my policy. It is most likely that racoon will always negotiate the SA's correctly. Racoon doesn't appear to be able to negotiate with itself for loopback to work though. So I think if you want to use labeled ipsec over loopback, you need to make sure the SA's context exactly matches the flow's, when setting up manually. For ping over labeled ipsec, an SA with context, "root:sysadm_r:ping_t:s0-s15:c0.c1023" worked for me. This event sent from IssueTracker by araghavan issue 108572
Joy, can you remind me again where we stand with this? I believe at one point you were going to talk with the ipsec people about making racoon talk to itself over loopback. Did that go anywhere? Can you help me get back up to date after my brain rotted during vacation?
I queried the ipsec-tools list but did not get any helpful info. One person stated they tried this a while back and could not get it to work. I started looking at the racoon code to see if it would be trivial to fix. Did not get very far with this as I had other lspp development items at equal priority. Joe Nall has also been looking at the code and sent me a racoon patch he created yesterday to look at. He says it needs more work. I will try and look at it later today or tomorrow.
https://www.redhat.com/archives/redhat-lspp/2007-January/msg00136.html
Per 2/12 discussion, Joy continues to work on a patch.
As this is likely going to have to be a userspace patch to ipsec-tools adding harald to ipsec-tools maintainer
Ran a 16 hour labeled ipsec stress test with the patched racoon. Sent streams of packets over loopback as well as eth0 to a remote to test how racoon would work in both schemes. While the stress tests completed successfully, I saw what I believe to be unusual behaviour. SAs were being created twice instead of once. So I will continue to work on this patch.
Joy will run one more day of stress testing.
reassigning to harald. jlatten should be attaching a patch for ipsec-tools very soon.
I have sent the patch that started off as a proof of concept from Paul Moore to th ipsec-tools community. I have been testing for last 24 hours without problems, but will continue to test until I feel less wary. I also would like to hear from ipsec-tools list. http://sourceforge.net/mailarchive/forum.php?thread_name=1175634159.3085.659.camel%40faith.austin.ibm.com&forum_name=ipsec-tools-devel
Created attachment 151822 [details] Patch that allows racoon to negotiate wih itself over loopback. Patch sent to ipsec-tools list. Still awaiting feedback and acceptance. This patch includes Paul Moore's proof of concept.
Stress test over weekend with lspp.72 kernel and latest racoon leaks file descriptors. Test ran 36 hours. See bug 235680.
sgrubb: Got OK to build.
Joy, this needs to be backported to RHEL5.
built ipsec-tools-0.6.5-6.3 to address this issue.
Joy, can you verify that this is fixed in a build? Thanks.
Ok, I just tried it and it appears to be working ok. However, I have not yet had this accepted upstream and would rather not close this until it is accepted.
Hello, Closing issue per last update. Thank You Joe Kachuck Internal Status set to 'Resolved' Status set to: Closed by Tech Resolution set to: 'RHEL 5.1' This event sent from IssueTracker by jkachuck issue 108572