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