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
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
Countermeasure: Configuring a Dedicated Management Network
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
The operational environment includes physical systems and their components, datacenter architects, administrators, and members of the IT organization. A security breach can occur at any point in the operational environment.
Virtualization places a layer of software between the actual hardware and the guest domains that run the production services, which increases complexity. As a result, you must carefully plan and configure the virtual system and beware of human error. Also, beware of attempts by attackers to gain access to the operational environment by using “social engineering.”
The following sections describe the distinctive threats that you can counter at the operational environment level.
The primary security concern for a virtualized environment is to sustain server isolation by separating network segments, segregating administrative access, and deploying servers to security classes, which are groups of domains that have the same security requirements and privileges.
Carefully configure virtual resources to avoid some of the following errors:
Creating unnecessary communication channels between production guest domains and the execution environment
Creating unnecessary access to network segments
Creating unintentional connections between discrete security classes
Unintentionally migrating a guest domain to the wrong security class
Allocating insufficient hardware, which might lead to unexpected resource overloading
Assigning disks or I/O devices to the wrong domain
Before you begin, carefully define the operational guidelines for your Oracle VM Server for SPARC environment. These guidelines describe the following tasks to perform and how to perform them:
Managing patches for all components of the environment
Enabling the well-defined, traceable, and secure implementation of changes
Checking log files at a regular interval
Monitoring the integrity and availability of the environment
Regularly perform checks to ensure that these guidelines remain up to date and adequate, and to verify that these guidelines are being followed in everyday operations.
In addition to these guidelines, you can take several more technical measures to reduce the risk of unintentional actions. See Logical Domains Manager.
When moving a physical system to a virtualized environment, you can usually keep the storage configuration as-is by reusing the original LUNs. However, the network configuration must be adapted to the virtualized environment and the resulting architecture might differ considerably from the architecture used on the physical system.
You must consider how to maintain the isolation of the discrete security classes and their needs. Also, consider the shared hardware of the platform and shared components such as network switches and SAN switches.
To maximize security for your environment, ensure that you maintain the isolation of guest domains and security classes. When you design the architecture, anticipate possible errors and attacks and implement lines of defense. A good design helps to confine potential security issues while managing complexity and cost.
Use security classes, which are groups of domains that have the same security requirements and privileges, to isolate individual domains from each other. By assigning guest domains that are in the same security class to a certain hardware platform, even a breach of isolation prevents the attack from crossing into another security class.
The live domain migration feature has the potential to break isolation if a guest domain is inadvertently migrated to a platform that is assigned to a different security class as shown in the following figure. So, carefully plan guest domain migration to ensure that a migration across security class boundaries is not permitted.
Figure 4 - Domain Migration Across Security Boundaries
Losing track of all of the virtual network connections might lead to a domain gaining erroneous access to a network segment. For example, such access might circumvent the firewall or a security class.
To reduce the risk of implementation errors, carefully plan and document all of the virtual and physical connections in your environment. Optimize the domain connection plan for simplicity and manageability. Clearly document your plan and verify the correctness of your implementation against your plan before going into production. Even after your virtual environment is in production, verify the implementation against the plan at regular intervals.
You can use VLAN tagging to consolidate several Ethernet segments onto a single physical network. This feature is also available for virtual switches. To mitigate the risks involved with software errors in the implementation of virtual switches, configure one virtual switch per physical NIC and VLAN. To further protect against errors in the Ethernet driver, refrain from using tagged VLANs. However, the probability for such errors is low as this tagged VLAN vulnerability is well known. Intrusion tests on Oracle's Sun SPARC T-Series platform with the Oracle VM Server for SPARC software have not shown this vulnerability.
Security appliances such as packet filters and firewalls are instruments of isolation and protect the isolation of security classes. These appliances are subject to the same threats as any other guest domain, so using them does not guarantee complete protection against an isolation breach. Therefore, carefully consider all aspects of risk and security before you decide to virtualize such a service.
Resource sharing in a virtualized environment might lead to denial-of-service (DoS) attacks, which overload a resource until it negatively affects another component such as another domain.
In a Oracle VM Server for SPARC environment, only some resources might be affected by a DoS attack. CPU and memory resources are assigned exclusively to each guest domain, which prevents most DoS attacks. Even the exclusive assignment of these resources might slow down a guest domain in the following ways:
Thrashing the cache areas that are shared between strands and are assigned to two guest domains
Overloading memory bandwidth
Unlike CPU and memory resources, disk and network services are usually shared between guest domains. These services are provided to the guest domains by one or more service domains. Carefully consider how to assign and distribute these resources to guest domains. Note that any configuration that permits maximum performance and resource utilization simultaneously minimizes the risk of side effects.
A network link can be saturated or a disk can be overloaded whether exclusively assigned to a domain or shared among domains. Such attacks affect the availability of a service for the duration of the attack. The target of the attack is not compromised and no data is lost. You can easily minimize the effects of this threat, but you should keep it in mind even though it is limited to network and disk resources on Oracle VM Server for SPARC.
Ensure that you assign only required hardware resources to guest domains. Be sure to unassign an unused resource after the resource is no longer required, for example, a network port or DVD drive required only during an installation. By following this practice, you minimize the number of possible entry points for an attacker.
Shared hardware resources such as physical network ports, present a possible target for DoS attacks. To limit the impact of DoS attacks to a single group of guest domains, carefully determine which guest domains share which hardware resources.
For example, guest domains that share hardware resources could be grouped by the same availability or security requirements. Beyond grouping, you can apply different kinds of resource controls.
You must consider how to share disk and network resources. You can mitigate issues by separating disk access through dedicated physical access paths or through dedicated virtual disk services.
All the countermeasures described in this section require that you understand the technical details of your deployment and their security implications. Plan carefully, document well, and keep your architecture as simple as possible. Ensure that you understand the implications of virtualized hardware so that you can prepare to securely deploy the Oracle VM Server for SPARC software.
Logical domains are robust against the effects of sharing CPUs and memory, as little sharing actually occurs. Nevertheless, it is best to apply resource controls such as Solaris resource management within the guest domains. Using these controls protect against bad application behavior for either a virtual or a non-virtualized environment.