[securityguide] Added a section about sVirt.
Bara Ančincová
bancinco at fedoraproject.org
Sun Aug 10 23:00:16 UTC 2014
commit 4970f227a9350830f13b617ff21973d632aa22de
Author: Barbora Ancincova <bancinco at redhat.com>
Date: Sun Aug 10 22:16:06 2014 +0200
Added a section about sVirt.
en-US/SVirt.xml | 120 ++++++++++++++++++++++++++++++++
en-US/Security_Guide.xml | 3 +-
en-US/images/after_virtualization.png | Bin 0 -> 40228 bytes
en-US/images/before_virtualization.png | Bin 0 -> 38560 bytes
en-US/images/selinux_uuid_block.png | Bin 0 -> 43395 bytes
5 files changed, 122 insertions(+), 1 deletions(-)
---
diff --git a/en-US/SVirt.xml b/en-US/SVirt.xml
new file mode 100644
index 0000000..3cd0ccd
--- /dev/null
+++ b/en-US/SVirt.xml
@@ -0,0 +1,120 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+
+<section id="sect-Security-Enhanced_Linux-sVirt">
+ <title>sVirt</title>
+ <para>
+ sVirt is a technology included in &PRODUCT; that integrates SELinux and virtualization. sVirt applies Mandatory Access Control (MAC) to improve security when using virtual machines. The main reasons for integrating these technologies are to improve security and harden the system against bugs in the hypervisor that might be used as an attack vector aimed toward the host or to another virtual machine.
+ </para>
+ <para>
+ This chapter describes how sVirt integrates with virtualization technologies in &PRODUCT;.
+ </para>
+ <bridgehead renderas="sect2">Non-Virtualized Environment</bridgehead>
+ <para>
+ 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:
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="./images/before_virtualization.png" format="PNG" />
+ </imageobject>
+ </mediaobject>
+ <bridgehead renderas="sect2">Virtualized Environment</bridgehead>
+ <para>
+ 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:
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="./images/after_virtualization.png" format="PNG" />
+ </imageobject>
+ </mediaobject>
+ <section id="sec-Security-Enhanced_Linux-Security_and_Virtualization">
+ <title>Security and Virtualization</title>
+ <para>
+ When services are not virtualized, machines are physically separated. Any exploit is 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.
+ </para>
+ <para>
+ sVirt is an effort to isolate guests and limit their ability to launch further attacks if exploited. This is demonstrated in the following image, where an attack cannot break out of the virtual machine and extend to another host instance:
+ </para>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="./images/selinux_uuid_block.png" format="PNG" />
+ </imageobject>
+ </mediaobject>
+ <para>
+ SELinux introduces a pluggable security framework for virtualized instances in its implementation of Mandatory Access Control (MAC). The sVirt framework allows guests and their resources to be uniquely labeled. Once labeled, rules can be applied which can reject access between different guests.
+ </para>
+ </section>
+ <section id="sec-Security-Enhanced_Linux-sVirt_Labeling">
+ <title>sVirt Labeling</title>
+ <para>
+ Like other services under the protection of SELinux, sVirt uses process-based mechanisms and restrictions to provide an extra layer of security over guest instances. Under typical use, you should not even notice that sVirt is working in the background. This section describes the labeling features of sVirt.
+ </para>
+ <para>
+ As shown in the following output, when using sVirt, each Virtual Machine (VM) process is labeled and runs with a dynamically generated level. Each process is isolated from other VMs with different levels:
+ </para>
+<screen>
+<prompt>~]#</prompt> <command>ps -eZ | grep qemu</command>
+
+system_u:system_r:svirt_t:s0:c87,c520 27950 ? 00:00:17 qemu-kvm
+system_u:system_r:svirt_t:s0:c639,c757 27989 ? 00:00:06 qemu-system-x86
+</screen>
+ <para>
+ The actual disk images are automatically labeled to match the processes, as shown in the following output:
+ </para>
+<screen>
+<prompt>~]#</prompt> <command>ls -lZ /var/lib/libvirt/images/*</command>
+
+system_u:object_r:svirt_image_t:s0:c87,c520 image1
+</screen>
+ <para>
+ The following table outlines the different labels that can be assigned when using sVirt:
+ </para>
+<table frame='all'><title>sVirt Labels</title>
+<tgroup cols='3' align='left' colsep='1' rowsep='1'>
+ <colspec colname='c1' />
+ <colspec colnum='2' colname='c2' />
+ <colspec colnum='3' colname='c3' />
+<thead>
+<row>
+ <entry namest="c1" nameend="c1" align="left">Type</entry>
+ <entry namest="c2" nameend="c2" align="left">SELinux Context</entry>
+ <entry namest="c2" nameend="c2" align="left">Description</entry>
+</row>
+</thead>
+<tbody>
+<row>
+ <entry>Virtual Machine Processes</entry>
+ <entry>system_u:system_r:svirt_t:MCS1</entry>
+ <entry>MCS1 is a randomly selected MCS field. Currently approximately 500,000 labels are supported.</entry>
+</row>
+<row>
+ <entry>Virtual Machine Image</entry>
+ <entry>system_u:object_r:svirt_image_t:MCS1</entry>
+ <entry>Only processes labeled <emphasis>svirt_t</emphasis> with the same MCS fields are able to read/write these image files and devices.</entry>
+</row>
+<row>
+ <entry>Virtual Machine Shared Read/Write Content</entry>
+ <entry>system_u:object_r:svirt_image_t:s0</entry>
+ <entry>All processes labeled <emphasis>svirt_t</emphasis> are allowed to write to the svirt_image_t:s0 files and devices.</entry>
+</row>
+<!--
+ <row>
+ <entry>Virtual Machine Shared Shared Read Only content</entry>
+ <entry>system_u:object_r:svirt_content_t:s0</entry>
+ <entry>All svirt_t processes are able to read files/devices with this label.</entry>
+ </row>
+-->
+<row>
+ <entry>Virtual Machine Image</entry>
+ <entry>system_u:object_r:virt_content_t:s0</entry>
+ <entry>System default label used when an image exits. No <emphasis>svirt_t</emphasis> virtual processes are allowed to read files/devices with this label.</entry>
+</row>
+</tbody>
+</tgroup>
+</table>
+ <para>
+ It is also possible to perform static labeling when using sVirt. Static labels allow the administrator to select a specific 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 virtual machine will always be started with that label, and the sVirt system will never modify the label of a statically-labeled virtual machine's content. This allows the sVirt component to run in an MLS environment. You can also run multiple virtual machines with different sensitivity levels on a system, depending on your requirements.
+ </para>
+ </section>
+</section>
diff --git a/en-US/Security_Guide.xml b/en-US/Security_Guide.xml
index 7256d28..ac27720 100644
--- a/en-US/Security_Guide.xml
+++ b/en-US/Security_Guide.xml
@@ -25,7 +25,8 @@
<xi:include href="Targeted_Policy.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Working_With_SELinux.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="sepolicy_Suite.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
- <xi:include href="Managing_Users.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
+ <xi:include href="Managing_Users.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
+ <xi:include href="SVirt.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Troubleshooting.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Further_Information.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
</chapter>
diff --git a/en-US/images/after_virtualization.png b/en-US/images/after_virtualization.png
new file mode 100644
index 0000000..d5f7179
Binary files /dev/null and b/en-US/images/after_virtualization.png differ
diff --git a/en-US/images/before_virtualization.png b/en-US/images/before_virtualization.png
new file mode 100644
index 0000000..075296c
Binary files /dev/null and b/en-US/images/before_virtualization.png differ
diff --git a/en-US/images/selinux_uuid_block.png b/en-US/images/selinux_uuid_block.png
new file mode 100644
index 0000000..9a4197a
Binary files /dev/null and b/en-US/images/selinux_uuid_block.png differ
More information about the docs-commits
mailing list