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)
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.
World readable permissions on this v2_key exposes the decryption keys for non root users.
file should be only readable by root, or at least not readable by "others".
Seems reasonable that the proper permissions for the v2_key should probably be 0400?
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
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
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 (22.214.171.124) seems to have this issue.
New commit detected on ManageIQ/manageiq-gems-pending/master:
Author: Nick Carboni <email@example.com>
AuthorDate: Fri Sep 8 09:21:17 2017 -0400
Commit: Nick Carboni <firstname.lastname@example.org>
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(-)
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.
*** Bug 1582289 has been marked as a duplicate of this bug. ***