Enable auditd and config it according to CIS DIL Benchmark

[timstoop]

This is a large patch that adds an additional module to fulfill the CIS DIL Benchmark chapter 4 requirements. These are mostly level 2 requirements.

The deployment is optional and only tested on Debian Stretch, but I suspect it'll work with only small changes on other OSes as well. If people can let me know, I will happily incorporate those changes as well.

Although you should probably check the options, one thing is important to note: According to the CIS DIL Benchmark 4.1.1.3 auditd should not rotate or throw away old logs, which is in most cases not helpful and can crash your machine if the disk becomes full due to this. So I've made the default to be rotate, so old logs are rotated away. You are still responsible for sending the logs to a remote log aggregation server before they are removed.

I know this is a large one, but I hope to get this incorporated, as it's pretty straight forward.

[artem-sidorenko]

@timstoop thanks for this PR!

I think we should port this one to chef/ansible too. For chef there is a PR open (dev-sec/chef-os-hardening#191) already for a while (something there went wrong with reintegration merges). However I think this puppet PR provides much more detailed implementation, so it make sense to take this one as a source for porting. @mcgege @atomic111 @chris-rock opinions?

[timstoop]

Judging from the other requests at other PRs, I assume you want enable_auditd = false to remove all the changes. Should that also purge the package?

[mcgege]

@timstoop Yep, I think this would be helpful - not just for me ;-)
@artem-sidorenko How should we proceed here? Honestly I don't know how to test this ...

[chris-rock]

That is great work. Am a bit hesitant in taking the direction to implement a specific benchmark, we made a lot of references in this PR to CIS benchmark. Instead, I think we should more think in components, eg. auditd. All properties should be named around that. Its okay if the default values match the CIS recommendation though. This allows the hardening cookbook to fulfill multiple benchmarks. Would love to hear what you think.

[timstoop]

@mcgege Regarding testing, the inspec rules already check all of these controls: https://github.com/dev-sec/cis-dil-benchmark I don't really know of another way to test aside from having the system perform actions and checking if they actually end up in the log, which would be a huge amount of work, really.
@chris-rock I'm not married with those descriptions, they were just the easiest way for me to implement this and keep track of what I was doing. For me, all work I'll provide will be based on CIS stuff as that's what the company requires, but I'm happy to have those descriptions changed. Assuming someone is willing to provide the alternative descriptions! Would it be possible to accept this PR and create an issue requesting someone to rewrite those descriptions? Or if you're willing, simply provide the PR yourself, I'm happy to review it.

[timstoop]

I don't revert the actual file changes, as purging the package should remove all left over config anyway. Let me know if you prefer me to remove them anyway.

[mcgege]

@timstoop What should we do about this pr?

[mcgege]

Please re-open if you'll continue on this