[Swan-dev] FIPS Behavior Question

[Kavinda Wewegama]

On 5/7/2021 2:43 PM, Andrew Cagney wrote:
>
>
> On Fri, 7 May 2021 at 15:08, Kavinda Wewegama 
> <kavinda.wewegama at forcepoint.com 
> <mailto: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
>>     <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.

No problem.


>
>      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>>;

Done: 
https://github.com/libreswan/libreswan/pull/420/commits/768b8d1b7fd551c98afb2bfb835eb6965ce3aa2f


> 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?

Agreed: having the SELinux policy still installed will make debugging 
easier.

-Kavinda


>
>     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
>     <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
>>     <mailto: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
>>         <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
>>         <mailto:Swan-dev at lists.libreswan.org>
>>         https://lists.libreswan.org/mailman/listinfo/swan-dev
>>         <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/2978d9c1/attachment-0001.html>