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
