<div dir="ltr">BTW, testing is still detecting unexpected audit records vis:<div><a href="https://testing.libreswan.org/v4.4-70-g291edd8b58-main/ikev2-labeled-ipsec-03-multi-acquires-enforced/OUTPUT/east.console.diff">https://testing.libreswan.org/v4.4-70-g291edd8b58-main/ikev2-labeled-ipsec-03-multi-acquires-enforced/OUTPUT/east.console.diff</a><br></div><div>any ideas?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 30 Apr 2021 at 22:05, Kavinda Wewegama <<a href="mailto:kavinda.wewegama@forcepoint.com">kavinda.wewegama@forcepoint.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 4/27/2021 8:08 PM, Paul Wouters wrote:<br>
> On Tue, 27 Apr 2021, Wewegama, Kavinda wrote:<br>
><br>
>> When FIPS is enabled, how does it affect Libreswan behavior besides <br>
>> enforcing certain cryptographic properties/restrictions?<br>
><br>
> That should be the only difference. If something is rejected because of<br>
> FIPS, there will be a clear log message about it.<br>
><br>
>> The reason I ask is because I am noticing child/IPsec SAs getting <br>
>> unsynchronized between tunnel endpoints if FIPS is enabled and SELinux<br>
>> Enforcing is turned on. In the past, I didn’t have issues with either <br>
>> FIPS by itself or with SELinux Enforcing by itself, but the<br>
>> combination isn’t working well.<br>
><br>
> That does not sound like a FIPS related problem with libreswan if you<br>
> don't see clearly logged reasons of issues? Is there perhaps other FIPS<br>
> restrictions that might be affecting the system from other components?<br>
<br>
The issue wasn't FIPS related per se but tended to manifest more easily <br>
with FIPS enabled: <a href="https://github.com/libreswan/libreswan/issues/441" rel="noreferrer" target="_blank">https://github.com/libreswan/libreswan/issues/441</a><br>
<br>
My hypothesis for why I observed this behavior with FIPS enabled is <br>
because enabling it triggers more chrony traffic which was not <br>
permitted, i.e. pluto's SELinux domain did not have `setcontext` <br>
permission against `chronyc_t`. But I don't have a way to confirm this.<br>
<br>
-Kavinda<br>
<br>
><br>
> Paul<br>
_______________________________________________<br>
Swan-dev mailing list<br>
<a href="mailto:Swan-dev@lists.libreswan.org" target="_blank">Swan-dev@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan-dev</a><br>
</blockquote></div>