<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/7/2021 2:43 PM, Andrew Cagney
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJeAr6tC6qvrJCURx4BUx0LmXwyYsugjFqDzsm=TmHH4vDq+yw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 7 May 2021 at 15:08,
Kavinda Wewegama <<a href="mailto:kavinda.wewegama@forcepoint.com" moz-do-not-send="true">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">
<div>
<p><br>
</p>
<div>On 5/1/2021 12:41 PM, Andrew Cagney wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank" moz-do-not-send="true">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>
</blockquote>
<p>I tracked this issue down to the way the test runs:<br>
</p>
</div>
</blockquote>
<div>Thanks for figuring it out.</div>
</div>
</div>
</blockquote>
<p>No problem.</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAJeAr6tC6qvrJCURx4BUx0LmXwyYsugjFqDzsm=TmHH4vDq+yw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p> </p>
<ol>
<li>SELinux policy gets installed via `semodule -i` in `
{east,west}init.sh`.<br>
<br>
</li>
<li>`pluto` starts via `ipsec start` in
`{east,west}init.sh`.<br>
<br>
</li>
<li>Test runs.<br>
<br>
</li>
<li>SELinux policy gets removed via `semodule -r` in
`final.sh`. <b>NOTE:</b> `pluto` is still running at
this point.<br>
<br>
</li>
<li>`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.<br>
<br>
</li>
<li>`pluto` stops via `ipsec stop` in `post-mortem.sh`.<br>
<br>
</li>
<li>The audit log we see is output in `post-mortem.sh`.</li>
</ol>
<p>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, <b>how should we proceed here?</b></p>
</div>
</blockquote>
<div>final.sh looks something like:</div>
<div><br>
</div>
<div> ../../guestbin/ipsec-look.sh<br>
semodule -r ipsecspd<br>
rm -rf tmp ipsecspd.fc ipsecspd.if<br>
-if [ -f /sbin/ausearch ]; then ausearch -ts recent -m AVC |
audit2allow ; fi</div>
<div><br>
</div>
<div>(the ausearch was moved to post-mortem with a recent
commit, but after the pluto shutdown as you point out)</div>
</div>
<div class="gmail_quote"><br>
</div>
<div>Drop <<semodule -r ipsecspd>>;</div>
</div>
</blockquote>
<p>Done:
<a class="moz-txt-link-freetext" href="https://github.com/libreswan/libreswan/pull/420/commits/768b8d1b7fd551c98afb2bfb835eb6965ce3aa2f">https://github.com/libreswan/libreswan/pull/420/commits/768b8d1b7fd551c98afb2bfb835eb6965ce3aa2f</a></p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAJeAr6tC6qvrJCURx4BUx0LmXwyYsugjFqDzsm=TmHH4vDq+yw@mail.gmail.com">
<div dir="ltr">
<div> 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?<br>
</div>
</div>
</blockquote>
<p>Agreed: having the SELinux policy still installed will make
debugging easier.</p>
<p>-Kavinda</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAJeAr6tC6qvrJCURx4BUx0LmXwyYsugjFqDzsm=TmHH4vDq+yw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<p>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:
<a href="https://github.com/libreswan/libreswan/pull/420/commits/07f732bc69a857cd201e888ce36b03b81f233347" target="_blank" moz-do-not-send="true">https://github.com/libreswan/libreswan/pull/420/commits/07f732bc69a857cd201e888ce36b03b81f233347</a><br>
</p>
<p>-Kavinda<br>
</p>
<blockquote type="cite"><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" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">Swan-dev@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.libreswan.org/mailman/listinfo/swan-dev</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>