We use transport instead of tunnel, but this is out of a working mls client configuration script:
CLEARANCE=s15:c0.c1023
...
spdadd ${LOCAL_IP} ${REMOTE_IP} any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-${CLEARANCE}" -P out ipsec esp/transport//require;
spdadd ${REMOTE_IP} ${LOCAL_IP} any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-${CLEARANCE}" -P in ipsec esp/transport//require;
The environment is RHEL 6.2 with racoon (not openswan). racoon.conf:
...
sainfo anonymous
{
lifetime time 36 hours ;
encryption_algorithm aes ;
authentication_algorithm hmac_sha1 ;
compression_algorithm deflate ;
}
remote anonymous
{
dpd_delay 10;
exchange_mode main,base;
lifetime time 36 hours ;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 1;
}
}
---
joe
On Jul 6, 2013, at 2:21 PM, Sven Vermeulen <sven.vermeulen@xxxxxxxxx> wrote:
> 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
