Yeah, I know.

But I like to change my audit rules when I add new services/items that need to be audited.

Anywhere that's actually paying you money to keep their servers up isn't going to be thrilled with you rebooting them....ever.

If you're actually auditing your audit rules and offloading your logs, you'll see someone changing them and thus can react to the change.

-e 2 makes your system *less* secure in many SLA settings (since you can't actually audit as much as you should be given system changes) and should be in the realm of 'ideal'.

Trevor


On Sat, Oct 5, 2013 at 11:33 PM, <fcaviggi@redhat.com> wrote:
Trevor,

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.

Regards,

Frank



On 10/05/2013 09:27 PM, Trevor Vaughan wrote:
Personally, I'm massively opposed to '-e 2'.

I really like the ability to audit new things as I add them without rebooting my systems.

Trevor


On Fri, Oct 4, 2013 at 8:06 AM, Josh Kayse <Joshua.Kayse@gtri.gatech.edu> wrote:
On 10/04/2013 07:40 AM, Trevor Vaughan wrote:
Is Augeas an option?

This seems like the perfect opportunity to solidify the Augeas lenses
regarding security settings while making life easier for everyone.

Trevor


On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn@redhat.com
<mailto:shawn@redhat.com>> wrote:

    On 10/3/13 3:11 PM, fcaviggi@redhat.com <mailto:fcaviggi@redhat.com>
    wrote:
    All,

    As a starting point for writing remediation fixes in the SSG - so,
    I did the following:

        $ ls ~//scap-security-guide/RHEL6/input/checks//*.xml | awk '{

    print $1 }' | sed s/\.[^\.]*$// > ~/checks
        $ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh | awk '{

    print $1 }' | sed s/\.[^\.]*$// > ~/fixes
        $ sdiff ~/fixes ~/checks | less

    There's fair a bit of work to be done for the fix remediations...

    Since I'm new to the project, I was wondering if there was any
    ideas or standards to how the SSG should distribute some of these
    fixes - for example - a wholesale replacement of the audit.rules
    and auditd.conf might be preferable than doing piecemeal sed's.

    It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules
    /etc/audit.rules`, and that likely is the right choice during an
    initial provisioning process. But then SysAdmins tailor audit rules,
    the system evolves, and we need to evaluate the audit.rules file
    against specific auditing guidance items after the pristine
    audit.rules template is manipulated.

    So, if a single rule must be remediated, we can't blow away the
    whole audit.rules file. Super fun sed scripts it is =/

<snip>

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.

-josh

--
404.407.6630


_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com

-- This account not approved for unencrypted proprietary information --


_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


-- 
Frank Caviggia
Consultant, Public Sector
fcaviggi@redhat.com
(M) (571) 295-4560

_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide




--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan@onyxpoint.com

-- This account not approved for unencrypted proprietary information --