Bug 1424612
| Summary: | Test for rsyslog file-mode test is broken | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Thomas Jones <redhat> |
| Component: | cloud-init | Assignee: | Lars Kellogg-Stedman <lars> |
| Status: | CLOSED ERRATA | QA Contact: | Vratislav Hutsky <vhutsky> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.4 | CC: | huzhao, mhaicman, mmagr, openscap-maint, redhat, vhutsky, yacao |
| Target Milestone: | rc | Keywords: | Reopened, Triaged |
| Target Release: | 7.4 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | cloud-init-0.7.9-6.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 23:23:42 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 |
Description of problem: The oscap test for the rsyslog_files_permissions seems to always report a permission violation, even when all filemodes on logs created by rsyslog are set to 0600 or more restrictive. Version-Release number of selected component (if applicable): - RHEL 7.3.1611 (redhat-release-server-7.3-7.el7.x86_64) - openscap-1.2.10-2.el7.x86_64 - openscap-scanner-1.2.10-2.el7.x86_64 - scap-security-guide-0.1.30-3.el7.noarch How reproducible: Steps to Reproduce: 1. Install RHEL 7.3.1611 2. Install the openscap utilities 3. Update /etc/rsyslog.conf to set $umask var to 0277 4. Manually set all /var/log files to secure mode (e.g., `find /var/log -type f | xargs chmod go-rwx`) 5. Reboot system 6. Run oscap in report-mode with a profile that includes rsyslog file-mode checking (e.g., "C2S") - for example, `oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_C2S /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml` 6. View error-report and Cross-check to system state: # awk '/^[a-z*].*\//{ print $0}' /etc/rsyslog.conf *.info;mail.none;authpriv.none;cron.none /var/log/messages authpriv.* /var/log/secure mail.* -/var/log/maillog cron.* /var/log/cron uucp,news.crit /var/log/spooler local7.* /var/log/boot.log # ls -ld $(awk '/^[a-z*].*\//{ print $2}' /etc/rsyslog.conf | sed 's/^-//') ls: cannot access /var/log/boot.log: No such file or directory -rw-------. 1 root root 7954 Feb 17 19:24 /var/log/cron -rw-------. 1 root root 2753 Feb 17 19:24 /var/log/maillog -rw-------. 1 root root 1313092 Feb 17 19:27 /var/log/messages -rw-------. 1 root root 81628 Feb 17 19:27 /var/log/secure -rw-------. 1 root root 0 Dec 16 16:19 /var/log/spooler Actual results: OSCAP report indicates that not all files created by rsyslog are 0600 or better. Expected results: OSCAP report should report "Pass" state. Additional info: