M. Burnett brings up an important point - there is a lot of VM-as-panacea promotion going on, and implementers need to put some more thought into how VMs really fit in to the least privilege model. Another real-world scenario where this is directly relevant is for teleworkers. Some companies provide VMs to remote users thinking that they provide a secure way for people to connect to a the trusted network from an untrusted computer. They try to use the VM as virtual security when they cannot provide physical security and can't verify host integrity. Not that this is a good idea but it is a commonly promoted practice. In this scenario the VMX config file could be controlled or redirected by someone who has control of the untrusted system, so the posted fix doesn't provide much help. Same goes for the web surfing low privilege admin PC at work that also edits trusted VMs. It makes sense to add the posted config line to reduce stupid attack vectors in common implementations. But the more important underlying implementation vulnerability is that the trusted vmdk and its vmx should not be directly accessible from a computer that is not fully trusted, or under a login that cannot be trusted. So that means you can't host or edit a VM on your Windows web surfing machine without risking the VM's integrity. And it means that VMWare Player provides no real protection either for the VM. A high-trust VM should only be edited through high-trust hosts, and should only be accessible through its own properly secured network services. So the least-privilege user should not have access to the vmdk or vmx. It might make more sense to use an isolated VM as the less trustworthy web surfing machine instead of using the web machine to edit and host the trusted VM.
