Rsyslog write permissions

[eastokes]

I'm wondering if anyone has experience with the following issue while trying to meet CIS recommendations:

CIS recommends all log files be owned by root:root or root:<secure group>.
Rsyslog is configure by default to run and write to logs as syslog:adm.

Rsyslog starts elevated as root:root and then drops privileges, thus is still able to write to files owned by root:root as long as they were opened on startup. There are several log files that don't seem to be opened on startup, and thus rsyslog is not able to open them after dropping privileges, and these logs are never written to.

Notably /var/log/auth.log

[adespain]

Hmm, I just checked auth.log and noticed that nothing had been written to the log since I ran the cis role to update those permissions but also other logs in var/log aren't getting written to so maybe it's something else...I'll do some more checking.

[adespain]

http://serverfault.com/questions/518975/rsyslog-is-not-working-properly-it-does-not-log-anything
the ownership on my log files isn't correct anymore...

8.2.4.3 is the one that breaks rsyslog so that it won't log anymore. Need to fix so it doesn't change it to root:root

[eastokes]

Yeah I've changed my logs to syslog:adm which counts against the CIS score, but it seems like a more secure solution than keeping rsyslog running as root.

[adespain]

Looks like the Ubuntu 16.04 benchmarks don't modify log permissions, so they must have realized that wasn't good or something...

[awailly]

Nice spot! How should we modify 8.2.4.3 to have /var/log/auth.log with the correct permissions?

[eastokes]

I'm hesitant to modify the roles as any fix would not be compliant with v1.0 of the CIS PDF. I do think it's an oversight of the PDF, but those looking for strict compliance should probably keep things as they are.

[adespain]

I haven't tried this on 14.04 but on 16.04 if you change the permissions to root:root rsyslogd won't have permissions to write to any of the log files any more which seems like a larger security risk...

[awailly]

Ok, I think we will need a strict and lazy modes then. The strict mode would apply the CIS as-is, and not take care of the issues we detect. If more similar issues appear, with a reasonable approach to fix it, we will implement the lazy mode as a dedicated configurable option.

@eastokes, @adespain, does it sound like a solution for this issue?

[adespain]

I just looked and CIS 14.04 v2 benchmarks also remove the permissions change...maybe put a warning that says "some CIS 14.04 v1 benchmarks are insecure and that is why they published version2 -version 2 is recommended..." or something :)