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:
These authentication mechanisms are explained in sections Authenticating to the vSphere Host and The VIX Guest Authentication Mechanism below.
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).
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.
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.
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.
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.
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.
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:
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.
The currently supported security mechanisms are presented below.
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.
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.