2.3. Virtualization Layer

2.3.1. Desktop Provider Security
2.3.2. Desktop Security
2.3.3. RDP Security
2.3.4. Storage Security

The following sections describe the security model used for desktops and desktop providers.

For more information about secure configuration of any virtualization or session platform not supplied by Oracle, please refer to the documentation provided by the vendor.

2.3.1. Desktop Provider Security

Oracle VDI categorizes desktop providers according to the virtualization platform they use or the type of session they support. Hypervisor-based Desktop Providers

In the case of hypervisor-based desktop providers, the virtualization platform provides virtualization services and security mechanisms, and the desktop provider manages the virtualization services.

Oracle VDI manages hypervisors through the following interfaces:

  • The Oracle VM VirtualBox desktop provider uses the VirtualBox web services API.

  • The Microsoft Hyper-V desktop provider uses the Windows Remote Management (WinRM) interface.

  • The VMware vCenter desktop provider uses the VMware Infrastructure SDK web services API.

Communication to and from these interfaces takes place over secure HTTPS connections (see Firewalls Between Desktop Providers and Oracle VDI Centers in the Oracle Virtual Desktop Infrastructure Administrator's Guide).

Each desktop provider is configured with the user name and password of a sufficiently privileged account of the hypervisor management interface. These credentials are stored securely in the Oracle VDI database. Session-based Desktop Providers

Session-based desktop providers offer access to desktops hosted on remote computers or on the Oracle VDI host itself.

Kiosk Session Provider

Under Sun Ray Software, a given kiosk session normally runs as its own Sun Ray session, initiated by the X display manager (dtlogin/gdm), which operates with root privileges. The kiosk framework performs some of the session setup and teardown steps with root privileges and has hooks that allow customers to add session setup and teardown scripts, which also require root privileges.

Under Oracle VDI, kiosk sessions run within the already-started Oracle VDI kiosk session type, and the kiosk session runs without privileges. If a kiosk session type is designed to require root privileges, for instance, for custom setup and/or teardown code, it will not work, or at least will not work as intended.

Administrators should examine desktops and custom-designed kiosk sessions for possible vulnerabilities, such as users' ability to escape from the restricted session environment. For example, a UNIX terminal on a custom kiosk session could give users access to a command-line interface of the underlying operating system.

It is also advisable to identify and fix application exploits, wherever possible, to prevent unauthorized access, especially to the underlying operating system. At one time, for example, the Netscape Navigator print function allowed users to modify the lp print command used by the browser so that a user could replace the lp command with any application or script on the system and run it by clicking Print.

For further information on kiosk sessions in general and developing customized kiosk sessions to further enhance security, see:


The Microsoft RDS desktop provider can be set up, optionally, to provide additional status information for monitoring through the Windows Remote Management (WinRM) interface. Communication to this interface takes place over secure HTTPS connections.

Generic Session Provider

In addition to the kiosk and RDS session providers, there is a generic session provider that can be used to access any RDP server, such as a standalone PC running a suitable version of Windows, as an Oracle VDI desktop.

2.3.2. Desktop Security

Most desktop providers offer access to full desktops as supported by the operating system of an individual virtual machine or a remote host. The security features and configuration of these desktops depend on the desktop host operating system and access method as well as on which desktop provider and desktop pool type is used. See Configuring Pools and Desktops in the Oracle Virtual Desktop Infrastructure Administrator's Guide.

Oracle VDI administrators should take the same precautions with these desktops as they would with any physical PC, securing them with respect to the remote access method as well as normal practices, such as providing anti-virus software.

Desktop Templates

The easiest way to create new virtual desktops is to clone them from a template. Templates make it easy and convenient to roll out new versions of OS, application software, and security updates to all derived desktops (see About Templates and Revisions in the Oracle Virtual Desktop Infrastructure Administrator's Guide). However, anyone administering pools of virtual machines should pay close attention to the secure installation and configuration of desktop templates, since any problems in the template are replicated in its clones.

Oracle VDI desktops that cannot be updated through a new template revision need to be updated individually, through manual or automated update mechanisms provided by the software vendor or vendors.


Flexible desktop pools can provide enhanced protection against malware or user error, depending on their recycling policy. When a used desktop is deleted and subsequently replaced by a fresh instance, the newly cloned desktop is in the state provided by the template, which should be clean and well-defined. Any malware or misconfiguration issues that may have affected a prior instance are discarded when the virtual desktop is deleted.

2.3.3. RDP Security

Oracle VDI uses RDP for connections to virtual desktops. Administrators can specify levels of access control, authentication, connection, and session security with configuration policies on the Oracle VDI host. Some specific security properties of the connection can be controlled through RDP client settings and capabilities. Details vary depending on the desktop platform and access method.

RDP Connections

RDP connections are encrypted by default. The encryption mechanism depends on the configuration of the desktop host and the capabilities of the RDP client (see Section 2.1.2, “RDP Clients and the Oracle VDI RDP Broker” in the Oracle Virtual Desktop Infrastructure Administrator's Guide).

The Sun Ray Windows connector, which acts as the RDP client for Oracle Virtual Desktop Client and Sun Ray Client connections, provides options to control security choices and requirements. For information about enhanced network security options for the Sun Ray Windows connector, see Network Security in the Sun Ray Software Administration Guide.

RDP options can be configured separately for each pool. Most advanced security options, such as those to control peer verification for SSL connections, can also be configured globally through Oracle VDI kiosk session arguments.

Before users are granted access to desktop pools that use RDP, they are authenticated by the host, using the RDP authentication mechanisms specified with the Oracle VDI host configuration policies. RDP connections use a well-known port on the virtual machine (see Firewalls Between Clients and Oracle VDI in the Oracle Virtual Desktop Infrastructure Administrator's Guide).

VRDP Connections

The Oracle VM VirtualBox desktop provider can treat connecting to the host console and authenticating to the desktop operating system as separate steps, which do not need to occur at the same time. Since VRDP is a special case of RDP, VRDP connections are encrypted by default. Oracle VDI configures the virtual machine to require a secure, one-time password for RDP connections, made available only to authenticated Oracle VDI clients. If the guest OS supports this feature, then when the desktop becomes available for login, Oracle VDI cooperates with the Oracle VM VirtualBox Guest Additions to provide automatic login to the desktop for the authenticated Oracle VDI user. This scenario does not apply, however, if Oracle VDI client authentication is disabled.

2.3.4. Storage Security

Oracle VDI uses storage systems to maintain desktop and template images, both for personal (static) and flexible (dynamic) desktops. These images can be managed and operated upon by Oracle VDI and/or the hypervisor. As the administrator, you can choose which desktop provider to use.

Oracle VDI manages the storage for the Oracle VM VirtualBox and Microsoft Hyper-V desktop providers and ZFS storage pools on Sun Unified Storage Systems or Oracle Solaris hosts. It uses Secure Shell (SSH) for management access to storage hosts. Management access requires a sufficiently privileged account on the storage host, credentials for which are stored securely in the Oracle VDI database. Hypervisors access the desktop image data through a common account.

When Oracle VDI manages storage, it does not encrypt iSCSI used for data traffic connections by default. This is a good strategy for optimizing performance with large amounts of data, but it assumes that access to the storage data network is sufficiently secured. An isolated network within the data center, with physical access controls, for instance, would supply sufficient security in this case. Oracle VDI administrators should ensure that the storage data network is in fact secured, whether by this method or by another.

Customers who use the VMware vCenter desktop provider should refer to VMware documentation for information about how to configure storage securely. When vCenter is used, Oracle VDI directs the use of storage, but does not interface with storage directly.

For all other desktop providers, and for local storage, Network File System (NFS) storage, and unmanaged iSCSI storage scenarios, storage is managed independently of Oracle VDI. For any of these cases, refer to the documentation for the specific storage product and operating system for information about secure configuration.