Security Information

######

# Security Information

######

Guest virtual machines should be isolated from the host and from other guests running on the same host. Interaction between the host and guests, or between guests on the host, should occur only through channels with well-understood and documented security properties. This chapter helps you understand and mitigate the security risks of VIX API guest operations.

To use the VIX API for guest operations, applications must authenticate with two distinct security domains:

1. The client must first authenticate with the vSphere host.
2. The client must then supply a valid credential for the guest operating system on any virtual machine where it wants to perform guest operations.

These authentication mechanisms are explained in sections Authenticating to the vSphere Host and The VIX Guest Authentication Mechanism below.

## How to Disable Guest Operations in the VIX API

Many VIX functions (those with Guest in the name) can change data and affect settings on a guest operating system. Although guest-related functions are password protected, guest modification capability might contradict your site's security policy. If you decide to do so after reading this chapter, you can disable the running of VIX API guest operations by adding the following line to the config file:

    guest.commands.enabled = "FALSE"

Placing this line in the virtual machine's VMX file affects only that virtual machine. Placing this line in the host-wide configuration file affects all guests on that host. On ESX/ESXi hosts, `/etc/vmware/config` is the host-wide configuration file.

This line disables the operation of VMware vCenter Update Manager (VUM) and VMware Consolidated Backup (VCB), both of which call the VIX API for guest operations. This line also disables guest operations in the vSphere API 5.0 (see GuestAuthManager, GuestFileManager, and GuestProcessManager).

## Security of VIX API Guest Operations

The following sections describe the various authentication mechanisms for VIX API clients performing operations inside guest environments.

VIX provides functions that allow guest operations such as running a program in the guest, manipulating files in the guest, and so on. Guest operations are designed to be easy to use, for example, a 10-line Perl script in the guest. Guest operations are also designed to run remotely and affect many VMs. This raises the question of security.

Virtual machines and guest operating systems use security mechanisms similar to those on physical machines, in addition to the mechanisms described in this chapter.

## Authenticating to the vSphere Host

To perform any operations through the VIX API, the API client must first establish a connection to a host (ESX/ESXi or vCenter) by calling `VixHost_Connect` while supplying a username and password combination that is valid for that host.

Alternatively, with vCenter Server and ESX/ESXi 4.0 and later, a connection can be authenticated using an existing vSphere API session instead of with the username-password combination. To use an existing vSphere API session, a “clone ticket” is required. To get a clone ticket, call the API method `AcquireCloneTicket` with the SessionManager object reference. Then using the ticket string returned by this method, call `VixHost_Connect` with NULL as the userName and the clone ticket as password.

For more information about the vCenter authorization model, read about `AuthorizationManager` in the VMware vSphere API Reference.

## vSphere Permissions for Guest Operations

Specific permissions are required at the vSphere level to perform guest operations through the VIX API. In particular, the vSphere user supplied to `VixHost_Connect` must be associated with a role that has the “Acquire Guest Control Ticket” permission.

The administrator can prevent a user from performing guest operations with the VIX API by removing this permission from the user or the role.

If the user supplied to `VixHost_Connect` lacks this permission, attempts to perform guest operations through the VIX API will throw the error `VIX_E_HOST_USER_PERMISSIONS`.

## Network Connections, Transport, and Encryption

The VIX API makes two distinct connections to a vSphere or ESX/ESXi host. First, when an API client calls `VixHost_Connect` and connects to either an ESX/ESXi host or the vCenter Server, an initial connection is made using HTTPS/SOAP on TCP port 443. This is the port for secure HTTP over TLS/SSL.

Second, for each open VM handle (created by calling `VixHost_OpenVM` or `VixVM_Open`), the client code opens a socket on TCP port 902 from the client to the ESX/ESXi host where the VM resides. Data going over this connection are encrypted with SSL.

## Security of Virtual Disk and VMX Files

Despite the guest authentication mechanisms supplied with the VIX API, a vSphere user who has direct access to an unencrypted virtual disk file can use other mechanisms, such as VixDiskLib and the VDDK, to access or modify portions of the guest operating system. Unlike VixDiskLib, access to the VMX file requires local access, but could be used to modify VM configuration.

## The VIX Guest Authentication Mechanism

Authentication works in terms of implicit sessions. Currently, a VIX client (that is, a single process using the VIX library) can maintain at most one active session per VM.

Session state is stored only in the client, and any credentials are included with each command that is contained within the session. The guest Tools are stateless in terms of the security model.

To begin a session, a client calls `VixVM_LoginInGuest` with the appropriate credentials. These credentials are sent to the VMX. The VMX will, depending on the type of credentials, either determine the validity of the credential itself, or forward the command to VMware Tools for determination. Once the credentials have been accepted by either the VMX or VMware Tools, a session is established and the VIX client stores the credentials in memory, associated with the VM handle.

For each guest command (such as calling `VixVM_RunProgramInGuest`) issued by a client after successfully calling `VixVM_LoginInGuest`, the credential data associated with the handle gets sent as part of the request to the VMX, which forwards the command to VMware Tools. VMware Tools verify the credential data again, then use it if needed to perform the command.

A session can be ended in one of the following ways:

- The client calls `VixVM_LogoutInGuest`.
- The client successfully calls `VixVM_LoginInGuest` again with different credentials.
- The client releases the VM handle. Because the session state is stored with the VM handle state, releasing the handle removes the session data.
- The client process exits. Session data is stored only in memory and is never persisted to disk (except swap).

Guest operations can be disabled on a per-VM or on a per-host basis, as documented in the How to Disable section. Guest operations can also be disabled on a per-user basis by removing the “Acquire Guest Control Ticket” permission from their assigned role, as documented in the vSphere Permissionssection.

## More About VIX Guest Security Mechanisms

The currently supported security mechanisms are presented below.

#### Guest Username and Password with Impersonation

In this case, the client provides the username and password belonging to a guest account.

When `VixVM_LoginInGuest` is called, a command with the credentials is sent to the Tools daemon-service, which will attempt to impersonate the user account using the credentials. If VMware Tools succeeds with impersonation, the credentials are considered valid and success is reported to the client; otherwise, an error is reported.

When the client receives a successful response, the username and password are stored as part of the VM handle data structure (as above).

For each successive guest command, the client will send the username and password as part of the command request to the Tools. The Tools will take the credentials and then impersonate the user using them; if the impersonation succeeds, VMware Tools will then perform the action specified by the command, then undo its impersonation and revert to its original identity.

Since the Tools daemon-service runs as super user, it can impersonate any user. Also, since (if installed) it should be running whenever the guest OS is running, it can receive commands at any time after the guest completes boot-up.

On Windows, the authentication and impersonation is achieved with the `LoginUser()` and `LoadUserProfile()` Win32 APIs.

On Linux, the authentication is performed using PAM, and the impersonation is performed using `setresuid()`.

For non-interactive sessions on Linux, VIX API clients do not look at dot files inside the guest, nor do they set environment variables from the profile.

#### Guest Username and Password to Match the Interactive Session

First, a quick definition: an "interactive session" is a session where a user is logged into the guest's console. In other words, some human is interacting with the MKS (mouse keyboard screen).

When a user logs into the console of a guest OS that has VMware Tools installed, a process called `vmware-user` (VMwareUser on Windows, `vmtoolsd` on ESX/ESXi) starts. This process runs as the user who logged in, and runs inside the same environment as any applications that the user starts. On Linux this process knows about the user's X session, and has all of the user's environment variables that might be set in the `.bashrc` file and other dot files (except for non-interactive sessions). On Windows, this program has access to any mapped drives that the user has configured, and on Windows Vista and later, it runs in the interactive desktop session.

To allow users to run commands in the interactive environment, there is another login mechanism that will securely direct a command to vmware-user. To request that a command use the impersonation mechanism, a client calls `VixVM_LoginInGuest` with the options parameter set to `VIX_LOGIN_IN_GUEST_REQUIRE_INTERACTIVE_ENVIRONMENT` and passes the username and password for the account that belongs to the user who is currently logged in interactively.

When the user logs in with this method, a command is sent to the VMX, which checks if both the Tools daemon-service and the vmware-user process are running. If one or both are not running, then the command fails. If both are running, then the VMX first forwards the command to the daemon-service, which validates that the username and password are valid. If they are, then the daemon-service responds first to the VMX, which removes the password and sends the command to the vmware-user process. The vmware-user process then checks to see if the username matches the account under which it is currently running, and if so, executes the command.

The process is somewhat convoluted for a number of reasons: (1) In Linux, only root has access to `/etc/shadow`, where a hashed and salted version of each password is stored for local accounts. Thus, vmware-user process for any non-root account cannot verify the provided password. So the password must be verified by the Tools daemon. (2) Because all users have control over what applications launch when they log in, they could replace vmware-user with a malicious binary. Because a different user could be logged in interactively when a VIX client calls `LoginInGuest`, the authentication layer must not send cleartext passwords to vmware-user.