Permissions issues with /var/log/firewalld

Posted on

In the process of writing some security-remediation for one of my customers. One of the things they insist on is that all the files under /var/log must be mode 0600. A couple of processes create files with looser permissions than that but the permissions can be overridden using the UMask systemd-unit configuration-parameter (e.g., rhel-dmesg.service so as to ensure that dmesg output is protected).

Thought I'd taken care of things until the (AWS Inspector) scan came back. While the scan doesn't enumerate which file has offending permissions, a quick scan of the /var/log filesystem showed that the firewalld logfile was at least one of them. So, much like I did for the rhel-dmesg.service, I created an /etc/systemd/sytem/ file for the firewalld.service (copying from /usr/lib/systemd/system), and added the requisite UMask parameter and value to its [Service] section. Manually set the perms on the file and rebooted.

After reboot, checked the /var/log directory and the firewalld file was back to being mode 0640. In doublechecking my /etc/systemd/system/firewalld.service file, I noticed that there was a /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service file ...that sym-linked directly back to /usr/lib/systemd/system/firewalld.service ...which seems kind of broken, to me, but (insert shrug emoji). I nuked that sym-link and changed it to a hard-link pointing to my /etc/systemd/system/firewalld.service file.

I then repeated the "change current log-file's mode and reboot". Logged back in, the log file was back to mode 0640. So, seems like the firewalld service ignores the UMask parameter in its systemd unit file? Anyone know if this is expected behavior or a bug? And, in either case, how does one best ensure that firewalld's logfile stays at mode 0600 so that weekly scans don't flag it?

Responses