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.

[ reply ]