Limit file permissions on /var/log/cloud-init.log

Bug #1541196 reported by Brandon Checketts
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
cloud-init
Fix Committed
Low
Unassigned

Bug Description

It seems that both /var/log/cloud-init.log and /var/log/cloud-init-output.log files are created with the files as publicly readable (specifically 0644 file permissions)

```
brandon@:~$ ls -al /var/log/cloud-init*
-rw-r--r-- 1 syslog adm 1060887 Jan 26 05:23 /var/log/cloud-init.log
-rw-r--r-- 1 root root 18666 Jan 26 05:23 /var/log/cloud-init-output.log
```
Are there concerns with these being publicly readable? I don't have any specific examples of confidential information that may be exposed via these logs, but wouldn't it seem prudent to limit file permissions in case there was some unintended secrets output from another application or user-defined scripts that are run via cloudinit?

Related branches

Scott Moser (smoser)
Changed in cloud-init:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Scott Moser (smoser) wrote :

Hi, thanks for the bug report. I've marked this as low.
The log should only put non-sensitive information. cloud-init log may be able to set permissionsn on the file as it uses python fileConfig to do so.

It would be nice to have output able to set the permissions.

Revision history for this message
Thomas H Jones II (ferricoxide) wrote :

Wanted to provide additional input on this: my AWS-hosted customers have compliance-requirements that test for whether all files that rsyslog knows about are mode 0600 (or more restrictive). Because rsyslog knows about the /var/log/cloud-init.log file (via an include statement), cloud-init's clobbering of the mode (reverting it to 0644) causes security scans to pop an alert for permissions misconfiguration.

I was trying to get my head around "how do I patch this behavior", but couldn't noodle it. So, for now, it's causing me pains from my CND folks screaming, "you guys need to fix this".

Any suggestions on how to update my /etc/cloud/cloud.cfg.d/05_logging.cfg (path for RHEL 7's cloud init logging-config) to get them off my neck? I'd rather not have to either POAM this or resort to an rc.local script if there's a better way of addressing the issue.

Revision history for this message
Jeff Headley (jeffunf96) wrote :

We're in the same situation as Thomas mentioned above. We need to be able to control the permissions. Is there any way of addressing this?

Revision history for this message
ChrisA (chrisdpa) wrote :

We were able to work around this by redirecting cloud-init logs to syslog and then setting def_log_file to null (so the old file is not re-set to 0o644 on every restart of cloud-init)

echo 'def_log_file:' >> /etc/cloud/cloud.cfg
sed -i -r 's/( \- \[ \*log_base, \*log_file \])/#\1/' /etc/cloud/cloud.cfg.d/05_logging.cfg
sed -i -r 's/#( \- \[ \*log_base, \*log_syslog \])/\1/' /etc/cloud/cloud.cfg.d/05_logging.cfg

And then chmod any existing files:
find /var/log -type f -exec chmod g-wx,o-rwx {} +

Dan Watkins (oddbloke)
Changed in cloud-init:
status: Confirmed → Triaged
Revision history for this message
Chris Adams (acdha) wrote :

I took an alternative approach by having systemd run chmod after cloud-init starts, which avoid the need to otherwise touch cloud-init:

/etc/systemd/system/cloud-init-log-permissions.service

[Unit]
Description=Correct cloud-init's logfile permissions

# We want to start *AFTER* cloud-init has opened its log files:
After=cloud-init.service

# We want to restart any time cloud-init is restarted (requires RemainAfterExit below):
PartOf=cloud-init.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/chmod u=rw,g=r,o= /var/log/cloud-init.log /var/log/cloud-init-output.log

[Install]
WantedBy=multi-user.target

Changed in cloud-init:
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.