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
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
A service domain provides some virtual services to guest domains on the system. Services might include a virtual switch, virtual disk, or virtual console service.
Figure 1–6 shows an example service domain that offers console services. Often the control domain hosts the console services, and thus is also a service domain. The execution environment domains often combine the functions of a control domain, I/O domain, and service domain in one or two domains.
An attacker who gains control of a service domain can manipulate data or listen to any communication that occurs through the offered services. This control might include console access to guest domains, access to network services, or access to disk services.
While the attack strategies are the same as for an attack on the control domain, the possible damage is less because the attacker cannot modify the system configuration. The resulting damage might include the theft or manipulation of data that is being offered by the service domain but not manipulation of any data sources. Depending on the service, an attacker might be required to exchange kernel modules.
Figure 6 - Service Domain Example
If possible, have each service domain offer only one service to its clients. This configuration guarantees that only one service can be compromised if a service domain is breached. However, be sure to weigh the importance of this type of configuration against the additional complexity. Note that having redundant I/O domains is highly recommended.
You can isolate both Oracle Solaris 10 and Oracle Solaris 11 service domains from guest domains. The following solutions are shown in the preferred order of implementation:
Ensure that the service domain and the guest domain do not share the same network port. Also, do not plumb any virtual switch interface on the service domain. For Oracle Solaris 11 service domains, do not plumb any VNICs on the physical ports that are used for virtual switches.
If you must use the same network port for both the Oracle Solaris 10 OS and Oracle Solaris 11 OS, place the I/O domain traffic in a VLAN that is not used by guest domains.
If you cannot implement either of the previous solutions, do not plumb the virtual switch in the Oracle Solaris 10 OS and apply IP filters in the Oracle Solaris 11 OS.
Ensure that access to individual virtual consoles is limited to only those users that must access them. This configuration ensures that no single administrator has access to all consoles, which prevents access to consoles other than those assigned to a compromised account. See How to Create Default Services in Oracle VM Server for SPARC 3.1 Administration Guide .