On 5/7/2021 2:43 PM, Andrew Cagney wrote:
On Fri, 7 May 2021 at 15:08, Kavinda Wewegama
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
https://lists.libreswan.org/mailman/listinfo/swan-dev
<https://lists.libreswan.org/mailman/listinfo/swan-dev>
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
