Red Hat Enterprise Linux 6
Virtualization Security Guide
Securing your virtual environment
Scott Radvan
Red Hat Enterprise Linux 6 Virtualization Security Guide
Securing your virtual environment
Scott Radvan
Red Hat, Inc. Engineering Content Services
sradvan@redhat.com
Legal Notice
Copyright © 2013 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported
License. If you distribute this document, or a modified version of it, you must provide attribution to Red
Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be
removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or
endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries 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 other trademarks are the property of their respective owners.
Abstract
This guide provides an overview of virtualization security technologies provided by Red Hat. It also
provides recommendations for securing hosts, guests, and shared infrastructure and resources in
virtualized environments.
Table of Contents
Table of Contents
. . fa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . . .
Pr.e. . ce
1. Document Conventions 3
1.1. Typographic Conventions 3
1.2. Pull-quote Conventions 4
1.3. Notes and Warnings 5
2. Getting Help and Giving Feedback 5
2.1. Do You Need Help? 5
2.2. We Need Feedback! 6
. ha.pt.e. . . . . . oduct . . .
C. . . . r 1.. Int.r . . . . . . ion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7. . . . . . . . . .
1.1. Virtualized and Non-Virtualized Environments 7
1.2. Why Virtualization Security Matters 8
1.3. Leveraging SELinux with sVirt 8
1.4. Further Resources 8
. ha.pt.e. . . . . . . . . . . . .it.y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C. . . . r 2.. Host. Se.cur . 1.0. . . . . . . . . .
2.1. Why Host Security Matters 10
2.2. Host Security Recommended Practices for Red Hat Enterprise Linux 10
2.2.1. Special Considerations for Public Cloud Operators 11
2.3. Host Security Recommended Practices for Red Hat Enterprise Virtualization 11
2.3.1. Red Hat Enterprise Virtualization Network Ports 11
. ha.pt.e. . . . . . ue. . . . . . cur.it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.3. . . . . . . . . .
C. . . . r 3. G . . st Se . . . .y
3.1. Why Guest Security Matters 13
3.2. Guest Security Recommended Practices 13
. ha.pt.e. . . sVirt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C. . . . r 4... . . . . 1.4. . . . . . . . . .
4.1. Introduction 14
4.2. SELinux and Mandatory Access Control (MAC) 14
4.3. sVirt Configuration 15
4.4. sVirt Labeling 15
4.4.1. Types of sVirt Labels 15
4.4.2. Dynamic Configuration 16
4.4.3. Dynamic Configuration with Base Labeling 17
4.4.4. Static Configuration with Dynamic Resource Labeling 17
4.4.5. Static Configuration without Resource Labeling 17
. ha.pt.e. . . . . . wor . . . . . . . . y. . a. Vir .ua . . d Envir . . . . . . . 1.8. . . . . . . . . .
C. . . . r 5.. Ne.t . . . .k Se.curit . in. . . . .t . . liz.e. . . . . . . .onme.nt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1. Network Security Overview 18
5.2. Network Security Recommended Practices 18
5.2.1. Securing Connectivity to Spice 18
5.2.2. Securing Connectivity to Storage 18
. ha.pt.e. . . . . . . the.r. Informa.t.ion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C. . . . r 6.. Fur . . . . . . . . . . . . 1.9. . . . . . . . . .
6.1. Contributors 19
6.2. Other Resources 19
. . vision Hist.ory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Re. . . . . . . . . . . . . 2.0. . . . . . . . . .
1
Red Hat Enterprise Linux 6 Virtualization Security Guide
2
Preface
Preface
1. Document Conventions
This manual uses several conventions to highlight certain words and phrases and draw attention to
specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The
Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative
but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later include the Liberation
Fonts set by default.
1.1. Typographic Conventions
Four typographic conventions are used to call attention to specific words and phrases. These
conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight
keys and key combinations. For example:
To see the contents of the file my_next_bestselling_novel in your current working
directory, enter the cat my_next_bestselling_novel command at the shell prompt
and press Enter to execute the command.
The above includes a file name, a shell command and a key, all presented in mono-spaced bold and all
distinguishable thanks to context.
Key combinations can be distinguished from an individual key by the plus sign that connects each part of
a key combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to a virtual terminal.
The first example highlights a particular key to press. The second example highlights a key combination:
a set of three keys pressed simultaneously.
If source code is discussed, class names, methods, functions, variable names and returned values
mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for
directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialog-box text;
labeled buttons; check-box and radio-button labels; menu titles and submenu titles. For example:
Choose System Preferences Mouse from the main menu bar to launch Mouse
Preferences. In the Buttons tab, select the Left-handed mouse check box and click
Close to switch the primary mouse button from the left to the right (making the mouse
suitable for use in the left hand).
To insert a special character into a gedit file, choose Applications Accessories
3
Red Hat Enterprise Linux 6 Virtualization Security Guide
Character Map from the main menu bar. Next, choose Search Find& from the
Character Map menu bar, type the name of the character in the Search field and click
Next. The character you sought will be highlighted in the Character Table. Double-click
this highlighted character to place it in the Text to copy field and then click the Copy
button. Now switch back to your document and choose Edit Paste from the gedit menu
bar.
The above text includes application names; system-wide menu names and items; application-specific
menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all
distinguishable by context.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable
text. Italics denotes text you do not input literally or displayed text that changes depending on
circumstance. For example:
To connect to a remote machine using ssh, type ssh username@domain.name at a shell
prompt. If the remote machine is example.com and your username on that machine is
john, type ssh john@example.com.
The mount -o remount file-system command remounts the named file system. For
example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It
will return a result as follows: package-version-release.
Note the words in bold italics above: username, domain.name, file-system, package, version and release.
Each word is a placeholder, either for text you enter when issuing a command or for text displayed by
the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and
important term. For example:
Publican is a DocBook publishing system.
1.2. Pull-quote Conventions
Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in mono-spaced roman and presented thus:
books Desktop documentation drafts mss photos stuff svn
books_tests Desktop1 downloads images notes scripts svgs
Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
4
Preface
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
struct kvm_assigned_pci_dev *assigned_dev)
{
int r = 0;
struct kvm_assigned_dev_kernel *match;
mutex_lock(&kvm->lock);
match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
assigned_dev->assigned_dev_id);
if (!match) {
printk(KERN_INFO "%s: device hasn't been assigned before, "
"so cannot be deassigned\n", __func__);
r = -EINVAL;
goto out;
}
kvm_deassign_device(kvm, match);
kvm_free_assigned_device(kvm, match);
out:
mutex_unlock(&kvm->lock);
return r;
}
1.3. Notes and Warnings
Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
Note
Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should
have no negative consequences, but you might miss out on a trick that makes your life easier.
Important
Important boxes detail things that are easily missed: configuration changes that only apply to the
current session, or services that need restarting before an update will apply. Ignoring a box
labeled Important will not cause data loss but may cause irritation and frustration.
Warning
Warnings should not be ignored. Ignoring warnings will most likely cause data loss.
2. Getting Help and Giving Feedback
2.1. Do You Need Help?
If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer
5
Red Hat Enterprise Linux 6 Virtualization Security Guide
Portal at http://access.redhat.com. Through the customer portal, you can:
search or browse through a knowledgebase of technical support articles about Red Hat products.
submit a support case to Red Hat Global Support Services (GSS).
access other product documentation.
Red Hat also hosts a large number of electronic mailing lists for discussion of Red Hat software and
technology. You can find a list of publicly available mailing lists at https://www.redhat.com/mailman/listinfo.
Click on the name of any mailing list to subscribe to that list or to access the list archives.
2.2. We Need Feedback!
If you find a typographical error in this manual, or if you have thought of a way to make this manual
better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/
against the product Red Hat Enterprise Linux 6.
When submitting a bug report, be sure to mention the manual's identifier: doc-
Virtualization_Security_Guide
If you have a suggestion for improving the documentation, try to be as specific as possible when
describing it. If you have found an error, please include the section number and some of the surrounding
text so we can find it easily.
6
Chapter 1. Introduction
Chapter 1. Introduction
1.1. Virtualized and Non-Virtualized Environments
A virtualized environment presents opportunities for both the discovery of new attack vectors and the
refinement of existing exploits that may not previously have presented value to an attacker. It is therefore
important to take steps to ensure the security of both the physical hosts and the guests running on them
when creating and maintaining virtual machines.
Non-Virtualized Environment
In a non-virtualized environment, hosts are separated from each other physically and each host has a
self-contained environment, consisting of services such as a web server, or a DNS server. These
services communicate directly to their own user space, host kernel and physical host, offering their
services directly to the network. The following image represents a non-virtualized environment:
Virtualized Environment
In a virtualized environment, several operating systems can be housed (as "guests") within a single
host kernel and physical host. The following image represents a virtualized environment:
When services are not virtualized, machines are physically separated. Any exploit is therefore usually
contained to the affected machine, with the obvious exception of network attacks. When services are
grouped together in a virtualized environment, extra vulnerabilities emerge in the system. If there is a
security flaw in the hypervisor that can be exploited by a guest instance, this guest may be able to not
only attack the host, but also other guests running on that host. This is not theoretical; attacks already
exist on hypervisors. These attacks can extend beyond the guest instance and could expose other
guests to attack.
7
Red Hat Enterprise Linux 6 Virtualization Security Guide
1.2. Why Virtualization Security Matters
Deploying virtualization in your infrastructure provides many benefits but can also introduce new risks.
Virtualized resources and services should be deployed with the following security considerations:
The host/hypervisor become prime targets; in effect, they are often a single point of failure for guests
and data.
Virtual machines can interfere with each other in undesirable ways.
Resources and services can become difficult to track and maintain; with rapid deployment of
virtualized systems comes an increased need for management of resources, including sufficient
patching, monitoring and maintenance.
There may be a lack of knowledge, gaps in skill sets, and minimal experience among technical staff.
This is often a gateway to vulnerabilities.
Resources such as storage can be spread across, and dependent upon, several machines. This
can 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.
This guide aims to assist you in mitigating your security risks by offering a number of virtualization
recommended practices for Red Hat Enterprise Linux and Red Hat Enterprise Virtualization that will help
you secure your virtualized infrastructure.
1.3. Leveraging SELinux with sVirt
sVirt integrates virtualization into the existing security framework provided by SELinux (Security-
Enhanced Linux), applying Mandatory Access Control (MAC) to virtual machines. The main objective of
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 this capability to
hosts and guests by treating each guest as a process, allowing administrators to apply similar policies
designed to prevent malicious guests from accessing restricted resources. For more information on
sVirt, refer to Chapter 4, sVirt.
1.4. Further Resources
Red Hat offers a wealth of documentation solutions across its various virtualization products. Coverage
of Red Hat Enterprise Linux and its inbuilt virtualization products includes:
Red Hat Enterprise Linux Virtualization Getting Started Guide: This guide provides an introduction
to virtualization concepts, advantages, and tools, and an overview of Red Hat virtualization
documentation and products.
Red Hat Enterprise Linux Virtualization Host Configuration and Guest Installation Guide: This
guide covers the installation of virtualization software and configuration of guest machines on a
virtualization host.
Red Hat Enterprise Linux Virtualization Administration Guide: This guide covers administration of
hosts, networking, storage, device and guest management using either virt-manager or virsh, a libvirt
and QEMU reference, and troubleshooting information.
Red Hat Enterprise Linux Virtualization Security Guide: This guide provides an overview of
virtualization security technologies provided by Red Hat. Also included are recommendations for
securing hosts, guests, and shared infrastructure and resources in virtualized environments.
Red Hat Enterprise Linux Virtualization Tuning and Optimization Guide: This guide provides tips,
8
Chapter 1. Introduction
tricks and suggestions for making full use of virtualization performance features and options for your
systems and guest virtual machines.
Red Hat Enterprise Linux V2V Guide describes importing virtual machines from KVM, Xen and
VMware ESX/ESX(i) hypervisors to Red Hat Enterprise Virtualization and KVM managed by libvirt.
Note
These guides, and the documentation suite for Red Hat Enterprise Virtualization, are available at
the Red Hat Customer Portal: https://access.redhat.com/site/documentation/
9
Red Hat Enterprise Linux 6 Virtualization Security Guide
Chapter 2. Host Security
2.1. Why Host Security Matters
When deploying virtualization technologies, the security of the host should be paramount. The Red Hat
Enterprise Linux host system is responsible for managing and controlling access to the physical
devices, storage and network as well as all virtualized guests themselves. If the host system were to be
compromised, not only would the host system be vulnerable, but so would the guests and their data.
Virtualized guests are only as secure as their host system; securing the Red Hat Enterprise Linux host
system is the first step towards ensuring a secure virtualization platform.
2.2. Host Security Recommended Practices for Red Hat Enterprise
Linux
With host security being such a critical part of a secure virtualization infrastructure, the following
recommended practices should serve as a starting point for securing a Red Hat Enterprise Linux host
system:
Run only the services necessary to support the use and management of your guest systems. If you
need to provide additional services, such as file or print services, you should consider running those
services in 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 privileged
access to administrators based on their administrative roles.
Ensure that SELinux is configured properly for your installation and is operating in enforcing mode.
Besides being a good security practice, the advanced virtualization security functionality provided by
sVirt relies on SELinux. Refer to Chapter 4, sVirt for more information on SELinux and sVirt.
Ensure that auditing is enabled on the host system and that libvirt is configured to emit audit records.
When auditing is enabled, libvirt will generate audit records for changes to guest configuration as
well start/stop events which help you track the guest's state. In addition to the standard audit log
inspection tools, the libvirt audit events can also be viewed using the specialized auvirt tool.
Ensure that any 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 and data
encryption to help ensure that only approved administrators can manage the system remotely.
Ensure that the firewall is configured properly for your installation and is activated at boot. Only those
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, you should use partitions (for example, /dev/sdb1) or LVM volumes for guest storage.
10
Chapter 2. Host Security
Note
The 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 method of
addressing them. However, there are a number of recommended practices to follow when
securing a Red Hat Enterprise Linux system that apply regardless of whether the system is a
standalone, virtualization host, or guest instance. These recommended practices include
procedures such as system updates, password security, encryption, and firewall configuration.
This information is discussed in more detail in the Red Hat Enterprise Linux Security Guide which
can be found at https://access.redhat.com/site/documentation/.
2.2.1. Special Considerations for Public Cloud Operators
Public cloud service providers are exposed to a number of security risks beyond that of the traditional
virtualization user. Virtual guest isolation, both between the host and guest as well as between guests,
is critical due to the threat of malicious guests and the requirements on customer data 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 and
other device passthrough mechanisms not only make management difficult, but often rely on the
underlying hardware to enforce separation between the guests.
Network traffic should be separated such that the cloud operator's private management network is
isolated from the customer guest network, helping to ensure that the guests can not access the host
systems over the network. The network should be further isolated such that customer guest systems
run in a private, virtualized network so that one customer can not access another customer's guest
systems directly via the cloud provider's internal network.
2.3. Host Security Recommended Practices for Red Hat Enterprise
Virtualization
2.3.1. Red Hat Enterprise Virtualization Network Ports
Red Hat Enterprise Virtualization uses various network ports for management and other virtualization
features. These ports must be open for Red Hat Enterprise Linux to function as a host with Red Hat
Enterprise Virtualization. The list below covers ports and their usage by Red Hat Enterprise
Virtualization:
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 5634 to 6166 (TCP) are used for guest console access.
Ports 8080 or 8443 (TCP), depending on the security settings on the Manager, are used by the
vdsm-reg service to communicate information about the host.
Port 16514 (TCP) is used to support migration communication generated by libvirt.
Ports 49152 to 49216 (TCP) are used for migrations. Migration may use any port in this range
depending on the number of concurrent migrations occurring.
Port 54321 (TCP) is used by default, by VDSM for management, storage and inter-host
11
Red Hat Enterprise Linux 6 Virtualization Security Guide
communication. This port can be modified.
Warning
Take special care to filter SNMP on port 161 (UDP) at the border of your network unless it is
absolutely necessary to externally manage devices.
12
Chapter 3. Guest Security
Chapter 3. Guest Security
3.1. Why Guest Security Matters
While the security of the host system is critical in ensuring the security of the guests running on the
host, it does not remove the need for properly securing the individual guest machines. All of the security
risks associated with a conventional, non-virtualized system still exist when the system is run as a
virtualized guest. Any resources accessible to the guest system, such as critical business data or
sensitive customer information, could be made vulnerable if the guest system were to be compromised.
3.2. Guest Security Recommended Practices
All of the recommended practices for securing a Red Hat Enterprise Linux system documented in the
Red Hat Enterprise Linux Security Guide apply to the conventional, non-virtualized systems as well as
those systems installed as a virtualized guest. However, there are a few security practices which are of
critical importance when running in a virtualized environment:
With all management of the guest likely taking place remotely, ensure that the 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 and data encryption to ensure that only approved
administrators can manage the system remotely.
Some virtualization technologies use special guest agents or drivers to enable some virtualization
specific features. Ensure that these agents and applications are secured using the standard Red
Hat Enterprise Linux security features, e.g. SELinux.
In virtualized environments there is a greater risk of sensitive data being accessed outside the
protection boundaries of the guest system. Protect stored sensitive data using encryption tools such
as dm-crypt and GnuPG; although special care needs to be taken to ensure the confidentiality of the
encryption keys.
13
Red Hat Enterprise Linux 6 Virtualization Security Guide
Chapter 4. sVirt
4.1. Introduction
Since virtual machines under KVM are implemented as Linux processes, KVM leverages the standard
Linux 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 add mandatory
access control (MAC), multi-level security (MLS) and multi-category security (MCS) through a flexible and
customizable security policy. SELinux provides strict resource isolation and confinement 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 controlled sharing. For example, fine-grained
permissions could be applied to group virtual machines together to share resources.
From a security point of view, the hypervisor is a tempting target for attackers, as a compromised
hypervisor could lead to the compromise of all virtual machines running on the host system. Integrating
SELinux into the virtualization technologies helps improve the security of the hypervisor against
malicious 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 compromised
hypervisor (or guest) to launch further attacks, or to extend to another instance:
Note
For more information on SELinux, refer to Red Hat Enterprise Linux Security-Enhanced Linux at
https://access.redhat.com/site/documentation/.
4.2. SELinux and Mandatory Access Control (MAC)
Security-Enhanced Linux (SELinux) is an implementation of MAC in the Linux kernel, checking for allowed
operations after standard discretionary access controls (DAC) are checked. SELinux can enforce a user
customizable security policy on running processes and their actions, including their attempts to access
file system objects. Enabled by default in Red Hat Enterprise Linux, SELinux limits the scope of potential
damage that can result from the exploitation of vulnerabilities in applications and system services, such
as the hypervisor.
sVirt integrates with libvirt, a virtualization management abstraction layer, to provide a MAC framework
for virtual machines. This architecture allows all virtualization platforms supported by libvirt and all MAC
implementations supported by sVirt to interoperate.
14
Chapter 4. sVirt
implementations supported by sVirt to interoperate.
4.3. sVirt Configuration
SELinux Booleans are variables that can be toggled on or off, quickly enabling or disabling features or
other special conditions. The following table shows the SELinux Boolean values that affect KVM when
launched by libvirt.
KVM SELinux Booleans
SELinux Boolean Description
virt_use_comm Allow virt to use serial/parallel communication
ports.
virt_use_fusefs Allow virt to read FUSE mounted files.
virt_use_nfs Allow virt to manage NFS mounted files.
virt_use_samba Allow virt to manage CIFS mounted files.
virt_use_sanlock Allow confined virtual guests to interact with the
sanlock.
virt_use_sysfs Allow virt to manage device configuration (PCI).
virt_use_usb Allow virt to use USB devices.
virt_use_xserver Allow virtual machine to interact with the X
Window System.
Note
For more information on SELinux Booleans, refer to Red Hat Enterprise Linux Security-Enhanced
Linux and Red Hat Enterprise Linux Managing Confined Services at
https://access.redhat.com/site/documentation/.
4.4. sVirt Labeling
Like other services under the protection of SELinux, sVirt uses process based mechanisms, labels and
restrictions to provide extra security and control over guest instances. Labels are applied automatically
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 requirements that may exist.
4.4.1. Types of sVirt Labels
The following table outlines the different sVirt labels that can be assigned to resources such as virtual
machine processes, image files and shared content:
15
Red Hat Enterprise Linux 6 Virtualization Security Guide
Table 4 .1. sVirt Labels
Type SELinux Context Description/Effect
Virtual Machine Processes system_u:system_r:svirt_t:MCS1 MCS1 is a randomly selected
field. Currently approximately
500,000 labels are supported.
Virtual Machine Image system_u:object_r:svirt_image_t: Only svirt_t processes with the
MCS1 same MCS1 fields are able to
read/write these image files and
devices.
Virtual Machine Shared system_u:object_r:svirt_image_t: All svirt_t processes are allowed
Read/Write Content s0 to write to the svirt_image_t:s0
files and devices.
Virtual Machine Shared Shared system_u:object_r:svirt_content All svirt_t processes are able to
Read Only content _t:s0 read files/devices with this label.
Virtual Machine Image system_u:object_r:virt_content_t System default label used when
:s0 an image exits. No svirt_t virtual
processes are allowed to read
files/devices with this label.
4.4.2. Dynamic Configuration
Dynamic label configuration is the default labeling option when using sVirt with SELinux. Refer to the
following 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 label and the
MCS label are combined to form the complete security label for the process. Likewise, libvirt takes the
same MCS label and base label to form the image label. This image label is then automatically applied to
all host files that the VM is required to access, such as disk images, disk devices, PCI devices, USB
devices, and kernel/initrd files. Each process is isolated from other virtual machines with different labels.
The following example shows the virtual machine's unique security label (with a corresponding MCS
label 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 16
Chapter 4. sVirt
4.4.3. Dynamic Configuration with Base Labeling
To override the default base security label in dynamic mode, the
option can be configuredsystem_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 system_u:system_r:svirt_custom_t:s0:c87,c520 system_u:system_r:svirt_custom_t:s0:c87,c520 Red Hat Enterprise Linux 7 Virtualization Security Guide en US Red Hat Enterprise Linux 6 Virtualization Security Guide en US Red Hat Enterprise Linux 6 Resource Management Guide en US Red Hat Enterprise Linux 4 Global Network Block?vice en US Red Hat Enterprise Linux 3 GFS Release Notes en US Red Hat Enterprise MRG 2 Tuna User Guide en US Red Hat Enterprise Linux 5 5 10 Release Notes en US Red Hat Enterprise Linux 6 Beta Virtualization Security Guide en US Red Hat Enterprise Linux 6 Virtualization Getting Started Guide en US red hat enterprise linux 5 io tuning guide Red Hat Enterprise Linux 5 Para virtualized Windows Drivers Guide en US Red Hat Enterprise Linux OpenStack Platform?rtification Test Suite 5 User Guide en US Red Hat Enterprise Linux OpenStack Platform?rtification 1 0 Policy Guide en US Red Hat Enterprise Linux OpenStack Platform?rtification Test Suite 4 User Guide en US Red Hat Enterprise Linux 6 Hypervisor?ployment Guide en US Red Hat Enterprise Linux 7 Kernel Crash Dump Guide en US Red Hat Enterprise Linux 7 Kernel Crash Dump Guide en US Red Hat Enterprise Linux 6 V2V Guide en US Red Hat Enterprise Linux 6 High Availability?d On Overview en US więcej podobnych podstron