Bug 1489556 - v2_key has world readable (others) permissions of 0644
Summary: v2_key has world readable (others) permissions of 0644
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.8.0
Hardware: All
OS: Linux
Target Milestone: GA
: 5.9.0
Assignee: Nick Carboni
QA Contact: Alex Newman
: 1582289 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-09-07 17:43 UTC by Lynn Dixon
Modified: 2021-06-10 12:58 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-03-01 13:17:22 UTC
Category: Bug
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1582289 0 unspecified CLOSED v2_key has world readable (others) permissions of 0644 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2018:0380 0 normal SHIPPED_LIVE Moderate: Red Hat CloudForms security, bug fix, and enhancement update 2018-03-01 18:37:12 UTC

Internal Links: 1582289

Description Lynn Dixon 2017-09-07 17:43:25 UTC
Description of problem:
v2_key is created/copied with world readable permissions

Version-Release number of selected component (if applicable):
CFME 5.8 (Cloudforms 4.5) 

How reproducible:
Deploy an appliance, either create the v2_key or copy from an existing appliance

Steps to Reproduce:
1. Deploy 5.8 appliance
2. create or copy v2_key
3. navigate to /var/www/miq/vmdb/certs and list files, noticing the permissions are created as:  0644 on the v2_key file.

Actual results:
World readable permissions on this v2_key exposes the decryption keys for non root users.

Expected results:
file should be only readable by root, or at least not readable by "others".

Additional info:
Seems reasonable that the proper permissions for the v2_key should probably be 0400?

Comment 2 Greg Scott 2017-09-07 22:33:55 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.

Comment 3 Nick Carboni 2017-09-08 12:52:02 UTC
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.

Comment 4 Lynn Dixon 2017-09-08 13:19:21 UTC
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 ( seems to have this issue.

Comment 6 CFME Bot 2017-09-08 13:33:13 UTC
New commit detected on ManageIQ/manageiq-gems-pending/master:

commit a0d26857de3a92e1ec4037cd0f885089666be5dc
Author:     Nick Carboni <ncarboni@redhat.com>
AuthorDate: Fri Sep 8 09:21:17 2017 -0400
Commit:     Nick Carboni <ncarboni@redhat.com>
CommitDate: Fri Sep 8 09:21:17 2017 -0400

    Set v2_key file permissions to 0400 after create or fetch

 lib/gems/pending/appliance_console/key_configuration.rb | 11 +++++++----
 spec/appliance_console/key_configuration_spec.rb        |  3 +++
 2 files changed, 10 insertions(+), 4 deletions(-)

Comment 9 errata-xmlrpc 2018-03-01 13:17:22 UTC
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.


Comment 10 Nick Carboni 2018-05-24 19:39:31 UTC
*** Bug 1582289 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.