From mboxrd@z Thu Jan  1 00:00:00 1970
From: Burn Alting <burn@swtf.dyndns.org>
Subject: Adding enterprise capability - an includeConfig directive for
	audit.rules?
Date: Wed, 27 Mar 2013 20:38:07 +1100
Message-ID: <1364377087.31258.25.camel@swtf.swtf.dyndns.org>
Reply-To: burn@swtf.dyndns.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com
	[10.5.110.21])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id r2R9cIvC005390
	for <linux-audit@redhat.com>; Wed, 27 Mar 2013 05:38:18 -0400
Received: from gateway.swtf.dyndns.org (203-219-87-38.static.tpgi.com.au
	[203.219.87.38])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2R9cGG2003932
	for <linux-audit@redhat.com>; Wed, 27 Mar 2013 05:38:17 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by gateway.swtf.dyndns.org (Postfix) with ESMTP id 923EC24D005D
	for <linux-audit@redhat.com>; Wed, 27 Mar 2013 20:35:00 +1100 (EST)
Received: from [192.168.2.100] (unknown [192.168.2.100])
	by gateway.swtf.dyndns.org (Postfix) with ESMTP id 2BBFD24D0045
	for <linux-audit@redhat.com>; Wed, 27 Mar 2013 20:34:59 +1100 (EST)
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: Linux-Audit Mailing List <linux-audit@redhat.com>
List-Id: linux-audit@redhat.com

All,

Has anyone considered allowing an includeConfig statement for
audit.rules (or auditd.conf if need be)?

The action would be to, at that point in the parse (or the end of the
file, if auditd.conf holds the directive), open the nominated directory
and any files within, and parse them.

The idea is to allow for localization of audit. At an enterprise level
one would deploy the common, corporate set of rules
in /etc/audit/audit.rules. Should a local system need additional rules
such as tailored file watches, workstation or capability specific
monitoring, these could appear in files in the includeConfig directory.
That way, distribution mechanisms such as puppet, rpm satellite server,
apt repositories, etc can maintain the corporate set of rules without
changing localized configurations on updates.

I'm happy to author this.

Regards
Burn Alting