<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">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">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> <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>>; 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 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">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">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">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">Swan-dev@lists.libreswan.org</a><br>
          <a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan-dev</a><br>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div></div>