On Sat, Jul 06, 2013 at 11:40:46AM -0400, Chad Hanson wrote: > Are you running with MLS policy? I am curious since the last output > showed: system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023. I would expect > the following SPD context for MLS: > system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023. If not using MLS, you > would always fail in within_range() at > > if (!mls_ready) /*mls may not be enabled */ > return 0 > > There should be a log message at the startup of racoon if MLS is > disabled. I didn't originally notice your original SPD context wasn't > ranged: system_u:object_r:ipsec_spd_t:s0. This typically would be > system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023 on a MLS system. I'm running an MLS-enabled policy (but its MCS, so only a single sensitivity level but multiple categories). I was thinking about the range as well, but that doesn't seem to help. Right now, my spdadd statements include the c0.c1023 range, and I'm trying to generate communication through both a s0:c0.c1023-ranged process as well as "just" s0 to see what happens. Still no luck. spdadd 10.1.2.0/24 10.1.3.0/24 any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023" -P out ipsec esp/tunnel/192.168.100.152-192.168.100.153/require; spdadd 10.1.3.0/24 10.1.2.0/24 any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s0:c0.c1023" -P in ipsec esp/tunnel/192.168.100.153-192.168.100.152/require; There is no logging related to MLS. I also changed SELinux from enforcing to permissive but that didn't change the behavior here. I'm going to start inserting the necessary print statements in the code to see when (and why) the association isn't set up. Wkr, Sven Vermeulen -- 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.
