Chapter 1 Oracle VM Server for SPARC Security Overview
Security Features Used by Oracle VM Server for SPARC
Oracle VM Server for SPARC Product Overview
Applying General Security Principles to Oracle VM Server for SPARC
Security in a Virtualized Environment
Securing the Execution Environment
Threat: Unintentional Misconfiguration
Countermeasure: Creating Operational Guidelines
Threat: Errors in the Architecture of the Virtual Environment
Countermeasure: Carefully Assigning Guests to Hardware Platforms
Countermeasure: Planning an Oracle VM Server for SPARC Domain Migration
Countermeasure: Correctly Configuring Virtual Connections
Countermeasure: Using VLAN Tagging
Countermeasure: Using Virtual Security Appliances
Threat: Side Effects of Sharing Resources
Evaluation: Side Effects Through Shared Resources
Countermeasure: Carefully Assigning Hardware Resources
Countermeasure: Carefully Assigning Shared Resources
Summary: Side Effects Through Shared Resources
Threat: Manipulation of the Execution Environment
Evaluation: Manipulation of the Execution Environment
Countermeasure: Securing Interactive Access Paths
Countermeasure: Minimizing the Oracle Solaris OS
Countermeasure: Hardening the Oracle Solaris OS
Countermeasure: Using Role Separation and Application Isolation
Threat: Complete System Denial-of-Service
Evaluation: Complete System Denial-of-Service
Countermeasure: Securing the ILOM
Threat: Breaking the Isolation
Evaluation: Breaking the Isolation
Countermeasure: Validating Firmware and Software Signatures
Countermeasure: Validating Kernel Modules
Threat: Control Domain Denial-of-Service
Evaluation: Control Domain Denial-of-Service
Countermeasure: Securing Console Access
Threat: Unauthorized Use of Configuration Utilities
Evaluation: Unauthorized Use of Configuration Utilities
Countermeasure: Applying the Two-Person Rule
Countermeasure: Using Rights for the Logical Domains Manager
Countermeasure: Hardening the Logical Domains Manager
Countermeasure: Auditing the Logical Domains Manager
Threat: Manipulation of a Service Domain
Evaluation: Manipulation of a Service Domain
Countermeasure: Granularly Segregating Service Domains
Countermeasure: Isolating Service Domains and Guest Domains
Countermeasure: Restricting Access to Virtual Consoles
Threat: Experiencing a Denial-of-Service of an I/O Domain or a Service Domain
Evaluation: Experiencing a Denial-of-Service of an I/O Domain or a Service Domain
Countermeasure: Granularly Configuring I/O Domains
Countermeasure: Configuring Redundant Hardware and Root Domains
Threat: Manipulation of an I/O Domain
Evaluation: Manipulation in an I/O Domain
Countermeasure: Protecting Virtual Disks
Countermeasure: Securing the Guest Domain OS
Chapter 2 Secure Installation and Configuration of Oracle VM Server for SPARC
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.
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.
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.
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.
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.
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 .
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.
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