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

On 07/29/2015 12:39 AM, Burn Alting wrote: > 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. > Hey, Thanks for the answers. I have both up-to-date EL6 and EL7 hosts with latests kernel available in base channel so I think it means I have >=2.3 auditd package. I'll definitely have a look into augenrules and how to use it. I'll probably come back at you with mores questions after that. Florian