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
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
Countermeasure: Securing the Guest Domain OS
Chapter 2 Secure Installation and Configuration of Oracle VM Server for SPARC
Any domain that has direct access to physical I/O devices such as network ports or disks is an I/O domain. For information about configuring I/O domains, see Chapter 6, Setting Up I/O Domains, in Oracle VM Server for SPARC 3.1 Administration Guide .
An I/O domain also might be a service domain if it provides I/O services to guest domains, which gives the domains access to the hardware.
An attacker who blocks the I/O services of an I/O domain ensures that all dependent guest domains are equally blocked. A successful DoS attack might be achieved by overloading the back-end network or disk infrastructure or by injecting a fault into the domain. Either attack might force the domain to hang or panic. Likewise, an attacker who suspends a service domain's services causes any guest domain that depends on these services to immediately hang. If the guest domain hangs, it will resume operation when the I/O service resumes.
DoS attacks are commonly made over the network. Such an attack can be successful because network ports are open for communication and can be overwhelmed by network traffic. A resulting loss of service blocks dependent guest domains. A similar attack on disk resources might be made by means of the SAN infrastructure or by attacking the I/O domain. The only damage is a temporary halt of all dependent guest domains. While the impact of DoS tasks might be substantial, data is neither compromised nor lost, and the system configuration remains intact.
Configuring multiple I/O domains reduces the impact of one domain failing or being compromised. You can assign individual PCIe slots to a guest domain to give it I/O domain capabilities. If the root domain that owns the PCIe bus crashes, that bus is reset, which leads to a subsequent crash of the domain that was assigned the individual slot. This feature does not fully eliminate the need for two root domains that each own a separate PCIe bus.
High availability also contributes to enhanced security because it ensures that services can withstand denial-of-service attacks. The Oracle VM Server for SPARC implements high availability methodologies such as using redundant disk and network resources in redundant I/O domains. This configuration option enables rolling upgrades of the I/O domains and protects against the impact of a failed I/O domain due to a successful DoS attack. With the advent of SR-IOV, guest domains can have direct access to individual I/O devices. However, when SR-IOV is not an option, consider creating redundant I/O domains. See Countermeasure: Granularly Segregating Service Domains.
An I/O domain has direct access to back-end devices, usually disks, which it virtualizes and then offers to guest domains. A successful attacker has full access to these devices and can read sensitive data or manipulate software on the boot disks of the guest domains.
An I/O domain attack is as likely as a successful attack on a service domain or the control domain. The I/O domain is an attractive target given the potential access to a large number of disk devices. Therefore, consider this threat when dealing with sensitive data in a guest domain that runs on virtualized disks.
When an I/O domain is compromised, the attacker has full access to the guest domain's virtual disks.
Protect the contents of the virtual disks by doing the following:
Encrypting the contents of the virtual disks. On Oracle Solaris 10 systems, you might use an application that can encrypt its own data, such as pgp/gpg or Oracle 11g encrypted tablespaces. On Oracle Solaris 11 systems, you might use ZFS encrypted datasets to provide transparent encryption of all data stored in the file system.
Distributing the data over several virtual disks across different I/O domains. A guest domain might create a striped (RAID 1/RAID 5) volume that stripes over several virtual disks that are obtained from two I/O domains. If one of these I/O domains is compromised, the attacker would have difficulty making use of the portion of the data that is available.