Bug 1489556 - v2_key has world readable (others) permissions of 0644
Summary: v2_key has world readable (others) permissions of 0644
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.8.0
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: GA
: 5.9.0
Assignee: Nick Carboni
QA Contact: Alex Newman
URL:
Whiteboard:
: 1582289 (view as bug list)
Depends On:
Blocks:
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: 5.9.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-01 13:17:22 UTC
Category: Bug
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)


Links
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 (5.8.1.5) 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:
https://github.com/ManageIQ/manageiq-gems-pending/commit/a0d26857de3a92e1ec4037cd0f885089666be5dc

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
    
    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(-)

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.

https://access.redhat.com/errata/RHSA-2018:0380

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.