red hat enterprise linux-6-virtualization security guide-en-us

Scott Radvan Tahlia RichardsonThanks go to the following people for enabling the creat ion of this guide:Paul Moore Kurt Seifried David Jorm

Red Hat Enterprise Linux 6Virtualization Security Guide

Securing your virtual environment

Red Hat Enterprise Linux 6 Virtualizat ion Security Guide

Securing your virtual environment

Scott RadvanRed Hat Engineering Content [email protected] RichardsonRed Hat Engineering Content [email protected] MooreRed Hat EngineeringKurt SeifriedRed Hat EngineeringDavid JormRed Hat EngineeringThanks go to the fo llowing people for enabling the creation o f this guide:

Legal NoticeCopyright 2012, 2014 Red Hat, Inc.This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0Unported License. If you distribute this document, o r a modified version o f it, you must provideattribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all RedHat trademarks must be removed.Red Hat, as the licensor o f this document, waives the right to enforce, and agrees not to assert,Section 4d o f CC-BY-SA to the fullest extent permitted by applicable law.Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the InfinityLogo, and RHCE are trademarks o f Red Hat, Inc., registered in the United States and o thercountries.Linux is the registered trademark o f Linus Torvalds in the United States and o ther countries.Java is a registered trademark o f Oracle and/or its affiliates.XFS is a trademark o f Silicon Graphics International Corp. or its subsidiaries in the UnitedStates and/or o ther countries.MySQL is a registered trademark o f MySQL AB in the United States, the European Union andother countries.Node.js is an o fficial trademark o f Joyent. Red Hat Software Collections is not fo rmallyrelated to or endorsed by the o fficial Joyent Node.js open source or commercial pro ject.The OpenStack Word Mark and OpenStack Logo are either registered trademarks/servicemarks or trademarks/service marks o f the OpenStack Foundation, in the United States and o thercountries and are used with the OpenStack Foundation's permission. We are not affiliated with,endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.All o ther trademarks are the property o f their respective owners.

AbstractThis guide provides an overview of virtualization security techno logies provided by Red Hat. Italso provides recommendations for securing hosts, guests, and shared infrastructure andresources in virtualized environments.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table of ContentsChapt er 1 . Int roduct ion

1.1. Virtualized and No n-Virtualized Enviro nments1.2. Why Virtualizatio n Security Matters1.3. Leverag ing SELinux with sVirt1.4. Further Reso urces

Chapt er 2 . Host Securit y2.1. Why Ho st Security Matters2.2. Ho st Security Reco mmend ed Practices fo r Red Hat Enterp rise Linux

2.2.1. Sp ecial Co nsid eratio ns fo r Pub lic Clo ud Op erato rs2.3. Ho st Security Reco mmend ed Practices fo r Red Hat Enterp rise Virtualizatio n

2.3.1. Red Hat Enterp rise Virtualizatio n Netwo rk Po rts

Chapt er 3. Guest Securit y3.1. Why Guest Security Matters3.2. Guest Security Reco mmend ed Practices

Chapt er 4 . sVirt4.1. Intro d uctio n4.2. SELinux and Mand ato ry Access Co ntro l (MAC)4.3. sVirt Co nfig uratio n4.4. sVirt Lab eling

4.4.1. Typ es o f sVirt Lab els4.4.2. Dynamic Co nfig uratio n4.4.3. Dynamic Co nfig uratio n with Base Lab eling4.4.4. Static Co nfig uratio n with Dynamic Reso urce Lab eling4.4.5. Static Co nfig uratio n witho ut Reso urce Lab eling

Chapt er 5. Net work Securit y in a Virt ualized Environment5.1. Netwo rk Security Overview5.2. Netwo rk Security Reco mmend ed Practices

5.2.1. Securing Co nnectivity to Sp ice5.2.2. Securing Co nnectivity to Sto rag e

Appendix A. Furt her Informat ionA.1. SELinux and sVirtA.2. Virtualizatio n Security

Appendix B. Revision Hist ory

22344

666777

999

1 0101011121212131313

1 515151515

1 61616

1 7

T able of Cont ent s

1

Chapter 1. Introduction

1.1. Virtualized and Non-Virtualized EnvironmentsA virtualized environment presents opportunities for both the discovery of new attack vectors and therefinement of existing exploits that may not previously have presented value to an attacker. It istherefore important to take steps to ensure the security of both the physical hosts and the guestsrunning on them when creating and maintaining virtual machines.

Non-Virtualiz ed Environment

In a non-virtualized environment, hosts are separated from each other physically and each host hasa self-contained environment, consisting of services such as a web server, or a DNS server. Theseservices communicate directly to their own user space, host kernel and physical host, offering theirservices directly to the network. The following image represents a non-virtualized environment:

Figure 1.1. Non-Virtualiz ed Environment

Virtualiz ed Environment

In a virtualized environment, several operating systems can be housed (as "guests") within a singlehost kernel and physical host. The following image represents a virtualized environment:

Virt ualizat ion Securit y Guide

2

Figure 1.2. Virtualiz ed Environment

When services are not virtualized, machines are physically separated. Any exploit is therefore usuallycontained to the affected machine, with the obvious exception of network attacks. When services aregrouped together in a virtualized environment, extra vulnerabilities emerge in the system. If there is asecurity flaw in the hypervisor that can be exploited by a guest instance, this guest may be able tonot only attack the host, but also other guests running on that host. This is not theoretical; attacksalready exist on hypervisors. These attacks can extend beyond the guest instance and could exposeother guests to attack.

1.2. Why Virtualizat ion Securit y Mat tersDeploying virtualization in your infrastructure provides many benefits but can also introduce newrisks. Virtualized resources and services should be deployed with the following securityconsiderations:

The host/hypervisor become prime targets; they are often a single point of failure for guests anddata.

Virtual machines can interfere with each other in undesirable ways. Assuming no access controlswere in place to help prevent this, one malicious guest could bypass a vulnerable hypervisor anddirectly access other resources on the host system, such as the storage of other guests.

Resources and services can become difficult to track and maintain; with rapid deployment ofvirtualized systems comes an increased need for management of resources, including sufficientpatching, monitoring and maintenance.

Technical staff may lack knowledge, have gaps in skill sets, and have minimal experience invirtual environments. This is often a gateway to vulnerabilities.

Resources such as storage can be spread across, and dependent upon, several machines. Thiscan lead to overly complex environments, and poorly-managed and maintained systems.

Virtualization does not remove any of the traditional security risks present in your environment;the entire solution stack, not just the virtualization layer, must be secured.

Chapt er 1 . Int roduct ion

3

This guide aims to assist you in mitigating your security risks by offering a number of virtualizationrecommended practices for Red Hat Enterprise Linux and Red Hat Enterprise Virtualization that willhelp you secure your virtualized infrastructure.

1.3. Leveraging SELinux with sVirtsVirt integrates virtualization into the existing security framework provided by SELinux (Security-Enhanced Linux), applying Mandatory Access Control (MAC) to virtual machines. The main objectiveof sVirt is to protect hosts and guests from attacks via security vulnerabilities in the hypervisor.SELinux secures a system by applying access policy across different processes. sVirt extends thiscapability to hosts and guests by treating each guest as a process, allowing administrators to applysimilar policies designed to prevent malicious guests from accessing restricted resources. For moreinformation on sVirt, refer to Chapter 4, sVirt.

1.4 . Further ResourcesRed Hat offers a wealth of documentation solutions across its virtualization products. Coverage ofRed Hat Enterprise Linux and its inbuilt virtualization products includes:

Red Hat Enterprise Linux Virtualization Getting Started Guide: This guide provides an introductionto virtualization concepts, advantages, and tools, and an overview of Red Hat virtualizationdocumentation and products.

Red Hat Enterprise Linux Virtualization Host Configuration and Guest Installation Guide: This guidecovers the installation of virtualization software and configuration of guest machines on avirtualization host.

Red Hat Enterprise Linux Virtualization Administration Guide: This guide covers administration ofhosts, networking, storage, device and guest management using either virt-manager or virsh, alibvirt and QEMU reference, and troubleshooting information.

Red Hat Enterprise Linux Virtualization Security Guide: This guide provides an overview ofvirtualization security technologies provided by Red Hat. Also included are recommendations forsecuring hosts, guests, and shared infrastructure and resources in virtualized environments.

Red Hat Enterprise Linux Virtualization Tuning and Optimization Guide: This guide provides tips,tricks and suggestions for making full use of virtualization performance features and options foryour systems and guest virtual machines.

Red Hat Enterprise Linux V2V Guide describes importing virtual machines from KVM, Xen andVMware ESX/ESX(i) hypervisors to Red Hat Enterprise Virtualization and KVM managed by libvirt.

The Red Hat Enterprise Virtualization documentation suite provides information on installation,development of applications, configuration and usage of the Red Hat Enterprise Virtualizationplatform and its related products.

Red Hat Enterprise Virtualization Installation Guide: This guide describes how to prepare for and setup a Red Hat Enterprise Virtualization environment, and how to upgrade a Red Hat EnterpriseVirtualization environment to the latest release. It also outlines how to set up hypervisors andperform initial configuration of a Red Hat Enterprise Virtualization environment.

Red Hat Enterprise Virtualization Administration Guide: This guide describes how to configure andadminister a Red Hat Enterprise Virtualization environment after that environment has been set upfor the first time, including how to add hypervisors, storage domains, and external providers to theenvironment, how to manage resources such as virtual machines, virtual disks, and templates,and how to take and restore backups.


4

Red Hat Enterprise Virtualization User Guide: This guide describes how to use the User Portal of aRed Hat Enterprise Virtualization environment, including the functionality provided by the Basicand Extended tabs, how to create and work with virtual machines and templates, and how tomonitor resource usage.

Red Hat Enterprise Virtualization Technical Guide: This guide describes how to use the REST API,the Python and Java software development kits, and command-line tools specific to Red HatEnterprise Virtualization. It also outlines the underlying technical concepts behind Red HatEnterprise Virtualization.

Red Hat Enterprise Virtualization Manager Release Notes: This guide contains information on theRed Hat Enterprise Virtualization Manager specific to the current release.

Red Hat Enterprise Virtualization Technical Notes: This guide describes the changes that havebeen made made between the current release and the previous release.

NoteAll of the guides for these products are available at the Red Hat Customer Portal:https://access.redhat.com/site/documentation/

Chapt er 1 . Int roduct ion

5

Chapter 2. Host Security

2.1. Why Host Securit y Mat tersWhen deploying virtualization technologies, the security of the host should be paramount. The RedHat Enterprise Linux host system is responsible for managing and controlling access to the physicaldevices, storage and network as well as all virtualized guests themselves. If the host system were tobe compromised, not only would the host system be vulnerable, but so would the guests and theirdata.

Virtualized guests are only as secure as their host system; securing the Red Hat Enterprise Linux hostsystem is the first step towards ensuring a secure virtualization platform.

2.2. Host Securit y Recommended Pract ices for Red Hat EnterpriseLinuxWith host security being such a critical part of a secure virtualization infrastructure, the followingrecommended practices should serve as a starting point for securing a Red Hat Enterprise Linux hostsystem:

Run only the services necessary to support the use and management of your guest systems. Ifyou need to provide additional services, such as file or print services, you should considerrunning those services on a Red Hat Enterprise Linux guest.

Limit direct access to the system to only those users who have a need to manage the system.Consider disallowing shared root access and instead use tools such as sudo to grant privilegedaccess to administrators based on their administrative roles.

Ensure that SELinux is configured properly for your installation and is operating in enforcingmode. Besides being a good security practice, the advanced virtualization security functionalityprovided by sVirt relies on SELinux. Refer to Chapter 4, sVirt for more information on SELinux andsVirt.

Ensure that auditing is enabled on the host system and that libvirt is configured to emit auditrecords. When auditing is enabled, libvirt will generate audit records for changes to guestconfiguration as well start/stop events which help you track the guest's state. In addition to thestandard audit log inspection tools, the libvirt audit events can also be viewed using thespecialized auvirt tool.

Ensure that any remote management of the system takes place only over secured networkchannels. Tools such as SSH and network protocols such as TLS or SSL provide bothauthentication and data encryption to help ensure that only approved administrators canmanage the system remotely.

Ensure that the firewall is configured properly for your installation and is activated at boot. Onlythose network ports needed for the use and management of the system should be allowed.

Refrain from granting guests direct access to entire disks or block devices (for example, /dev/sdb); instead, use partitions (for example, /dev/sdb1) or LVM volumes for guest storage.

Ensure that staff have adequate training and knowledge in virtual environments.


6

WarningAttaching a USB device, Physical Function or physical device when SR-IOV is not available toa virtual machine could provide access to the device which is sufficient enough to over-writethat device's firmware. This presents a potential security issue by which an attacker couldover-write the device's firmware with malicious code and cause problems when moving thedevice between virtual machines or at host boot time. It is advised to use SR-IOV VirtualFunction device assignment where applicable.

NoteThe objective of this guide is to explain the unique security-related challenges, vulnerabilities,and solutions that are present in most virtualized environments, and the recommended methodof addressing them. However, there are a number of recommended practices to follow whensecuring a Red Hat Enterprise Linux system that apply regardless of whether the system is astandalone, virtualization host, or guest instance. These recommended practices includeprocedures such as system updates, password security, encryption, and firewallconfiguration. This information is discussed in more detail in the Red Hat Enterprise LinuxSecurity Guide which can be found at https://access.redhat.com/site/documentation/.

2.2.1. Special Considerat ions for Public Cloud OperatorsPublic cloud service providers are exposed to a number of security risks beyond that of thetraditional virtualization user. Virtual guest isolation, both between the host and guest as well asbetween guests, is critical due to the threat of malicious guests and the requirements on customerdata confidentiality and integrity across the virtualization infrastructure.

In addition to the Red Hat Enterprise Linux virtualization recommended practices previously listed,public cloud operators should also consider the following items:

Disallow any direct hardware access from the guest. PCI, USB, FireWire, Thunderbolt, eSATA andother device passthrough mechanisms not only make management difficult, but often rely on theunderlying hardware to enforce separation between the guests.

Isolate the cloud operator's private management network from the customer guest network, andcustomer networks from one another, so that:

the guests can not access the host systems over the network.

one customer can not access another customer's guest systems directly via the cloudprovider's internal network.

2.3. Host Securit y Recommended Pract ices for Red Hat EnterpriseVirtualizat ion

2.3.1. Red Hat Enterprise Virtualizat ion Network PortsRed Hat Enterprise Virtualization uses various network ports for management and other virtualizationfeatures. These ports must be open for Red Hat Enterprise Linux to function as a host with Red HatEnterprise Virtualization. The list below covers ports and their usage by Red Hat EnterpriseVirtualization:

Chapt er 2 . Host Securit y

7

Incoming ICMP echo requests and outgoing ICMP echo replies must be allowed.

Port 22 (TCP) should be open for SSH access and the initial installation.

Port 161 (UDP) is required for SNMP (Simple Network Management Protocol).

Ports 5900 to 65535 (TCP) are used for guest console access.

Ports 80 or 443 (TCP), depending on the security settings on the Manager, are used by the vdsm-reg service to communicate information about the host.

Port 16514 (TLS) or port 16509 (TCP) is used to support migration communication generated bylibvirt.

Ports 49152 to 49215 (TCP) are used for migrations. Migration may use any port in this rangedepending on the number of concurrent migrations occurring.

Port 54321 (TCP) is used by default, by VDSM for management, storage and inter-hostcommunication. This port can be modified.

WarningTake special care to filter SNMP on port 161 (UDP) at the border of your network unless it isabsolutely necessary to externally manage devices.


8

Chapter 3. Guest Security

3.1. Why Guest Securit y Mat tersWhile the security of the host system is critical in ensuring the security of the guests running on thehost, it does not remove the need for properly securing the individual guest machines. All of thesecurity risks associated with a conventional, non-virtualized system still exist when the system is runas a virtualized guest. Any resources accessible to the guest system, such as critical business dataor sensitive customer information, could be made vulnerable if the guest system were to becompromised.

3.2. Guest Securit y Recommended Pract icesAll of the recommended practices for securing a Red Hat Enterprise Linux system documented in theRed Hat Enterprise Linux Security Guide apply to conventional, non-virtualized systems as well assystems installed as a virtualized guest. However, there are a few security practices which are ofcritical importance when running guests in a virtualized environment:

With all management of the guest likely taking place remotely, ensure that the management of thesystem takes place only over secured network channels. Tools such as SSH and networkprotocols such as TLS or SSL provide both authentication and data encryption to ensure thatonly approved administrators can manage the system remotely.

Some virtualization technologies use special guest agents or drivers to enable somevirtualization specific features. Ensure that these agents and applications are secured using thestandard Red Hat Enterprise Linux security features, e.g. SELinux.

In virtualized environments there is a greater risk of sensitive data being accessed outside theprotection boundaries of the guest system. Protect stored sensitive data using encryption toolssuch as dm-crypt and GnuPG ; although special care needs to be taken to ensure theconfidentiality of the encryption keys.

Chapt er 3. Guest Securit y

9

Chapter 4. sVirt

4.1. Int roduct ionSince virtual machines under KVM are implemented as Linux processes, KVM leverages the standardLinux security model to provide isolation and resource controls. The Linux kernel includes SELinux(Security-Enhanced Linux), a project developed by the US National Security Agency to addmandatory access control (MAC), multi-level security (MLS) and multi-category security (MCS)through a flexible and customizable security policy. SELinux provides strict resource isolation andconfinement for processes running on top of the Linux kernel, including virtual machine processes.The sVirt project builds upon SELinux to further facilitate virtual machine isolation and controlledsharing. For example, fine-grained permissions could be applied to group virtual machines togetherto share resources.

From a security point of view, the hypervisor is a tempting target for attackers, as a compromisedhypervisor could lead to the compromise of all virtual machines running on the host system.Integrating SELinux into virtualization technologies helps improve hypervisor security againstmalicious virtual machines trying to gain access to the host system or other virtual machines.

Refer to the following image which represents isolated guests, limiting the ability for a compromisedhypervisor (or guest) to launch further attacks, or to extend to another instance:

Figure 4 .1. At tack path iso lated by SELinux

NoteFor more information on SELinux, refer to Red Hat Enterprise Linux Security-Enhanced Linux athttps://access.redhat.com/site/documentation/.

4.2. SELinux and Mandatory Access Cont rol (MAC)Security-Enhanced Linux (SELinux) is an implementation of MAC in the Linux kernel, checking for


10

allowed operations after standard discretionary access controls (DAC) are checked. SELinux canenforce a user-customizable security policy on running processes and their actions, includingattempts to access file system objects. Enabled by default in Red Hat Enterprise Linux, SELinux limitsthe scope of potential damage that can result from the exploitation of vulnerabilities in applicationsand system services, such as the hypervisor.

sVirt integrates with libvirt, a virtualization management abstraction layer, to provide a MACframework for virtual machines. This architecture allows all virtualization platforms supported bylibvirt and all MAC implementations supported by sVirt to interoperate.

4.3. sVirt Configurat ionSELinux Booleans are variables that can be toggled on or off, quickly enabling or disabling featuresor other special conditions. Booleans can be toggled by running either setsebool boolean_name {on|off} for a temporary change, or setsebool -P boolean_name {on|off} to make the change persistent across reboots.

The following table shows the SELinux Boolean values that affect KVM when launched by libvirt. Thecurrent state of these booleans (on or off) can be found by running the command getsebool -a|grep virt.

Table 4 .1. KVM SELinux Booleans

SELinux Boolean Descript ionstaff_use_svirt Allow staff user to create and transition to sVirt

domains.unprivuser_use_svirt Allow unprivileged user to create and transition

to sVirt domains.virt_sandbox_use_audit Allow sandbox containers to send audit

messages.virt_sandbox_use_netlink Allow sandbox containers to use netlink system

calls.virt_sandbox_use_sys_admin Allow sandbox containers to use sys_admin

system calls, e.g. mount.virt_transition_userdomain Allow virtual processes to run as userdomains.virt_use_comm Allow virt to use serial/parallel communication

ports.virt_use_execmem Allow confined virtual guests to use executable

memory and executable stack.virt_use_fusefs Allow virt to read FUSE mounted files.virt_use_nfs Allow virt to manage NFS mounted files.virt_use_rawip Allow virt to interact with rawip sockets.virt_use_samba Allow virt to manage CIFS mounted files.virt_use_sanlock Allow confined virtual guests to interact with the

sanlock.virt_use_usb Allow virt to use USB devices.virt_use_xserver Allow virtual machine to interact with the X

Window System.

Chapt er 4 . sVirt

11

NoteFor more information on SELinux Booleans, refer to Red Hat Enterprise Linux Security EnhancedLinux at https://access.redhat.com/site/documentation/.

4.4 . sVirt LabelingLike other services under the protection of SELinux, sVirt uses process based mechanisms, labelsand restrictions to provide extra security and control over guest instances. Labels are appliedautomatically to resources on the system based on the currently running virtual machines (dynamic),but can also be manually specified by the administrator (static), to meet any specific requirementsthat may exist.

4 .4 .1. T ypes of sVirt LabelsThe following table outlines the different sVirt labels that can be assigned to resources such asvirtual machine processes, image files and shared content:

Table 4 .2. sVirt Labels

Type SELinux Context Descript ion/Ef fectVirtual Machine Processes system_u:system_r:svirt_t:MCS1 MCS1 is a randomly selected

field. Currently approximately500,000 labels are supported.

Virtual Machine Image system_u:object_r:svirt_image_t:MCS1

Only svirt_t processes with thesame MCS1 fields are able toread/write these image files anddevices.

Virtual Machine SharedRead/Write Content

system_u:object_r:svirt_image_t:s0

All svirt_t processes are allowedto write to the svirt_image_t:s0files and devices.

Virtual Machine SharedShared Read Only content

system_u:object_r:svirt_content_t:s0

All svirt_t processes are able toread files/devices with thislabel.

Virtual Machine Image system_u:object_r:virt_content_t:s0

System default label used whenan image exits. No svirt_t virtualprocesses are allowed to readfiles/devices with this label.

4 .4 .2. Dynamic Configurat ionDynamic label configuration is the default labeling option when using sVirt with SELinux. Refer to thefollowing example which demonstrates dynamic labeling:

# ps -eZ | grep qemu-kvm

system_u:system_r:svirt_t:s0:c87,c520 27950 ? 00:00:17 qemu-kvm

In this example, the qemu-kvm process has a base label of system_u:system_r:svirt_t:s0 .The libvirt system has generated a unique MCS label of c87,c520 for this process. The base labeland the MCS label are combined to form the complete security label for the process. Likewise, libvirt


12

takes the same MCS label and base label to form the image label. This image label is thenautomatically applied to all host files that the VM is required to access, such as disk images, diskdevices, PCI devices, USB devices, and kernel/initrd files. Each process is isolated from other virtualmachines with different labels.

The following example shows the virtual machine's unique security label (with a corresponding MCSlabel of c87,c520 in this case) as applied to the guest disk image file in /var/lib/libvirt/images:

# ls -lZ /var/lib/libvirt/images/*

system_u:object_r:svirt_image_t:s0:c87,c520 image1

The following example shows dynamic labeling in the XML configuration for the guest:

system_u:system_r:svirt_t:s0:c87,c520 system_u:object_r:svirt_image_t:s0:c87,c520

4 .4 .3. Dynamic Configurat ion with Base LabelingTo override the default base security label in dynamic mode, the option can beconfigured manually in the XML guest configuration, as shown in this example:

system_u:system_r:svirt_custom_t:s0 system_u:system_r:svirt_custom_t:s0:c87,c520 system_u:object_r:svirt_image_t:s0:c87,c520

4 .4 .4 . Stat ic Configurat ion with Dynamic Resource LabelingSome applications require full control over the generation of security labels but still require libvirt totake care of resource labeling. The following guest XML configuration demonstrates an example ofstatic configuration with dynamic resource labeling:

system_u:system_r:svirt_custom_t:s0:c87,c520

4 .4 .5. Stat ic Configurat ion without Resource LabelingPrimarily used in MLS (multi-level security) or otherwise strictly controlled environments, staticconfiguration without resource relabeling is possible. Static labels allow the administrator to select aspecific label, including the MCS/MLS field, for a virtual machine. Administrators who run statically-labeled virtual machines are responsible for setting the correct label on the image files. The virtualmachine will always be started with that label, and the sVirt system will never modify the label of astatically-labelled virtual machine's content. The following guest XML configuration demonstrates anexample of this scenario:

Chapt er 4 . sVirt

13

system_u:system_r:svirt_custom_t:s0:c87,c520


14

Chapter 5. Network Security in a Virtualized Environment

5.1. Network Securit y OverviewIn almost all situations, the network is the only way to access systems, applications and managementinterfaces. As networking plays such a critical role in the management of virtualized systems and theavailability of their hosted applications, it is very important to ensure that the network channels bothto and from the virtualized systems are secure.

Securing the network allows administrators to control access and protect sensitive data frominformation leaks and tampering.

5.2. Network Securit y Recommended Pract icesNetwork security is a critical part of a secure virtualization infrastructure. Refer to the followingrecommended practices for securing the network:

Ensure that remote management of the system takes place only over secured network channels.Tools such as SSH and network protocols such as TLS or SSL provide both authentication anddata encryption to assist with secure and controlled access to systems.

Ensure that guest applications transferring sensitive data do so over secured network channels. Ifprotocols such as TLS or SSL are not available, consider using one like IPsec.

Configure firewalls and ensure they are activated at boot. Only those network ports needed for theuse and management of the system should be allowed. Test and review firewall rules regularly.

5.2.1. Securing Connect ivity to SpiceThe Spice remote desktop protocol supports SSL/TLS which should be enabled for all of the Spicecommunication channels (main, display, inputs, cursor, playback, record).

5.2.2. Securing Connect ivity to StorageYou can connect virtualized systems to networked storage in many different ways. Each approachpresents different security benefits and concerns, however the same security principles apply to each:authenticate the remote store pool before use, and protect the confidentiality and integrity of the datawhile it is being transferred.

The data must also remain secure while it is stored. Red Hat recommends data be encrypted and/ordigitally signed before storing.

NoteFor more information on networked storage, refer to the Storage Concepts chapter of the RedHat Enterprise Linux Virtualization Administration Guide athttps://access.redhat.com/site/documentation/.

Chapt er 5. Net work Securit y in a Virt ualized Environment

15

Appendix A. Further Information

A.1. SELinux and sVirtFurther information on SELinux and sVirt:

Main SELinux website: http://www.nsa.gov/research/selinux/index.shtml.

SELinux documentation: http://www.nsa.gov/research/selinux/docs.shtml.

Main sVirt website: http://selinuxproject.org/page/SVirt.

Dan Walsh's blog: http://danwalsh.livejournal.com/.

The unofficial SELinux FAQ: http://www.crypt.gen.nz/selinux/faq.html.

A.2. Virtualizat ion Securit yFurther information on virtualization security:

NIST (National Institute of Standards and Technology) full virtualization security guidelines:http://www.nist.gov/itl/csd/virtual-020111.cfm.


16

Appendix B. Revision HistoryRevision 0.4 -29 Tue Jul 14 2015 Laura Novich

Preparing for 6.7 General Availability Release

Revision 0.4 -28 Mon Jul 14 2015 Jiri HerrmannVersion for 6.7 GA release

Revision 0.4 -26 Fri Apr 17 2015 Laura NovichPreparing document for 6.7 Beta publication.




Revision 0.4 -22 Thu Apr 16 2015 Laura NovichPreparing document for 6.7 Beta publication.

Revision 0.4 -21 Fri Oct 10 2014 Scot t RadvanVersion for 6.6 GA release.

Revision 0.4 -20 Fri Oct 10 2014 Scot t RadvanAdd warning admonition regarding USB and PF security vulnerability (BZ#1150077).

Revision 0.4 -19 Wed May 14 2014 Tahlia RichardsonUpdated booleans list (BZ#1093284).Applied Docs QE feedback (BZ#1093286, BZ#1097058).

Revision 0.4 -18 Tues Nov 19 2013 Tahlia RichardsonVersion for 6.5 GA release.

Revision 0.4 -17 Mon Sept 30 2013 Tahlia RichardsonRemoved the Hypervisor Deployment Guide from the doc suite list.Publishing with the updated docs suite list and updated links (changed previously).

Revision 0.4 -16 Sun Feb 17 2013 Scot t RadvanVersion for 6.4 GA release.

Revision 0.4 -15 Wed Feb 13 2013 Scot t RadvanReview for 6.4 release.

Revision 0.4 -14 Tue Jan 22 2013 Scot t RadvanAdd `Further Resources` to Introduction.

Revision 0.4 -13 Tue Jan 22 2013 Scot t Radvan


17

Review for 6.4 release.

Revision 0.4 -12 Sun Nov 25 2012 Scot t RadvanBoolean descriptions now match those from the 'semanage boolean -l' command.

Revision 0.4 -11 Sun Oct 28 2012 Scot t Radvanfix subtitle

Revision 0.4 -10 Tue Oct 16 2012 Scot t RadvanReview for 6.4 accuracy.

Revision 0.4 -9 Thu Sep 27 2012 Scot t RadvanCorrect links to new docs site.

Revision 0.4 -08 Fri Ju l 20 2012 Laura BaileyEnsuring that the document complies with word usage policy.

Revision 0.4 -07 Sun Jun 17 2012 Scot t RadvanPublish for 6.3 GA release.

Revision 0.4 -06 Fri Jun 15 2012 Scot t RadvanRemove draft watermark, prepare for 6.3 branch.

Revision 0.4 -05 Fri Jun 08 2012 Scot t RadvanStatic labeling example output re-ordered.

Revision 0.4 -04 Fri Jun 08 2012 Scot t RadvanMinor fixes from SME review.

Revision 0.4 -03 Tue Jun 05 2012 Scot t RadvanAdd fixes from QE review (BZ#828032).

Revision 0.4 -02 Mon Jun 04 2012 Scot t RadvanInclude Further Information chapter, add contributors and links.

Revision 0.4 -01 Mon Jun 04 2012 Scot t RadvanBump major, performed proof and minor edits.

Revision 0.2-06 Wed May 30 2012 Scot t RadvanInitial work on 'Chapter 5 - Network Security in a Virtualized Environment'.

Revision 0.2-05 Tue May 15 2012 Scot t RadvanAdd note about root access in guests not being desirable, to Guest_Security.xml

Revision 0.2-04 Mon May 14 2012 Scot t RadvanAdd warning about SNMP at network border.

Revision 0.2-03 Mon May 14 2012 Scot t Radvan


18

Add `Guest Security' sections. Expand Network Ports to specify Echo Request (ping) and TCP/UDP.Include additional passthrough mechanisms for public cloud recommendations. Expand Booleansto specify mounted file systems.

Revision 0.2-02 Tue May 08 2012 Scot t Radvans/Overview/Introduction

Revision 0.2-01 Tue May 08 2012 Scot t RadvanBump major. Added SME content for `Host Security' chapter and performed edits/proof.

Revision 0.1-15 Thu Mar 29 2012 Scot t RadvanImport `Red Hat Enterprise Virtualization Network Ports' section to Host_Security.xml.

Revision 0.1-14 Thu Mar 29 2012 Scot t RadvanRename titles for Best Practices sections. Re-wording of Best Practices.

Revision 0.1-13 Wed Mar 28 2012 Scot t RadvanBuild with new version of publishing toolchain.

Revision 0.1-12 Mon Mar 20 2012 Scot t RadvanInitial publish of new section: `1.2. Why Virtualization Security Matters' for SME review.

Revision 0.1-11 Mon Mar 20 2012 Scot t RadvanMove `Best Host Security Practices for Red Hat Enterprise Linux' to `Host Security' chapter.

Revision 0.1-10 Mon Mar 20 2012 Scot t RadvanMajor SME-assisted restructure of TOC.

Revision 0.1-09 Mon Feb 14 2012 Scot t RadvanIntroduction wording.

Revision 0.1-08 Mon Feb 13 2012 Scot t RadvanNew version of publishing tool.

Revision 0.1-07 Tue Feb 01 2012 Scot t RadvanPublish for SME review of sVirt chapter.

Revision 0.1-06 Tue Jan 31 2012 Scot t RadvanAdd draft watermark to denote development/internal status.

Revision 0.1-05 Mon Jan 30 2012 Scot t RadvanAdditions to Introduction. Arrange sVirt labeling sections. Add admonition regarding systemhardening topics that this guide does not cover. Introduce dynamic labeling.

Revision 0.1-04 Mon Jan 30 2012 Scot t RadvanMinor wording updates to sVirt chapter. Restructure and improve flow of Chapter 1: Introduction.

Revision 0.1-03 Fri Jan 20 2012 Scot t RadvanFurther restructure sVirt chapter. Incorporate initial developer feedback/fixes.

Revision 0.1-02 Tue Jan 17 2012 Scot t Radvan


19

Major restructure of document flow. Make file names consistent.

Revision 0.1-01 Tue Jan 17 2012 Scot t RadvanInitial creation of book. Import existing text/remarks.


20

Table of ContentsChapter1.Introduction1.1.Virtualized and Non-Virtualized Environments1.2.Why Virtualization Security Matters1.3.Leveraging SELinux with sVirt1.4.Further Resources

Chapter2.Host Security2.1.Why Host Security Matters2.2.Host Security Recommended Practices for Red Hat Enterprise Linux2.2.1.Special Considerations for Public Cloud Operators

2.3.Host Security Recommended Practices for Red Hat Enterprise Virtualization2.3.1.Red Hat Enterprise Virtualization Network Ports

Chapter3.Guest Security3.1.Why Guest Security Matters3.2.Guest Security Recommended Practices

Chapter4.sVirt4.1.Introduction4.2.SELinux and Mandatory Access Control (MAC)4.3.sVirt Configuration4.4.sVirt Labeling4.4.1.Types of sVirt Labels4.4.2.Dynamic Configuration4.4.3.Dynamic Configuration with Base Labeling4.4.4.Static Configuration with Dynamic Resource Labeling4.4.5.Static Configuration without Resource Labeling

Chapter5.Network Security in a Virtualized Environment5.1.Network Security Overview5.2.Network Security Recommended Practices5.2.1.Securing Connectivity to Spice5.2.2.Securing Connectivity to Storage

AppendixA.Further InformationA.1.SELinux and sVirtA.2.Virtualization Security

AppendixB.Revision History

red hat enterprise linux-6-virtualization security guide-en-us

Documents

trademarks o f red hat

creation o f

property o f

licensor o f

o thercountries

o fficial trademark

modified version o f

o ther trademarks