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

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

[Burn Alting]

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

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

[Steve Grubb]

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

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

[Burn Alting]

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
	b. If not empty, it will concatenate all files of the form xxx.rules,
stripping comments and blank lines. The xxx will determine sort.
	c. If the resultant file is not empty, it can
replace /etc/audit/audit.rules.

Rgds



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
> 

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

[Steve Grubb]

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

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

[Boyce, Kevin P. (AS)]

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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: 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@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

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

[Burn Alting]

[-- Attachment #1: Type: text/plain, Size: 8795 bytes --]

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


[-- Attachment #2: audit.patch --]
[-- Type: text/x-patch, Size: 18136 bytes --]

diff -rupN audit-2.2.3/audit.spec audit-2.2.3_burn1/audit.spec
--- audit-2.2.3/audit.spec	2013-03-20 07:31:20.000000000 +1100
+++ audit-2.2.3_burn1/audit.spec	2013-04-07 20:52:51.663230537 +1000
@@ -10,7 +10,7 @@
 Summary: User space tools for 2.6 kernel auditing
 Name: audit
 Version: 2.2.3
-Release: 1
+Release: 2
 License: GPLv2+
 Group: System Environment/Daemons
 URL: http://people.redhat.com/sgrubb/audit/
@@ -218,6 +218,7 @@ fi
 %attr(644,root,root) %{_mandir}/man8/aulast.8.gz
 %attr(644,root,root) %{_mandir}/man8/aulastlog.8.gz
 %attr(644,root,root) %{_mandir}/man8/auvirt.8.gz
+%attr(644,root,root) %{_mandir}/man8/augenrules.8.gz
 %attr(644,root,root) %{_mandir}/man8/ausyscall.8.gz
 %attr(644,root,root) %{_mandir}/man7/audit.rules.7.gz
 %attr(644,root,root) %{_mandir}/man5/auditd.conf.5.gz
@@ -229,6 +230,7 @@ fi
 %attr(755,root,root) /sbin/aureport
 %attr(750,root,root) /sbin/autrace
 %attr(750,root,root) /sbin/audispd
+%attr(750,root,root) /sbin/augenrules
 %attr(755,root,root) %{_bindir}/aulast
 %attr(755,root,root) %{_bindir}/aulastlog
 %attr(755,root,root) %{_bindir}/ausyscall
@@ -241,10 +243,11 @@ fi
 %endif
 %attr(750,root,root) %dir %{_var}/log/audit
 %attr(750,root,root) %dir /etc/audit
+%attr(750,root,root) %dir /etc/audit/rules.d
 %attr(750,root,root) %dir /etc/audisp
 %attr(750,root,root) %dir /etc/audisp/plugins.d
 %config(noreplace) %attr(640,root,root) /etc/audit/auditd.conf
-%config(noreplace) %attr(640,root,root) /etc/audit/audit.rules
+%config(noreplace) %attr(640,root,root) /etc/audit/rules.d/audit.rules
 %config(noreplace) %attr(640,root,root) /etc/audisp/audispd.conf
 %config(noreplace) %attr(640,root,root) /etc/audisp/plugins.d/af_unix.conf
 %config(noreplace) %attr(640,root,root) /etc/audisp/plugins.d/syslog.conf
diff -rupN audit-2.2.3/docs/augenrules.8 audit-2.2.3_burn1/docs/augenrules.8
--- audit-2.2.3/docs/augenrules.8	1970-01-01 10:00:00.000000000 +1000
+++ audit-2.2.3_burn1/docs/augenrules.8	2013-04-07 19:15:26.692978885 +1000
@@ -0,0 +1,36 @@
+.TH AUGENRULES: "8" "Apr 2013" "Red Hat" "System Administration Utilities"
+.SH NAME
+augenrules \- a script that merges component audit rule files
+.SH SYNOPSIS
+.B augenrules
+.RI [ options ]
+.SH DESCRIPTION
+\fBaugenrules\fP is a script that merges all component audit rules files,
+found in the audit rules directory, \fI/etc/audit/rules.d\fP, placing the
+merged file in \fI/etc/audit/audit.rules\fP. Component audit rule files, must
+end in \fI.rules\fP in order to be processed. All other files in
+\fI/etc/audit/rules.d\fP are ignored.
+.P
+The files are concatenated in order, based on their natural sort (see -v option of ls(1)) and striped of empty and comment (#) lines.
+.P
+The last processed -\fID\fP directive without an option, if present, is always
+emitted as the first line in the resultant file. Those with an option are
+replicated in place.
+The last processed -\fIb\fP directive, if present, is always
+emitted as the second line in the resultant file.
+The last processed -\fIf\fP directive, if present, is always
+emitted as the third line in the resultant file.
+The last processed -\fIe\fP directive, if present, is always
+emitted as the last line in the resultant file.
+.P
+The generated file is only copied to \fI/etc/audit/rules.d\fP, if it differs.
+.SH OPTIONS
+.TP
+.BR none
+
+.SH FILES
+/etc/audit/rules.d/
+/etc/audit/audit.rules
+.SH "SEE ALSO"
+.BR audit.rules (8),
+.BR auditd (8).
diff -rupN audit-2.2.3/docs/Makefile.am audit-2.2.3_burn1/docs/Makefile.am
--- audit-2.2.3/docs/Makefile.am	2013-03-20 07:31:12.000000000 +1100
+++ audit-2.2.3_burn1/docs/Makefile.am	2013-04-07 16:35:36.040595035 +1000
@@ -54,5 +54,6 @@ ausearch_clear.3 \
 ausearch_next_event.3 ausearch_set_stop.3 \
 autrace.8 get_auditfail_action.3 set_aumessage_mode.3 \
 audispd.8 audispd.conf.5 audispd-zos-remote.8 libaudit.conf.5 \
+augenrules.8 \
 zos-remote.conf.5 
 
diff -rupN audit-2.2.3/docs/Makefile.in audit-2.2.3_burn1/docs/Makefile.in
--- audit-2.2.3/docs/Makefile.in	2013-03-20 07:32:00.000000000 +1100
+++ audit-2.2.3_burn1/docs/Makefile.in	2013-04-07 20:53:56.678501579 +1000
@@ -290,6 +290,7 @@ ausearch_clear.3 \
 ausearch_next_event.3 ausearch_set_stop.3 \
 autrace.8 get_auditfail_action.3 set_aumessage_mode.3 \
 audispd.8 audispd.conf.5 audispd-zos-remote.8 libaudit.conf.5 \
+augenrules.8 \
 zos-remote.conf.5 
 
 all: all-am
diff -rupN audit-2.2.3/init.d/auditd.init audit-2.2.3_burn1/init.d/auditd.init
--- audit-2.2.3/init.d/auditd.init	2013-03-20 07:30:07.000000000 +1100
+++ audit-2.2.3_burn1/init.d/auditd.init	2013-04-07 16:39:44.654719851 +1000
@@ -71,6 +71,8 @@ start(){
 	echo
 	if test $RETVAL = 0 ; then
 		touch /var/lock/subsys/auditd
+		# Prepare the default rules
+		test -d /etc/audit/rules.d && /sbin/augenrules
 		# Load the default rules
 		test -f /etc/audit/audit.rules && /sbin/auditctl -R /etc/audit/audit.rules >/dev/null
 	fi
@@ -102,6 +104,8 @@ stop(){
 reload(){
 	test -f /etc/audit/auditd.conf  || exit 6
 	echo -n $"Reloading configuration: "	
+	# Prepare the default rules
+	test -d /etc/audit/rules.d && /sbin/augenrules
 	killproc $prog -HUP
 	RETVAL=$?
 	echo
diff -rupN audit-2.2.3/init.d/auditd.service audit-2.2.3_burn1/init.d/auditd.service
--- audit-2.2.3/init.d/auditd.service	2013-03-20 07:30:07.000000000 +1100
+++ audit-2.2.3_burn1/init.d/auditd.service	2013-04-07 16:40:17.919162224 +1000
@@ -7,6 +7,7 @@ Before=sysinit.target shutdown.target
 
 [Service]
 ExecStart=/sbin/auditd -n
+ExecStartPost=/sbin/augenrules
 ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
 
 [Install]
diff -rupN audit-2.2.3/init.d/augenrules audit-2.2.3_burn1/init.d/augenrules
--- audit-2.2.3/init.d/augenrules	1970-01-01 10:00:00.000000000 +1000
+++ audit-2.2.3_burn1/init.d/augenrules	2013-04-07 20:51:35.027485205 +1000
@@ -0,0 +1,96 @@
+#!/bin/bash
+
+# Script to concatenate rules files found in a base audit rules directory
+# to form a single /etc/audit/audit.rules file suitable for loading into
+# the Linux audit system
+
+# When forming the interim rules file, both empty lines and comment
+# lines (starting with # or <whitespace>#) are stripped as the source files
+# are processed.
+#
+# Having formed the interim rules file, the script checks if the file is empty
+# or is identical to the existing /etc/audit/audit.rules and if either of
+# these cases are true, it does not replace the existing file
+#
+
+# Variables
+#
+# DestinationFile:
+#   Destination rules file
+# SourceRulesDir:
+#   Directory location to find component rule files
+# TmpRules:
+#   Temporary interim rules file
+# ASuffix:
+#   Suffix for previous audit.rules file if this script replaces it.
+#   The file is left in the destination directory with suffix with $ASuffix
+
+DestinationFile=/etc/audit/audit.rules
+SourceRulesDir=/etc/audit/rules.d
+TmpRules=/tmp/rules.$$
+ASuffix="prev"
+
+
+# Delete the interim file on faults
+trap 'rm -f ${TmpRules}; exit 1' 1 2 3 13 15
+
+# Check environment
+if [ ! -d ${SourceRulesDir} ]; then
+	echo "$0: No rules directory - ${SourceRulesDir}"
+	exit 1
+fi
+
+# Create the interim rules file ensuring its access modes protect it
+# from normal users and strip empty lines and comment lines. We also ensure
+#   - the last processed -D directive without an option is emitted as the first
+#     line. -D directives with options are left in place
+#   - the last processed -b directory is emitted as the second line
+#   - the last processed -f directory is emitted as the third line
+#   - the last processed -e directive is emitted as the last line
+umask 0137
+for rules in $(/bin/ls -1v ${SourceRulesDir} | grep ".rules$") ; do
+	cat ${SourceRulesDir}/${rules}
+done | awk '\
+BEGIN   {
+        minus_e = "";
+        minus_D = "";
+        minus_f = "";
+        minus_b = "";
+        rest = 0;
+} {
+        if (length($0) < 1) { next; }
+        if (match($0, "^\\s*#")) { next; }
+        if (match($0, "^\\s*-e")) { minus_e = $0; next; }
+        if (match($0, "^\\s*-D\\s*$")) { minus_D = $0; next; }
+        if (match($0, "^\\s*-f")) { minus_f = $0; next; }
+        if (match($0, "^\\s*-b")) { minus_b = $0; next; }
+        rules[rest++] = $0;
+}
+END     {
+        printf "%s\n%s\n%s\n", minus_D, minus_b, minus_f;
+        for (i = 0; i < rest; i++) { printf "%s\n", rules[i]; }
+        printf "%s\n", minus_e;
+}' > ${TmpRules}
+
+# If empty then quit
+if [ ! -s ${TmpRules} ]; then
+	echo "$0: No rules"
+	rm -f ${TmpRules}
+	exit 0
+fi
+
+# If the same then quit
+cmp -s ${TmpRules} ${DestinationFile} > /dev/null 2>&1
+if [ $? -eq 0 ]; then
+	echo "$0: No change"
+	rm -f ${TmpRules}
+	exit 0
+fi
+
+# Otherwise we install the new file
+if [ -f ${DestinationFile} ]; then
+	cp ${DestinationFile} ${DestinationFile}.prev
+fi
+mv ${TmpRules} ${DestinationFile}
+
+exit 0
diff -rupN audit-2.2.3/init.d/Makefile.am audit-2.2.3_burn1/init.d/Makefile.am
--- audit-2.2.3/init.d/Makefile.am	2013-03-20 07:30:07.000000000 +1100
+++ audit-2.2.3_burn1/init.d/Makefile.am	2013-04-07 20:28:07.196119948 +1000
@@ -22,7 +22,7 @@
 
 CONFIG_CLEAN_FILES = *.rej *.orig
 EXTRA_DIST = auditd.init auditd.service auditd.sysconfig auditd.conf \
-	audit.rules auditd.cron libaudit.conf audispd.conf
+	audit.rules auditd.cron libaudit.conf audispd.conf augenrules
 libconfig = libaudit.conf
 dispconfig = audispd.conf
 dispconfigdir = $(sysconfdir)/audisp
@@ -34,7 +34,10 @@ sysconfigdir = $(sysconfdir)/sysconfig
 endif
 
 auditdir = $(sysconfdir)/audit
-dist_audit_DATA = auditd.conf audit.rules
+auditrdir = $(auditdir)/rules.d
+dist_audit_DATA = auditd.conf
+dist_auditr_DATA = audit.rules
+sbin_SCRIPTS = augenrules
 
 install-data-hook:
 	$(INSTALL_DATA) -D -m 640 ${srcdir}/${dispconfig} ${DESTDIR}${dispconfigdir}
@@ -51,6 +54,8 @@ if ENABLE_SYSTEMD
 else
 	$(INSTALL_SCRIPT) -D ${srcdir}/auditd.init ${DESTDIR}${initdir}/auditd
 endif
+	chmod 0750 $(DESTDIR)$(sbindir)/augenrules
+
 
 uninstall-hook:
 	rm ${DESTDIR}${dispconfigdir}/${dispconfig}
diff -rupN audit-2.2.3/init.d/Makefile.in audit-2.2.3_burn1/init.d/Makefile.in
--- audit-2.2.3/init.d/Makefile.in	2013-03-20 07:32:00.000000000 +1100
+++ audit-2.2.3_burn1/init.d/Makefile.in	2013-04-07 20:53:56.772513541 +1000
@@ -36,6 +36,7 @@
 #   Steve Grubb <sgrubb@redhat.com>
 #
 
+
 VPATH = @srcdir@
 am__make_dryrun = \
   { \
@@ -74,8 +75,8 @@ build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
 subdir = init.d
-DIST_COMMON = $(dist_audit_DATA) $(srcdir)/Makefile.am \
-	$(srcdir)/Makefile.in
+DIST_COMMON = $(dist_audit_DATA) $(dist_auditr_DATA) \
+	$(srcdir)/Makefile.am $(srcdir)/Makefile.in
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 am__aclocal_m4_deps = $(top_srcdir)/src/libev/libev.m4 \
 	$(top_srcdir)/configure.ac
@@ -84,13 +85,6 @@ am__configure_deps = $(am__aclocal_m4_de
 mkinstalldirs = $(install_sh) -d
 CONFIG_HEADER = $(top_builddir)/config.h
 CONFIG_CLEAN_VPATH_FILES =
-SOURCES =
-DIST_SOURCES =
-am__can_run_installinfo = \
-  case $$AM_UPDATE_INFO_DIR in \
-    n|no|NO) false;; \
-    *) (install-info --version) >/dev/null 2>&1;; \
-  esac
 am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
 am__vpath_adj = case $$p in \
     $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
@@ -118,8 +112,17 @@ am__uninstall_files_from_dir = { \
     || { echo " ( cd '$$dir' && rm -f" $$files ")"; \
          $(am__cd) "$$dir" && rm -f $$files; }; \
   }
-am__installdirs = "$(DESTDIR)$(auditdir)"
-DATA = $(dist_audit_DATA)
+am__installdirs = "$(DESTDIR)$(sbindir)" "$(DESTDIR)$(auditdir)" \
+	"$(DESTDIR)$(auditrdir)"
+SCRIPTS = $(sbin_SCRIPTS)
+SOURCES =
+DIST_SOURCES =
+am__can_run_installinfo = \
+  case $$AM_UPDATE_INFO_DIR in \
+    n|no|NO) false;; \
+    *) (install-info --version) >/dev/null 2>&1;; \
+  esac
+DATA = $(dist_audit_DATA) $(dist_auditr_DATA)
 DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
 ACLOCAL = @ACLOCAL@
 AMTAR = @AMTAR@
@@ -256,7 +259,7 @@ top_builddir = @top_builddir@
 top_srcdir = @top_srcdir@
 CONFIG_CLEAN_FILES = *.rej *.orig
 EXTRA_DIST = auditd.init auditd.service auditd.sysconfig auditd.conf \
-	audit.rules auditd.cron libaudit.conf audispd.conf
+	audit.rules auditd.cron libaudit.conf audispd.conf augenrules
 
 libconfig = libaudit.conf
 dispconfig = audispd.conf
@@ -265,7 +268,10 @@ dispconfigdir = $(sysconfdir)/audisp
 @ENABLE_SYSTEMD_TRUE@initdir = /usr/lib/systemd/system
 @ENABLE_SYSTEMD_FALSE@sysconfigdir = $(sysconfdir)/sysconfig
 auditdir = $(sysconfdir)/audit
-dist_audit_DATA = auditd.conf audit.rules
+auditrdir = $(auditdir)/rules.d
+dist_audit_DATA = auditd.conf
+dist_auditr_DATA = audit.rules
+sbin_SCRIPTS = augenrules
 all: all-am
 
 .SUFFIXES:
@@ -299,6 +305,41 @@ $(top_srcdir)/configure:  $(am__configur
 $(ACLOCAL_M4):  $(am__aclocal_m4_deps)
 	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
 $(am__aclocal_m4_deps):
+install-sbinSCRIPTS: $(sbin_SCRIPTS)
+	@$(NORMAL_INSTALL)
+	@list='$(sbin_SCRIPTS)'; test -n "$(sbindir)" || list=; \
+	if test -n "$$list"; then \
+	  echo " $(MKDIR_P) '$(DESTDIR)$(sbindir)'"; \
+	  $(MKDIR_P) "$(DESTDIR)$(sbindir)" || exit 1; \
+	fi; \
+	for p in $$list; do \
+	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
+	  if test -f "$$d$$p"; then echo "$$d$$p"; echo "$$p"; else :; fi; \
+	done | \
+	sed -e 'p;s,.*/,,;n' \
+	    -e 'h;s|.*|.|' \
+	    -e 'p;x;s,.*/,,;$(transform)' | sed 'N;N;N;s,\n, ,g' | \
+	$(AWK) 'BEGIN { files["."] = ""; dirs["."] = 1; } \
+	  { d=$$3; if (dirs[d] != 1) { print "d", d; dirs[d] = 1 } \
+	    if ($$2 == $$4) { files[d] = files[d] " " $$1; \
+	      if (++n[d] == $(am__install_max)) { \
+		print "f", d, files[d]; n[d] = 0; files[d] = "" } } \
+	    else { print "f", d "/" $$4, $$1 } } \
+	  END { for (d in files) print "f", d, files[d] }' | \
+	while read type dir files; do \
+	     if test "$$dir" = .; then dir=; else dir=/$$dir; fi; \
+	     test -z "$$files" || { \
+	       echo " $(INSTALL_SCRIPT) $$files '$(DESTDIR)$(sbindir)$$dir'"; \
+	       $(INSTALL_SCRIPT) $$files "$(DESTDIR)$(sbindir)$$dir" || exit $$?; \
+	     } \
+	; done
+
+uninstall-sbinSCRIPTS:
+	@$(NORMAL_UNINSTALL)
+	@list='$(sbin_SCRIPTS)'; test -n "$(sbindir)" || exit 0; \
+	files=`for p in $$list; do echo "$$p"; done | \
+	       sed -e 's,.*/,,;$(transform)'`; \
+	dir='$(DESTDIR)$(sbindir)'; $(am__uninstall_files_from_dir)
 
 mostlyclean-libtool:
 	-rm -f *.lo
@@ -326,6 +367,27 @@ uninstall-dist_auditDATA:
 	@list='$(dist_audit_DATA)'; test -n "$(auditdir)" || list=; \
 	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
 	dir='$(DESTDIR)$(auditdir)'; $(am__uninstall_files_from_dir)
+install-dist_auditrDATA: $(dist_auditr_DATA)
+	@$(NORMAL_INSTALL)
+	@list='$(dist_auditr_DATA)'; test -n "$(auditrdir)" || list=; \
+	if test -n "$$list"; then \
+	  echo " $(MKDIR_P) '$(DESTDIR)$(auditrdir)'"; \
+	  $(MKDIR_P) "$(DESTDIR)$(auditrdir)" || exit 1; \
+	fi; \
+	for p in $$list; do \
+	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
+	  echo "$$d$$p"; \
+	done | $(am__base_list) | \
+	while read files; do \
+	  echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(auditrdir)'"; \
+	  $(INSTALL_DATA) $$files "$(DESTDIR)$(auditrdir)" || exit $$?; \
+	done
+
+uninstall-dist_auditrDATA:
+	@$(NORMAL_UNINSTALL)
+	@list='$(dist_auditr_DATA)'; test -n "$(auditrdir)" || list=; \
+	files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
+	dir='$(DESTDIR)$(auditrdir)'; $(am__uninstall_files_from_dir)
 tags: TAGS
 TAGS:
 
@@ -367,9 +429,9 @@ distdir: $(DISTFILES)
 	done
 check-am: all-am
 check: check-am
-all-am: Makefile $(DATA)
+all-am: Makefile $(SCRIPTS) $(DATA)
 installdirs:
-	for dir in "$(DESTDIR)$(auditdir)"; do \
+	for dir in "$(DESTDIR)$(sbindir)" "$(DESTDIR)$(auditdir)" "$(DESTDIR)$(auditrdir)"; do \
 	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
 	done
 install: install-am
@@ -422,14 +484,14 @@ info: info-am
 
 info-am:
 
-install-data-am: install-dist_auditDATA
+install-data-am: install-dist_auditDATA install-dist_auditrDATA
 	@$(NORMAL_INSTALL)
 	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
 install-dvi: install-dvi-am
 
 install-dvi-am:
 
-install-exec-am:
+install-exec-am: install-sbinSCRIPTS
 	@$(NORMAL_INSTALL)
 	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
 install-html: install-html-am
@@ -468,7 +530,8 @@ ps: ps-am
 
 ps-am:
 
-uninstall-am: uninstall-dist_auditDATA
+uninstall-am: uninstall-dist_auditDATA uninstall-dist_auditrDATA \
+	uninstall-sbinSCRIPTS
 	@$(NORMAL_INSTALL)
 	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
 .MAKE: install-am install-data-am install-exec-am install-strip \
@@ -478,14 +541,16 @@ uninstall-am: uninstall-dist_auditDATA
 	distclean distclean-generic distclean-libtool distdir dvi \
 	dvi-am html html-am info info-am install install-am \
 	install-data install-data-am install-data-hook \
-	install-dist_auditDATA install-dvi install-dvi-am install-exec \
-	install-exec-am install-exec-hook install-html install-html-am \
-	install-info install-info-am install-man install-pdf \
-	install-pdf-am install-ps install-ps-am install-strip \
-	installcheck installcheck-am installdirs maintainer-clean \
+	install-dist_auditDATA install-dist_auditrDATA install-dvi \
+	install-dvi-am install-exec install-exec-am install-exec-hook \
+	install-html install-html-am install-info install-info-am \
+	install-man install-pdf install-pdf-am install-ps \
+	install-ps-am install-sbinSCRIPTS install-strip installcheck \
+	installcheck-am installdirs maintainer-clean \
 	maintainer-clean-generic mostlyclean mostlyclean-generic \
 	mostlyclean-libtool pdf pdf-am ps ps-am uninstall uninstall-am \
-	uninstall-dist_auditDATA uninstall-hook
+	uninstall-dist_auditDATA uninstall-dist_auditrDATA \
+	uninstall-hook uninstall-sbinSCRIPTS
 
 
 install-data-hook:
@@ -497,6 +562,7 @@ install-exec-hook:
 @ENABLE_SYSTEMD_TRUE@	mkdir -p ${DESTDIR}${initdir}
 @ENABLE_SYSTEMD_TRUE@	$(INSTALL_SCRIPT) -D -m 640 ${srcdir}/auditd.service ${DESTDIR}${initdir}
 @ENABLE_SYSTEMD_FALSE@	$(INSTALL_SCRIPT) -D ${srcdir}/auditd.init ${DESTDIR}${initdir}/auditd
+	chmod 0750 $(DESTDIR)$(sbindir)/augenrules
 
 uninstall-hook:
 	rm ${DESTDIR}${dispconfigdir}/${dispconfig}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

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

[Steve Grubb]

On Sunday, April 07, 2013 09:16:46 PM Burn Alting wrote:
> Please find attached my patch on this matter.

Thanks for taking this on.


> 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.

One issue that I am concerned about is how this feature gets added to existing 
setups. For example, someone may have a /etc/audit/audit.rules file, then 
upgrade and if there is an empty shipped policy in /etc/audit/audit.d, it will 
erase the installed rules.

So, I think we should have an /etc/sysconfig option that enables augenrules so 
that an admin has to do something to turn this on thus preventing automatic 
deletion of rules.

For systemd, I think we want to ship the service file with the ExecStartPost 
line commented out which then requires an admin to take an action to enable. 
We really don't want unexpected things to happen during an upgrade.
 

> The generated file ensures
>  - the last processed -D directive without an option, if present, is
> emitted  on the first line

In generating rules, we should always start with -D. I can't imagine not 
having it.

>  - the last processed -b directive, if present, is emitted on the second
> line

We probably want the largest in all the processed files.


>  - the last processed -f directive, if present, is emitted on the third
> line

We probably want the largest here, too.

>  - the last processed -e directive, if present, is emitted as the last
> line.

I was thinking that if any of the files try to ask for it to be immutable, then 
it should go at the end.

> The file, /etc/audit/audit.rules, is only updated if it has changed.
> > https://www.redhat.com/mailman/listinfo/linux-audit

That is great, because any write could be an auditable event. At some point we 
also might want to add support for a --check option which does everything 
except overwrite the final rules.

-Steve

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

[Burn Alting]

Steve,

I will make the changes on the weekend and re-submit.

Rgds
On Thu, 2013-04-18 at 09:49 -0400, Steve Grubb wrote:
> On Sunday, April 07, 2013 09:16:46 PM Burn Alting wrote:
> > Please find attached my patch on this matter.
> 
> Thanks for taking this on.
> 
> 
> > 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.
> 
> One issue that I am concerned about is how this feature gets added to existing 
> setups. For example, someone may have a /etc/audit/audit.rules file, then 
> upgrade and if there is an empty shipped policy in /etc/audit/audit.d, it will 
> erase the installed rules.
> 
> So, I think we should have an /etc/sysconfig option that enables augenrules so 
> that an admin has to do something to turn this on thus preventing automatic 
> deletion of rules.
> 
> For systemd, I think we want to ship the service file with the ExecStartPost 
> line commented out which then requires an admin to take an action to enable. 
> We really don't want unexpected things to happen during an upgrade.
>  
> 
> > The generated file ensures
> >  - the last processed -D directive without an option, if present, is
> > emitted  on the first line
> 
> In generating rules, we should always start with -D. I can't imagine not 
> having it.
> 
> >  - the last processed -b directive, if present, is emitted on the second
> > line
> 
> We probably want the largest in all the processed files.
> 
> 
> >  - the last processed -f directive, if present, is emitted on the third
> > line
> 
> We probably want the largest here, too.
> 
> >  - the last processed -e directive, if present, is emitted as the last
> > line.
> 
> I was thinking that if any of the files try to ask for it to be immutable, then 
> it should go at the end.
> 
> > The file, /etc/audit/audit.rules, is only updated if it has changed.
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> 
> That is great, because any write could be an auditable event. At some point we 
> also might want to add support for a --check option which does everything 
> except overwrite the final rules.
> 
> -Steve

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

[Steve Grubb]

On Friday, April 19, 2013 07:23:53 AM Burn Alting wrote:
> Steve,
> 
> I will make the changes on the weekend and re-submit.

No need, I can take care of it. I just wanted to air the concerns and make 
sure everyone was in agreement or maybe someone saw another way to solve the 
problem. I will merge the code today with a couple changes. I am trying to get 
the audit package ready for another release sometime in the next couple days.

So, if anyone has any other bugs...now's a good time to air them. :-)

-Steve


> On Thu, 2013-04-18 at 09:49 -0400, Steve Grubb wrote:
> > On Sunday, April 07, 2013 09:16:46 PM Burn Alting wrote:
> > > Please find attached my patch on this matter.
> > 
> > Thanks for taking this on.
> > 
> > > 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.
> > 
> > One issue that I am concerned about is how this feature gets added to
> > existing setups. For example, someone may have a /etc/audit/audit.rules
> > file, then upgrade and if there is an empty shipped policy in
> > /etc/audit/audit.d, it will erase the installed rules.
> > 
> > So, I think we should have an /etc/sysconfig option that enables
> > augenrules so that an admin has to do something to turn this on thus
> > preventing automatic deletion of rules.
> > 
> > For systemd, I think we want to ship the service file with the
> > ExecStartPost line commented out which then requires an admin to take an
> > action to enable. We really don't want unexpected things to happen during
> > an upgrade.> 
> > > The generated file ensures
> > > 
> > >  - the last processed -D directive without an option, if present, is
> > > 
> > > emitted  on the first line
> > 
> > In generating rules, we should always start with -D. I can't imagine not
> > having it.
> > 
> > >  - the last processed -b directive, if present, is emitted on the second
> > > 
> > > line
> > 
> > We probably want the largest in all the processed files.
> > 
> > >  - the last processed -f directive, if present, is emitted on the third
> > > 
> > > line
> > 
> > We probably want the largest here, too.
> > 
> > >  - the last processed -e directive, if present, is emitted as the last
> > > 
> > > line.
> > 
> > I was thinking that if any of the files try to ask for it to be immutable,
> > then it should go at the end.
> > 
> > > The file, /etc/audit/audit.rules, is only updated if it has changed.
> > > 
> > > > https://www.redhat.com/mailman/listinfo/linux-audit
> > 
> > That is great, because any write could be an auditable event. At some
> > point we also might want to add support for a --check option which does
> > everything except overwrite the final rules.
> > 
> > -Steve

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

[Steve Grubb]

On Friday, April 19, 2013 06:53:41 AM Steve Grubb wrote:
> On Friday, April 19, 2013 07:23:53 AM Burn Alting wrote:
> > Steve,
> > 
> > I will make the changes on the weekend and re-submit.
> 
> No need, I can take care of it. I just wanted to air the concerns and make
> sure everyone was in agreement or maybe someone saw another way to solve the
> problem. I will merge the code today with a couple changes. I am trying to
> get the audit package ready for another release sometime in the next couple
> days.

This patch is now applied to svn with some minor changes.

-Steve