configuration for busy docker host

[Steve Grubb]

On Wednesday, August 22, 2018 7:40:56 AM EDT Frederik Bosch wrote:
> Hi Steve,
> 
> Thank you very much for your reply and your suggestion. I appreciate
> that. The summary looks as follows.
> 
> 
> Key Summary Report
> ===========================
> total  key
> ===========================
> 63164  tmp
> 16060  docker
> 7206  delete
> 6007  admin_user_home
> 2760  auditlog
> 1595  specialfiles
> 675  perm_mod
> 69  systemd
> 54  systemd_tools
> 36  init
> 15  sshd
> 12  cron
> 5  login
> 5  actions
> 4  access
> 3  privileged
> 1  audit_rules_networkconfig_modification
> 
> 
> Now I wonder why to watch /tmp and /var/tmp.

This can be a staging ground for exploits. However, if they are mounted with 
the noexec option, they should be harmless. Also, the whole section titled:

# Capture all failures to access on critical elements

really is not necessary. Do you really need to know an open failed because of 
ENOENT? For example, every time a program is executed, ld.so tries to open 3 
or 4 nonexisting files. This is not needed for security purposes and is 
normal system activity. The only time things matter is when you fail to open 
for permissions.

About the docker section...why do you need to know all reads of those files? 
I'm not sure of the reason you'd want that information.

-Steve

> As it seems, these cause
> most entries in the logs. Could you think of any reason why that would
> be? I have also asked this question to the owner of the package. I will
> reduce the number of delete calls to specific locations and disable
> watches for /home as they seem to be inappropriate for my use case.
> 
> Regards,
> Frederik
> 
> On 20-08-18 19:48, Steve Grubb wrote:
> > On Monday, August 20, 2018 5:56:04 AM EDT Frederik Bosch wrote:
> >> As I have not found a location anywhere else on the web, I am sending my
> >> question to this list. I have an Ubuntu 18.04 machine with auditd and it
> >> acts as a Docker Host machine. I have hardened the system via this
> >> package: https://github.com/konstruktoid/hardening which installs auditd
> >> with the configuration to be found here:
> >> https://github.com/konstruktoid/hardening/blob/master/misc/audit.rules.
> > 
> > These rules could be improved upon by condensing:
> > 
> > # File deletions
> > # Capture all unauthorized file accesses
> > # Capture all failures to access on critical elements
> > # Permissions
> > 
> > down to 2 rules in each, 4 for the second one. That, however, is not the
> > actual problem. My guess is that it is capturing way more information
> > than is necessary.
> > 
> >> The problems I have are related to the directives -f and -b. The
> >> hardening package uses -b 8192 and -f 2. That results in a kernel panic
> >> very quickly because of audit backlog limit exceeded, and that causes a
> >> reboot of the system. Now I wonder what a good configuration would be. I
> >> started reading on the subject and read that -f 2 is probably the best
> >> for security reasons. However, I do not want to have a system that
> >> panics very quickly and reboots.
> > 
> > I'd say that you need to run:
> > 
> > aureport --start today --key --summary
> > 
> > and see what rule is triggering all the events. Do you really want all
> > deletes? Or just deletes in a specific directory? Do you really want to
> > know that a user changed dir permissions on a file in their homedir?
> > 
> >> Should I simply increase the backlog to much higher numbers? Or should I
> >> change -f to not cause a kernel panic? Or am I missing something and
> >> should I change some other configuration? Thanks for your help.
> > 
> > For the moment change -f not to cause a kernel panic. I think the rules
> > are probably too aggressive.
> > 
> > -Steve