Bug 1346448
| Summary: | [ESXi][RHEL7.3]open-vm-tools SSL/TLS certificates needs to be unique per instance or install but this value is created at install-time and not during the first run. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Kurt Seifried <kseifried> | ||||
| Component: | open-vm-tools | Assignee: | Cathy Avery <cavery> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | ldu <ldu> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.1 | CC: | cavery, gveitmic, jsavanyo, ldu, mrezanin, ravindrakumar, ribarry, rjones, vmware-gos-qa, yacao, ybhasin | ||||
| Target Milestone: | rc | Keywords: | ZStream | ||||
| Target Release: | 7.8 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1813246 1813247 1813912 1813913 (view as bug list) | Environment: | |||||
| Last Closed: | 2020-04-15 12:48:27 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 1667549 | ||||||
| Bug Blocks: | 1346019, 1782469, 1797441, 1813246, 1813247, 1813912, 1813913 | ||||||
| Attachments: |
|
||||||
Rich, I will take care of this for Fedora and you will have to help with RHEL. Kurt, thanks for the details. I have a question though. None of the links talk about who would remove/cleanup these system specific setup files? Is the cleanup of these files still a responsibility of RPM? (FYI, I have also raised this question on https://fedorahosted.org/fpc/ticket/506) (In reply to Ravindra Kumar from comment #2) > Rich, I will take care of this for Fedora and you will have to help with > RHEL. > > Kurt, thanks for the details. I have a question though. None of the links > talk about who would remove/cleanup these system specific setup files? Is > the cleanup of these files still a responsibility of RPM? (FYI, I have also > raised this question on https://fedorahosted.org/fpc/ticket/506) That is more of a programming/BU question, the only security concern is it needs to be unique (so first run), as long as you get there without creating a new security flaw I'm happy =). As for cleanup it seems like postinstall could still do that, we'd have the .rpmsave stuff in case right? Just a note, the first run issue can also be handled through orchestration (e.g. OpenStack, CloudForms, OpenShift Enterprise and so on). But the certificate creation MUST be removed from the rpm install scripts. (In reply to Kurt Seifried from comment #3) > As for cleanup it seems like postinstall could still do > that, we'd have the .rpmsave stuff in case right? You seem to be talking about upgrade and I was referring to uninstall. For cleanup in uninstall, I will have to hard code the assumptions about the file paths. I will take a look at it. I'm assigning this bug to myself. Ravindra please continue to work this issue. I have committed following 2 changes to fix this in Fedora: 1. https://src.fedoraproject.org/rpms/open-vm-tools/c/3f6bfd351da6d80f07fffc139b2d52e30b1bc9fe?branch=master 2. https://src.fedoraproject.org/rpms/open-vm-tools/c/6296e846e8f8abcb374b3fd1019dbff62b1dfeb1?branch=master Both changes together should address this issue. OK moving this BZ to POST. The fix appears to be in 10.3.0-3. It will be picked up in RHEL 7.7 when Mirek rebases. (In reply to Cathy Avery from comment #8) > The fix appears to be in 10.3.0-3. Actually, there was an additional change. Both the fixes are in open-vm-tools-10.3.0-4. I'd like to let you know that we have changed our direction regarding this tool. We are going to remove vmware-guestproxycerttool in very near future from open-vm-tools. So, another potential fix for this is to remove vmware-guestproxycerttool and it's call from the postinstall step in the spec file. You have 2 options at this point: 1. Either follow the Fedora fix I provided earlier -OR- 2. Remove vmware-guestproxycerttool and its invocation from the RPM postinstall step Hi Ravindra, For this issue, I am not sure how to verify it, could you help give clearly steps? Install RHEL7 on ESXi host, then install container in RHEL guest, does this right? how to check the key/certificate? Thanks very much! Lili Simply check if there are certs generated under /etc/vmware-tools/GuestProxyData directory after installing open-vm-tools. There should be none unless you start vmtoolsd service. (In reply to Ravindra Kumar from comment #16) > Simply check if there are certs generated under > /etc/vmware-tools/GuestProxyData directory after installing open-vm-tools. > There should be none unless you start vmtoolsd service. @Ravindra, thanks for provide info! I test with open-vm-tools.x86_64 0:10.3.0-2.el7 , There is no certs under etc/vmware-tools/GuestProxyData directory after uninstall open-vm-tools, but after install open-vm-tools, even not start vmtoolsd service,certs would be generated under etc/vmware-tools/GuestProxyData directory. maybe this version open-vm-tools not contain your patch in commnet 7. @Cathy, as this bug fixed in version open-vm-tools-10.3.0-4, but now the OVT version in RHEL7.7 is open-vm-tools.x86_64 0:10.3.0-2.el7 , could you help confirm the patch in comment 7 contain in open-vm-tools.x86_64 0:10.3.0-2.el7 ? Created attachment 1577783 [details]
RHEL-7 Missing code
Attaching changes missing in RHEL 7
Ravindra, We are missing patch https://src.fedoraproject.org/rpms/open-vm-tools/c/3f6bfd351da6d80f07fffc139b2d52e30b1bc9fe?branch=master in RHEL7 and are mulling over if we should defer to z-stream or make it a blocker. How important is the presence of this patch to customers? Thanks, Cathy This bug was actually raised by RH security team. So, I think they need to make this call. From our perspective, it is not important to block a release or require any special patch because the component that uses the certificate in question is unused functionality. (In reply to Ravindra Kumar from comment #26) > This bug was actually raised by RH security team. So, I think they need to > make this call. > > From our perspective, it is not important to block a release or require any > special patch because the component that uses the certificate in question is > unused functionality. Ravindra, thanks for the quick response. Does your comment apply to the entire content of the patch in comment 25? I think there's other code besides the fix for this particular security bug. Can you re-check and let us know if there's anything else in that patch that we should block the release for? Thanks! (In reply to Rick Barry from comment #27) > Does your comment apply to the entire content of the patch in comment 25? I > think there's other code besides the fix for this particular security bug. > > Can you re-check and let us know if there's anything else in that patch that > we should block the release for? This patch - https://src.fedoraproject.org/rpms/open-vm-tools/c/3f6bfd351da6d80f07fffc139b2d52e30b1bc9fe?branch=master - intends to fix only this bug. There is nothing else in that patch. Based on comment 26 and 28, the missing patch provides a fix only for this bug and does not impact critical open-vm-tools functionality, so it's not a blocker for RHEL 7.7. We'll defer this change to RHEL 7.8 where we'll either pull in this patch or rebase to 10.3.10 (TBD). @Ravindra https://src.fedoraproject.org/rpms/open-vm-tools/c/3f6bfd351da6d80f07fffc139b2d52e30b1bc9fe?branch=master is a Fedora only patch. Meaning there is no upstream equivalent. What version of Fedora? Thanks, Cathy (In reply to Cathy Avery from comment #33) > @Ravindra > > https://src.fedoraproject.org/rpms/open-vm-tools/c/ > 3f6bfd351da6d80f07fffc139b2d52e30b1bc9fe?branch=master is a Fedora only > patch. Meaning there is no upstream equivalent. There was no upstream fix because entire change was in the packaging scripts. Please note that this fix is not needed/applicable to open-vm-tools 11.0.0 and later because the service that need the SSL certs has been removed from the newer versions. > What version of Fedora? Patch was applied to multiple branches of Fedora, e.g. Fedora 27 too https://src.fedoraproject.org/rpms/open-vm-tools/c/3f6bfd351da6d80f07fffc139b2d52e30b1bc9fe?branch=f27. Fixed in 7.9 rebase BZ 1806675 |
Version-Release number of selected component (if applicable): open-vm-tools-9.10.2-4.el7.x86_64.rpm How reproducible: Always. post install: /usr/bin/vmware-guestproxycerttool -g &> /dev/null || /bin/true -g, --generate_key_cert Regenerate the server key/cert, the old key/cert will be replaced. Steps to Reproduce: 1. Install to a container or image. 2. Run new instance of container or image. 3. Actual results: All container and image instances share the same key/certificate. Expected results: Each instance should receive a unique key/certificate. Additional info: This bug is being file because Product Security considers "first run problems" to be bugs with the source package and with the container or image only in the aggregate. This view is in collaboration with upstream Fedora. See: https://fedorahosted.org/fpc/ticket/506 The recommended resolution for services is to follow the "First-time Service Setup" pattern (see: https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup ). Other packages may should use a runtime check and generation or similar procedure.