[Swan-dev] FIPS Behavior Question

[Andrew Cagney]

On Fri, 7 May 2021 at 15:08, Kavinda Wewegama <
kavinda.wewegama at forcepoint.com> wrote:

>
> On 5/1/2021 12:41 PM, Andrew Cagney wrote:
>
> BTW, testing is still detecting unexpected audit records vis:
>
> https://testing.libreswan.org/v4.4-70-g291edd8b58-main/ikev2-labeled-ipsec-03-multi-acquires-enforced/OUTPUT/east.console.diff
> any ideas?
>
> I tracked this issue down to the way the test runs:
>
Thanks for figuring it out.


>    1. SELinux policy gets installed via `semodule -i` in `
>    {east,west}init.sh`.
>
>    2. `pluto` starts via `ipsec start` in `{east,west}init.sh`.
>
>    3. Test runs.
>
>    4. SELinux policy gets removed via `semodule -r` in `final.sh`. *NOTE:*
>    `pluto` is still running at this point.
>
>    5. `pluto` and `ip` perform actions triggering AVC (Access Vector
>    Cache) deny messages since the above SELinux policy is no longer in effect.
>    These are the messages we see in the audit log.
>
>    6. `pluto` stops via `ipsec stop` in  `post-mortem.sh`.
>
>    7. The audit log we see is output in `post-mortem.sh`.
>
> The solution is to not remove the SELinux policy until after `pluto`
> stops. But I haven't submitted any changes to the test scripts in case it
> causes issues elsewhere. And so, *how should we proceed here?*
>
final.sh looks something like:

 ../../guestbin/ipsec-look.sh
 semodule -r ipsecspd
 rm -rf tmp ipsecspd.fc ipsecspd.if
-if [ -f /sbin/ausearch ]; then ausearch -ts recent -m AVC | audit2allow ;
fi

(the ausearch was moved to post-mortem with a recent commit, but after the
pluto shutdown as you point out)

Drop <<semodule -r ipsecspd>>; when batch testing the reboot will flush the
module, and when a single test pluto is still running in the correct
environment making debugging easier?


>
> While a number of audit messages are covered by the existing policy, there
> were a couple of rules that were missing. I have rectified this:
> https://github.com/libreswan/libreswan/pull/420/commits/07f732bc69a857cd201e888ce36b03b81f233347
>
> -Kavinda
>
>
> On Fri, 30 Apr 2021 at 22:05, Kavinda Wewegama <
> kavinda.wewegama at forcepoint.com> wrote:
>
>>
>> On 4/27/2021 8:08 PM, Paul Wouters wrote:
>> > On Tue, 27 Apr 2021, Wewegama, Kavinda wrote:
>> >
>> >> When FIPS is enabled, how does it affect Libreswan behavior besides
>> >> enforcing certain cryptographic properties/restrictions?
>> >
>> > That should be the only difference. If something is rejected because of
>> > FIPS, there will be a clear log message about it.
>> >
>> >> The reason I ask is because I am noticing child/IPsec SAs getting
>> >> unsynchronized between tunnel endpoints if FIPS is enabled and SELinux
>> >> Enforcing is turned on. In the past, I didn’t have issues with either
>> >> FIPS by itself or with SELinux Enforcing by itself, but the
>> >> combination isn’t working well.
>> >
>> > That does not sound like a FIPS related problem with libreswan if you
>> > don't see clearly logged reasons of issues? Is there perhaps other FIPS
>> > restrictions that might be affecting the system from other components?
>>
>> The issue wasn't FIPS related per se but tended to manifest more easily
>> with FIPS enabled: https://github.com/libreswan/libreswan/issues/441
>>
>> My hypothesis for why I observed this behavior with FIPS enabled is
>> because enabling it triggers more chrony traffic which was not
>> permitted, i.e. pluto's SELinux domain did not have `setcontext`
>> permission against `chronyc_t`. But I don't have a way to confirm this.
>>
>> -Kavinda
>>
>> >
>> > Paul
>> _______________________________________________
>> Swan-dev mailing list
>> Swan-dev at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210507/0edc85b5/attachment-0001.html>