<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"><<a moz-do-not-send="true"
href="mailto:Joshua.Kayse@gtri.gatech.edu" target="_blank">Joshua.Kayse@gtri.gatech.edu</a>></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 <<a
moz-do-not-send="true" href="mailto:shawn@redhat.com"
target="_blank">shawn@redhat.com</a><br>
</div>
<mailto:<a moz-do-not-send="true"
href="mailto:shawn@redhat.com" target="_blank">shawn@redhat.com</a>>>
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>
<mailto:<a moz-do-not-send="true"
href="mailto:fcaviggi@redhat.com" target="_blank">fcaviggi@redhat.com</a>><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/\.[^\.]*$// > ~/checks<br>
</div>
$ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh
| awk '{
<div class="im"><br>
print $1 }' | sed s/\.[^\.]*$// > ~/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>
<snip><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>