EXT :Re: Adding enterprise capability - an includeConfig directive for audit.rules?

[Burn Alting]

Steve,

I'll take your recommendations on board and, Kevin, I'll look at
Canonical's methods of file building. I'll also check the limitations in
the number of rules loadable which auditctl mentions. I believe, by
offering a rule building capability, we indirectly introduce a risk of
increasing the rule set size.

Kevin,

I think to incorporate your recommendations would be a contrib element
that can 'manage' a file in /etc/audit/rules.d. I'll take this into
consideration as I document the file nomenclature in the rules
directory. 

Will author all this on the weekend.

Rgds
Burn

On Wed, 2013-04-03 at 09:19 -0400, Boyce, Kevin P. (AS) wrote:
> I think this is a worthwhile effort. You might have a look at how the 
> Canonical folks do things like this, in particular the update-grub 
> script, uses a bunch of files in a ".d" directory and build the actual 
> config file (/boot/grub/grub.cfg).
> 
> On another note I will take the opportunity to introduce some feature 
> creep.  At one point I had written a cron script for my environment that 
> rebuilt the snare.conf file every week and restart the audit daemon.  
> Additionally, this script would take in a list of the names of packages 
> you were interested in auditing. For example passwd-0.77-4.el6_2.2 (by 
> name passwd) and wireshark-1.2.15-2.el6_2.1 (by name wireshark).  The 
> script would then query the package manager to see if it was installed.  
> If it is, it would list all files provided by the package, filter out 
> the executables from the libraries from the config files from the 
> documentation.  Then it would generate a rule for each type of file.  
> Config files and libraries were added to the rule list looking for 
> failure to write or change the file.  Executables would be added to the 
> rule list looking for success or failure to execute the file.
> 
> The reason for all of this was that in a large environment with many 
> users with root privilege you don't always know what software would be 
> installed on a system.  If at some point someone had added wireshark 
> (via rpm) to a system you know it will get audited after that.  The 
> other benefit is that it make the generation of rules sort of agnostic 
> with regard to the architecture of the system; the package manager 
> handles telling you the location of the files you are interested in for 
> any given package.
> 
> I don't know if this sort of thing has value to anyone else, but I 
> thought I'd throw it out there as a suggestion anyway.
> 
> Kevin
> 
> On 04/03/2013 07:42 AM, Steve Grubb wrote:
> > 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
> > Linux-audit at redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit