In digging further, looks like this may be getting triggered by cloud-init subsystem. The "/etc/rsyslog.d/21-cloudinit.conf" file references "/var/log/cloud-init.log" which - in spite of my umask and hand-setting of the mode - loses the mode 0600 on reboot.

I'm guessing that cloud-init, itself, is resetting the mode of this file on reboot? I started poking in the "/etc/cloud/cloud.cfg.d/05_logging.cfg" to see if there's a mode-setting method, there, but am not seeing one (also didn't see one documented in the python logging.config guidance).

Bleah... The logfile's permissions problem looks to be an upstream issue with cloud-init:

https://bugs.launchpad.net/cloud-init/+bug/1541196

Dunno whether RH should track this as a scan-issue or as a package issue.

Looks like this not an issue in scap-security-guide but in the component resetting the permission on files.

Probably shouldn't be CLOSED/NOTABUG: the component that's doing it is the cloud-init software shipped by Red Hat:

> # rpm -qi cloud-init
> Name        : cloud-init
> Version     : 0.7.6
> Release     : 2.el7
> Architecture: x86_64
> Install Date: Tue 28 Feb 2017 10:35:17 PM UTC
> Group       : System Environment/Base
> Size        : 1475675
> License     : GPLv3
> Signature   : RSA/SHA256, Wed 04 Feb 2015 04:14:31 PM UTC, Key ID 1> 99e2f91fd431d51
> Source RPM  : cloud-init-0.7.6-2.el7.src.rpm
> Build Date  : Fri 16 Jan 2015 10:01:22 PM UTC
> Build Host  : x86-024.build.eng.bos.redhat.com
> Relocations : (not relocatable)
> Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
> Vendor      : Red Hat, Inc.
> URL         : http://launchpad.net/cloud-init
> Summary     : Cloud instance init scripts
> Description :
> Cloud-init is a set of init scripts for cloud instances.  Cloud instances
> need special scripts to run during initialization to retrieve and install
> ssh keys and to let the user run various scripts.

I simply pointed to the bug found in the Red Hat RPM's upstream project as a reference. If Red Hat can't get the upstream to fix things, they need to patch the version they ship since it creates an error in the oscap reports.

You are right, Thomas. Reopening and switching component to cloud-init.

Cool. Thank you!

So there are two issues here:

(1) cloud-init is setting /var/log/cloud-init.log to mode 0644.  This is an issue with the cloud-init code, and I have proposed a fix for this  upstream in https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/322244

(2) cloud-init is creating /var/log/cloud-init-output.log.  This doesn't actually stem from the cloud-init code itself but instead comes from the final lines of /etc/cloud/cloud.cfg.d/05_logging.cfg, which look like:

  # This tells cloud-init to redirect its stdout and stderr to
  # 'tee -a /var/log/cloud-init-output.log' so the user can see output
  # there without needing to look on the console.
  output: {all: '| tee -a /var/log/cloud-init-output.log'}

This is completely unnecessary, since output to stdout/stderr is captured by systemd and available via 'journalctl'.  You can simply remove these lines from the file.

I will incorprate both of these changes into the next release of cloud-init.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2275