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

Burn Alting burn at swtf.dyndns.org
Sun Apr 7 11:16:46 UTC 2013 

All,

Please find attached my patch on this matter.

I essence, /etc/audit/audit.rules is now formed from files (.rules
suffixed) within /etc/audit/rules.d. The new script /sbin/augenrules is
executed by from either startup script,  /etc/init.d/auditd
or /usr/lib/systemd/system/auditd.service before calling auditctl.

The generated file ensures
 - the last processed -D directive without an option, if present, is
emitted  on the first line
 - the last processed -b directive, if present, is emitted on the second
line
 - the last processed -f directive, if present, is emitted on the third
line
 - the last processed -e directive, if present, is emitted as the last
line.

The file, /etc/audit/audit.rules, is only updated if it has changed.

Rgds
Burn

On Thu, 2013-04-04 at 07:19 +1100, Burn Alting wrote:
> 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
> 
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

-------------- next part --------------
A non-text attachment was scrubbed...
Name: audit.patch
Type: text/x-patch
Size: 18136 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20130407/0c586e34/attachment.bin>

More information about the Linux-audit mailing list