Execution Environment

Figure 1–3 shows the components of the execution environment. Each component provides certain services that together form the overall platform on which to run the production guest domains. Properly configuring the components is vitally important for the integrity of the system.

All of the execution environment components are potential targets for an attacker. This section describes the threats that might affect each component in the execution environment. Some threats and countermeasures might apply to more than one component.

Threat: Manipulation of the Execution Environment

By manipulating the execution environment, you can gain control in numerous ways. For example, you might install manipulated firmware in the ILOM to snoop on all guest domain I/O from within an I/O domain. Such an attack can access and change the system's configuration. An attacker that takes control of the Oracle VM Server for SPARC control domain can reconfigure the system in any way, and an attacker that takes control of an I/O domain can make changes to attached storage, such as to boot disks.

Evaluation: Manipulation of the Execution Environment

An attacker who successfully breaks in to either the ILOM or to any domain in the execution environment can read and manipulate all data that is available to that domain. This access might be gained over the network or by means of an error in the virtualization stack. Such an attack is difficult to perform as usually the ILOM and the domains cannot be attacked directly.

The countermeasures to protect against the manipulation of the execution environment are standard security practice and should be implemented on any system. Standard security practices present an additional layer of protection around the execution environment that further reduces the risk of intrusion and manipulation.

Countermeasure: Securing Interactive Access Paths

Ensure that you only create accounts that are required for the applications that run on the system.

Ensure that accounts that are required for administration are secured by using either key-based authentication or strong passwords. These keys or passwords should not be shared among different domains. Also, consider implementing two-factor authentication or a “two-person rule” for taking certain actions.

Do not use anonymous logins for accounts such as root to ensure that you have complete traceability and accountability of the commands run on the system. Instead, use rights to grant individual administrators access only to those functions that they are permitted to perform. Ensure that administrative network access always uses encryption such as SSH and that an administrator's workstation is treated as a high-security system.

Countermeasure: Minimizing the Oracle Solaris OS

Any software that is installed on a system can be compromised, so ensure that you install only the required software to minimize the breach window.

Countermeasure: Hardening the Oracle Solaris OS

In addition to installing a minimized Oracle Solaris OS, configure software packages to “harden” the software against attack. First, run limited network services to effectively disable all network services except for SSH. This policy is the default behavior on Oracle Solaris 11 systems. For information about how to secure the Oracle Solaris OS, see Oracle Solaris 10 Security Guidelines and Oracle Solaris 11 Security Guidelines .

Countermeasure: Using Role Separation and Application Isolation

By necessity, production applications are connected to other systems and as a result are more exposed to external attacks. Do not deploy production applications to a domain that is part of the execution environment. Instead, ensure that you deploy them only to guest domains that have no further privileges.

The execution environment should provide only the necessary infrastructure for these guest domains. Separating the execution environment from the production applications enables you to implement granularity in administration privileges. A production guest domain administrator does not require access to the execution environment and an execution environment administrator does not require access to the production guest domains. If possible, assign the different roles of the execution environment, such as the control domain and I/O domain, to different domains. This type of configuration reduces the amount of damage that can be done if any one of these domains is compromised.

You can also extend role separation to the network environment that is used to connect your different servers.

Countermeasure: Configuring a Dedicated Management Network

Connect all servers that are equipped with service processors (SPs) to a dedicated management network. This configuration is also recommended for the domains of the execution environment. If networked at all, host these domains on their own dedicated network. Do not connect the execution environment domains directly to those networks that are assigned to the production domains. While you can perform all administrative work through the single console connection that is made available by the ILOM SP, this configuration makes administration sufficiently cumbersome to be impracticable. By separating the production and administration networks, you protect against both eavesdropping and manipulation. This type of separation also eliminates the possibility of an attack on the execution environment from the guest domains over the shared network.

Figure 5 - Dedicated Management Network