What is the virtual machine backdoor?

[cookieme]

I came across something called a virtual machine backdoor while reading the following blog post: http://virtualfoundry.blogspot.com/2009/04/protect-console-virtual-firewall.html

It said the following:

While you're in here, go ahead and disable the virtual machine backdoor by adding this directive:

monitor_control.restrict_backdoor = "true"

What is this backdoor? Should I add this command to all my VMs?

Thanks

[RParker]

What is this backdoor?

Did you read the ENTIRE article?

That pertains to a FIREWALL within a VM, and it specifically addresses loging into the VM via alternate methods. It also requires 2 NIC's in the VM as well...

[J1mbo]

It enables nested VMs, i.e. running a Windows VM on ESXi which is in itself a VM running on ESXi - handy for test environments.

[cookieme]

What is this backdoor?

Did you read the ENTIRE article?

That pertains to a FIREWALL within a VM, and it specifically addresses loging into the VM via alternate methods. It also requires 2 NIC's in the VM as well...

Yes, I did read the ENTIRE article! I understand that it was about setting up Vyatta as a VM, which is what I am doing but for ESXi.

I wanted to know why he added the backdoor command and whether it is something that should be done in general to harden security.

You say that it "specifically addresses loging into the VM via alternate methods". What are the alternative methods?

EDIT: The author of the article wrote: "We also want to disable the virtual machine backdoor, so VMware tools must not be installed." But this doesn't explain what it does or why it should be disabled!

[cookieme]

It enables nested VMs, i.e. running a Windows VM on ESXi which is in itself a VM running on ESXi - handy for test environments.

Ok, so it both enables nested VMs and alternative methods of logging in to a VM? Is there any documentation on this from VMware, so that I can understand it a little better?

[admin · Accepted solution]

The backdoor is a communications channel between the guest and the hypervisor. It allows the guest to make hypercalls into the hypervisor. Despite the scary name, it is not a security issue in and of itself, although there is always the possibility that one of the hypercall implementations enables some kind of security exploit. The VMware backdoor is implemented as an I/O operation to a specific port address. The VT-x and AMD-V instruction sets also provide a hypercall mechanism, but we still use the legacy mechanism, because it is supported by all of our hypervisors, regardless of the underlying implementation.

The configuration option, "monitor_control.restrict_backdoor" does not disable the backdoor entirely. As the name implies, it restricts the usage of the backdoor. In particular, it only allows the guest to use the backdoor when the guest IOPL >= its CPL. Typically, this means that the guest must be executing supervisory code, such as the guest OS kernel, running at CPL 0. (There are some notable exceptions, such as the X server under Linux, which runs at CPL 3 with IOPL 3.)

When running nested VMs, the backdoor must be restricted in the outer VM if you want to be able to make hypercalls from the inner VM to the inner hypervisor. Otherwise, hypercalls made from the inner VM will be handled by the outer hypervisor. If you don't care to install VMware Tools in the inner VM, you don't have to restrict the backdoor in the outer VM.

[cookieme]

Wow, that was very elaborate and complex, but thank you for the explanation. Just to put it in simple terms what did the author accomplish by adding the configuration to a Vyatta VM? In this case it is not about nested VMs and from your reply this option only restricts the usage of the backdoor, so what is restricted as I am not familiar with "guest IOPL >= its CPL"?

Thanks

[admin]

Just to put it in simple terms what did the author accomplish by adding the configuration to a Vyatta VM?

Warm fuzzies?

In this case it is not about nested VMs and from your reply this option only restricts the usage of the backdoor, so what is restricted as I am not familiar with "guest IOPL >= its CPL"?

CPL is "current privilege level." OS kernel code typically runs at CPL 0 (the highest privilege level). User application code typically runs at CPL 3 (the lowest privilege level).

IOPL is "I/O privilege level," and controls the privilege levels at which I/O operations are allowed. If the IOPL >= the CPL, then I/O operations are allowed. Otherwise, they are not. Under most operating systems, the IOPL is almost always 0, which restricts I/O operations to CPL 0 code (i.e. the kernel). With the monitor_control.restrict_backdoor option, hypercalls are similarly restricted.

So, in typical usage, this option restricts the use of the backdoor to the guest kernel. However, depending on the OS, it may be possible to modify the IOPL of a user level process. Linux, for example, provides the iopl() system call, which can change the IOPL of the calling process. Any process which can raise its IOPL to 3 will be able to make hypercalls, regardless of the setting of the monitor_control.restrict_backdoor option.

[cookieme]

Just to put it in simple terms what did the author accomplish by adding the configuration to a Vyatta VM?

Warm fuzzies?

Hehe I understand

Thank you for taking the time to explain the details!

[admin]

If you do have security concerns about specific services provided by the hypercall mechanism, some of these services can be disabled. Some common security settings are:

isolation.tools.copy.enable = "FALSE"
isolation.tools.paste.enable = "FALSE"
isolation.tools.HGFS.disable = "TRUE"

[cookieme]

If you do have security concerns about specific services provided by the hypercall mechanism, some of these services can be disabled. Some common security settings are:

> isolation.tools.copy.enable = "FALSE"
> isolation.tools.paste.enable = "FALSE"
> isolation.tools.HGFS.disable = "TRUE"
> 

I assume that these are only applicable if VMware Tools is installed in the VM, correct?

What is HGFS?

[admin]

I assume that these are only applicable if VMware Tools is installed in the VM, correct?

No. The services are normally available from the hypervisor whether or not Tools are installed. These options disable the services at the hypervisor level, so that malicious code can't take advantage of them.

What is HGFS?

Shared folders.

[cookieme]

Thanks again!