On Wednesday, April 03, 2013 09:37:23 PM Burn Alting wrote: > Thanks for these comments Steve. > > I will come up with a solution based on option one. Perhaps along the > line of a script (to suit both auditd.init and auditd.service) that > a. Looks for a known directory, say /etc/audit/auditd.rules
I was thinking something like /etc/audit/rules.d/ or something ending in '.d' under the audit directory so that selinux labels are the same. > b. If not empty, it will concatenate all files of the form xxx.rules, > stripping comments and blank lines. The xxx will determine sort. Sure. I think some people prefix numbers to the name to help guide the ordering like udev. > c. If the resultant file is not empty, it can > replace /etc/audit/audit.rules. Sure. The question is should it do that always on start? What about reload? Should it replace it only if its changed? (writing to /etc/audit/audit.rules is an auditable event...we probably want to minimize that.) Thanks, -Steve > On Tue, 2013-04-02 at 14:03 -0400, Steve Grubb wrote: > > On Wednesday, March 27, 2013 08:38:07 PM Burn Alting wrote: > > > 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. > > > > Sorry for the late reply, been out a bit and am trying to catch up on > > email. > > > > Well...have you heard of SCAP? Its a whole framework for assessing the > > security posture of a system based on open standards to prevent vendor > > lockin. It can also allow for continuous monitoring, boot up attestation > > via TNC, patch management, and we are working on some basic level of > > remediation. > > > > More info about SCAP can be found at these sites: > > http://scap.nist.gov/ > > http://makingsecuritymeasurable.mitre.org/ > > > > We have an openscap project > > http://www.open-scap.org/ > > > > There is an SCAP Security Guide which will become a STIG: > > https://fedorahosted.org/scap-security-guide/ > > > > And its being integrated into various systems management tools. The reason > > I mention this is that currently there is no way that you could evaluate > > audit rules from an SCAP based tool with a decomposed set of audit rules. > > The OVAL interpreter is the limitation. It does not have any method of > > being able to smartly assemble the collective audit rules to assess if > > the system is in compliance. In the audit system, the order of rules > > matters and that is one of the problems OVAL would have to be specified > > and coded to understand. > > > > So with SCAP in mind, the options seem to be: > > > > 1) Build a rule compiler that assembles a master audit.rules file from > > sources but only 1 set of rules are loaded. > > 2) Request a change in OVAL 5.11 to support this kind of setup. Sometime > > around 2014 NIST should have it approved and content developers can use > > it. > > This means holding off the functionality a bit because we can't allow > > audit > > configurations that cannot be monitored. > > 3) ?? (Any other ideas) > > > > OVAL has limited capability for reading file formats. Changes in > > capability > > have a long lead time. Audit configuration is very important to be able to > > assess from SCAP. For example, the DISA STIG and USGCB would mandate it. I > > think someone is working on a DSS-PCI profile which would also include > > some > > form of audit rule tests. > > > > In my opinion, the ability to assess the audit system's compliance has to > > take SCAP into account and solutions to allow drop in audit rule > > additions ought to fit within those limitations. I would imagine the same > > set of people that care about audit rules are nearly the same set of > > people that care about SCAP. > > > > -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
