<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Trevor,<br>
      <br>
      The -e 2 setting ensures that the audit rules are immutable until
      the next reboot.  It ensures the configuration can't be changed by
      doing someone doing something nefarious to the system.<br>
      <br>
      Regards,<br>
      <br>
      Frank<br>
      <br>
      <br>
      On 10/05/2013 09:27 PM, Trevor Vaughan wrote:<br>
    </div>
    <blockquote
cite="mid:CANs+FoXQ__BBNUJF3k_XMz1jEL88hRKgynbHPtmsebLRJbyJ_w@mail.gmail.com"
      type="cite">
      <div dir="ltr">Personally, I'm massively opposed to '-e 2'.
        <div><br>
        </div>
        <div>I really like the ability to audit new things as I add them
          without rebooting my systems.</div>
        <div><br>
        </div>
        <div>Trevor</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Fri, Oct 4, 2013 at 8:06 AM, Josh
          Kayse <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:Joshua.Kayse@gtri.gatech.edu" target="_blank">Joshua.Kayse@gtri.gatech.edu</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="im">On 10/04/2013 07:40 AM, Trevor Vaughan
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="im">
                Is Augeas an option?<br>
                <br>
                This seems like the perfect opportunity to solidify the
                Augeas lenses<br>
                regarding security settings while making life easier for
                everyone.<br>
                <br>
                Trevor<br>
                <br>
                <br>
                On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells &lt;<a
                  moz-do-not-send="true" href="mailto:shawn@redhat.com"
                  target="_blank">shawn@redhat.com</a><br>
              </div>
              &lt;mailto:<a moz-do-not-send="true"
                href="mailto:shawn@redhat.com" target="_blank">shawn@redhat.com</a>&gt;&gt;
              wrote:<br>
              <br>
                  On 10/3/13 3:11 PM, <a moz-do-not-send="true"
                href="mailto:fcaviggi@redhat.com" target="_blank">fcaviggi@redhat.com</a>
              &lt;mailto:<a moz-do-not-send="true"
                href="mailto:fcaviggi@redhat.com" target="_blank">fcaviggi@redhat.com</a>&gt;<br>
                  wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div class="im">
                      All,<br>
                  <br>
                      As a starting point for writing remediation fixes
                  in the SSG - so,<br>
                      I did the following:<br>
                  <br>
                </div>
                        $ ls ~//scap-security-guide/RHEL6/input/checks//*.xml
                | awk '{
                <div class="im"><br>
                      print $1 }' | sed s/\.[^\.]*$// &gt; ~/checks<br>
                </div>
                        $ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh
                | awk '{
                <div class="im"><br>
                      print $1 }' | sed s/\.[^\.]*$// &gt; ~/fixes<br>
                          $ sdiff ~/fixes ~/checks | less<br>
                  <br>
                      There's fair a bit of work to be done for the fix
                  remediations...<br>
                  <br>
                      Since I'm new to the project, I was wondering if
                  there was any<br>
                      ideas or standards to how the SSG should
                  distribute some of these<br>
                      fixes - for example - a wholesale replacement of
                  the audit.rules<br>
                      and auditd.conf might be preferable than doing
                  piecemeal sed's.<br>
                </div>
              </blockquote>
              <div class="im">
                <br>
                    It'd be omgz easier to `cp
                /usr/share/doc/audit-*/stig.rules<br>
                    /etc/audit.rules`, and that likely is the right
                choice during an<br>
                    initial provisioning process. But then SysAdmins
                tailor audit rules,<br>
                    the system evolves, and we need to evaluate the
                audit.rules file<br>
                    against specific auditing guidance items after the
                pristine<br>
                    audit.rules template is manipulated.<br>
                <br>
                    So, if a single rule must be remediated, we can't
                blow away the<br>
                    whole audit.rules file. Super fun sed scripts it is
                =/<br>
                <br>
              </div>
              &lt;snip&gt;<br>
            </blockquote>
            <br>
            I think that augeas is a good idea.  We need to be careful
            that rules that are inserted in to audit.rules happen before
            any '-e 2' line (if one exists).  Otherwise they will fail
            to be inserted because the audit rules become locked.<span
              class="HOEnZb"><font color="#888888"><br>
                <br>
                -josh<br>
                <br>
                -- <br>
                <a moz-do-not-send="true" href="tel:404.407.6630"
                  value="+14044076630" target="_blank">404.407.6630</a><br>
                <br>
              </font></span><br>
            _______________________________________________<br>
            scap-security-guide mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
            <a moz-do-not-send="true"
href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide"
              target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
            <br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        Trevor Vaughan<br>
        Vice President, Onyx Point, Inc<br>
        (410) 541-6699<br>
        <a moz-do-not-send="true" href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br>
        <br>
        -- This account not approved for unencrypted proprietary
        information --
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
scap-security-guide mailing list
<a class="moz-txt-link-abbreviated" href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Frank Caviggia
Consultant, Public Sector
<a class="moz-txt-link-abbreviated" href="mailto:fcaviggi@redhat.com">fcaviggi@redhat.com</a>
(M) (571) 295-4560</pre>
  </body>
</html>