Bug 1489556
| Summary: | v2_key has world readable (others) permissions of 0644 | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Lynn Dixon <ldixon> |
| Component: | Appliance | Assignee: | Nick Carboni <ncarboni> |
| Status: | CLOSED ERRATA | QA Contact: | Alex Newman <anewman> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 5.8.0 | CC: | abellott, anewman, brant.evans, greartes, gscott, jcutter, jhardy, ncarboni, obarenbo, rspagnol, simaishi, tpapaioa |
| Target Milestone: | GA | ||
| Target Release: | 5.9.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 5.9.0.1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-03-01 13:17:22 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | Bug | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Lynn Dixon
2017-09-07 17:43:25 UTC
I just looked at my own test appliance running Cloudforms 4.2. (CFME 5.7, an older version) [root@firstcloudforms42 ~]# cd /var/www/miq/vmdb/certs/ [root@firstcloudforms42 certs]# ls -al total 24 drwxr-xr-x. 2 root root 88 Jan 10 2017 . drwxr-xr-x. 20 root root 4096 Jan 10 2017 .. -rw-r--r--. 1 root root 3185 Dec 19 2016 server.cer -rw-r--r--. 1 root root 887 Dec 19 2016 server.cer.key -rw-r--r--. 1 root root 79 Dec 19 2016 v0_key -rw-r--r--. 1 root root 154 Dec 19 2016 v1_key -r--------. 1 root root 154 Jan 10 2017 v2_key [root@firstcloudforms42 certs]# As you can see, the permission bits on my v2_key are set to 400. But there are others at 644. And there may be others in different directories I don't know about. As long as this bz is for tightening up the permissions on v2_key, it seems reasonable to also tighten them on all private keys. The fix for this BZ will be to set the permissions for any newly generated or fetched keys, it will likely not provide a migration for existing keys on the file system. Additionally, I believe v2_key is a replacement for the older v1_key and v0_key. I'm not sure that they should be removed, but it not likely that they are being used if you have a v2_key present. I can confirm setting v2_key to 0400 does not cause any issues with already existing appliances. The customer referenced in the external tracker has been currently running with v2_key at 0400 for over a day now, with no issues. Adding to Mr. Greg Scott's comment, it doesnt appear this affected previous versions of the appliance. However, deploying the latest version of 5.8 (5.8.1.5) seems to have this issue. New commit detected on ManageIQ/manageiq-gems-pending/master: https://github.com/ManageIQ/manageiq-gems-pending/commit/a0d26857de3a92e1ec4037cd0f885089666be5dc commit a0d26857de3a92e1ec4037cd0f885089666be5dc Author: Nick Carboni <ncarboni> AuthorDate: Fri Sep 8 09:21:17 2017 -0400 Commit: Nick Carboni <ncarboni> CommitDate: Fri Sep 8 09:21:17 2017 -0400 Set v2_key file permissions to 0400 after create or fetch https://bugzilla.redhat.com/show_bug.cgi?id=1489556 lib/gems/pending/appliance_console/key_configuration.rb | 11 +++++++---- spec/appliance_console/key_configuration_spec.rb | 3 +++ 2 files changed, 10 insertions(+), 4 deletions(-) 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/RHSA-2018:0380 *** Bug 1582289 has been marked as a duplicate of this bug. *** |