|Summary:||[RFE] Cannot add unencrypted administrative credentials of Vcenter in "/etc/sysconfig/virt-who"|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Jayaram Alla <jalla>|
|Component:||virt-who||Assignee:||Radek Novacek <rnovacek>|
|Status:||CLOSED ERRATA||QA Contact:||gaoshang <sgao>|
|Version:||6.0||CC:||aladke, castigliones, chrobert, mdavis, ovasik, rbalakri, rjerrido, rnovacek, rshutt, shihliu, tlavigne|
|Fixed In Version:||virt-who-0.10-1.el6||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-10-14 07:13:14 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Jayaram Alla 2014-03-27 01:40:02 UTC
Description of problem: We have customers pointing that they cannot add the unencrypted administrative credentials in "/etc/sysconfig/virt-who".This is in thee case of registering the system using Virtual data center subscription. Version-Release number of selected component (if applicable): virt-who Subscription-Manager How reproducible: Anytime Actual results: direct credentials of the administors need to be provided virt-who config file which the customer is feeling risky. Expected results: There should be a provision of providing the credentials in encrypted form if possible. else should show any other way to provide the details.
Comment 1 Jayaram Alla 2014-03-27 01:48:32 UTC
I have 2 customers reported the above concern for whom i have advised to use RHN Classic as we dont have such functionality as of now. Please correct me if I am wrong and let me know if there is any alternate solution for this. Below article may give you more idea "Using RHEL subscriptions (2013 packaging): Scenario 5 - Virtual Datacenter " >> https://access.redhat.com/site/articles/480693
Comment 3 Jayaram Alla 2014-03-28 16:49:43 UTC
Here are some more requested inputs from the customer. > - business justification i.e list the business requirements Only admin servers/desktops have access to vCenter. So Red Hat must provide a way to register RHEL guests on third party hypervisors without requiring VMs to have admin access to vCenter (the current girt-who stuff is just defective by design) Registration/enrollement must be automatic (no need to go on the RedHat support website and assign enrolments for each an every VM) > - do you have specific timeline dependencies? No specific timeline dependencies. > - would you be able to assist in testing this functionality if implemented? Sure
Comment 5 Radek Novacek 2014-04-15 11:11:11 UTC
Hi, my current plan is following: 1) try to figure out, if virt-who could be used without administrator privileges on vCenter. Would it be OK for customer to have credentials for some non-admin user stored unencrypted in virt-who config file? 2) if not, add some possibility to encrypt the password that is supplied in the config file. I don't see any possibility how make the password storage secure but we can try to make it harder to read, but it will just be security through obscurity.
Comment 6 Yogendra Jog 2014-05-05 13:42:30 UTC
This is kind of roundrobbin. CU's need to use virt-who to register the RHEL guest installed on VMware-ESX or Hyper-V. CU cannot do that as their company security policy does not allow them to mention passwords in "clear text" in virt-who config which is an administrative user. Though I have seen another case where read only user may also work ? There is no alternate method to achieve this & customers are getting frustrated. Case - 01066127 where customer has 5 QTY of SKU RH00002 Red Hat Enterprise Linux for Virtual Datacenters, Standard, which cannot be fully utilized because of this issue. Regards Yogendra.
Comment 8 Radek Novacek 2014-05-19 12:06:34 UTC
So, is following solution acceptable for you: Have some utility that will ask you for your password and will return encoded string. You will place this encoded string to virt-who config file. On the background there will be file with the encryption key somewhere on the disk only accessible by root. There is no added security in this approach, anyone with the root access will still be able to get your password, but the password won't be stored in plaintext in the configuration file.
Comment 10 Sal Castiglione 2014-05-30 15:19:28 UTC
That sounds like a better interim solution, than having the password saved as cleartext, along with having the permissions of the virt-who config file default to 600 instead of 644 ? Also - I found another bug with the girt-who service: If the password being used ends with an & character as the 3rd to last, the service fails as it’s being interpreted as a command. For example, if the password is: 12345abcde&F1 when trying to start/stop the service, it will return /etc/sysconfig/virt-who: line 44: F!: command not found -Sal
Comment 11 Radek Novacek 2014-06-02 06:34:12 UTC
Config file permissions will be changed to 600. The behavior with ampersand in the password is expected. The /etc/sysconfig/virt-who file is read as a shell script that sets some environmental variables. The password should be quoted, e.g. VIRTWHO_ESX_PASSWORD='12345abcde&F1' I'll add note that this could happen. Thanks for noticing.
Comment 12 Radek Novacek 2014-06-06 12:08:25 UTC
This bug is fixed upstream and will be resolved by rebase of virt-who, see bug 1002640.
Comment 13 Radek Novacek 2014-06-18 07:34:03 UTC
This is already implemented, removing FutureFeature keyword.
Comment 14 Radek Novacek 2014-06-18 13:49:06 UTC
This bug is fixed by rebase to virt-who-0.10-1.el6.
Comment 16 Liushihui 2014-07-28 06:46:41 UTC
Verify it on virt-who-0.10-3.el6.noarch. Config file /etc/sysconfig/virt-who permissions has been modified to 600. [root@hp-z220-05 sysconfig]# ls -alt virt-who -rw-------. 1 root root 1846 Jul 28 14:29 virt-who
Comment 17 Jayaram Alla 2014-08-28 18:21:08 UTC
Hello Radek, May I know whether is there any date planned for the release of this fix ? so that I can update customer accordingly. Thank you in advance.
Comment 18 Radek Novacek 2014-08-29 06:08:02 UTC
This will be part of RHEL-6.6 release that is currently planned to the mid of October.
Comment 20 errata-xmlrpc 2014-10-14 07:13:14 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. http://rhn.redhat.com/errata/RHBA-2014-1513.html
Comment 21 Chris Roberts 2014-10-21 15:59:42 UTC