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 > > [email protected] > > https://www.redhat.com/mailman/listinfo/linux-audit > > -- > Linux-audit mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
