Re: Watching over non-existent folder to maintain a generic audit.rules file

On Tue, 2015-07-28 at 15:23 -0400, Steve Grubb wrote: > On Tuesday, July 28, 2015 05:26:18 PM Florian Crouzat wrote: >> Unfortunately, I do not only watch over system-related files and folders >> but also applicative ones (eg custom path where some private keys are >> stored, etc) .. >> My problem is that these folders do not exists on all hosts thus making >> it impossible to write a generic audit.rules files. > > What kernel are you using? And user space package? > > >> As I said, I have thousands of hosts and I can't imagine deploying >> different files on every hosts depending on the profile of the host. >> I know puppet could help me for this kind of stuff but I don't have it >> yet and even though, it would be difficult to configure. > > As of the 2.3 user space release, there is a utility, augenrules which takes > files in /etc/audit/rules.d/ and compiles them into an audit.rules file. So, it > would be possible for you to package up some rules for bind and install them > when you install bind and have your package install a > /etc/audit/rules.d/bind.rules file. You can have a base config, and then one for > each kind of daemon or role that the machine serves. > > >> How do you guys usually workaround this issue ? I'm pretty sure I'm not >> the first one wanting to deploy a generic hardening across many hosts >> (but maybe I'm the only one using auditd to watch over something else >> than pure system-related stuff? > > Others can chime in here. As Steve suggests, you should base you efforts around augenrules ... that why it was written. If you have a project that delivers a new capability, then part of the security element of it's transition to operations would be to have the project identify the sensitive files and have the system administrators deploy project specific .rules files in /etc/audit/rules.d to monitor them. If you have pre 2.3 audit user space deployments, then it is not difficult to deploy your own augenrules setup, but don't deploy it in the 'production' locations ... it's a bitch to remove when a 2.3 audit user space upgrade comes ... lots of rpm clashes. A word to the wise on file watches. If you have a capability who's 'service/process' continually accesses configuration files you will typically mask this out by having the service start under the init.d regime at boot time and configure auditd to not monitor the 'unset' auid. The problem comes when a sustainment staff member, elevates privilege, and restarts the service. At this, all file accesses by the service/process will be attributed to the sustainment staff members uid, not the 'unset' user. This appears to have been addressed by systemd, so if your Linux release supports systemd, and you configure your application to use it appropriately, it will not have the problem. There are workarounds for the init.d based service regime, but that will have to be a separate post if ane are interested.