aceec15371
Better follow conventions, especially: * remove Latinism like via and i.e. * use variable lists * Add missing <filename> * wrap long lines Change-Id: I2a537df78ddf4fbeb127b058bf05caaf42441d5f
698 lines
32 KiB
XML
698 lines
32 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE chapter [
|
|
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
|
|
%openstack;
|
|
]>
|
|
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xmlns="http://docbook.org/ns/docbook" version="5.0"
|
|
xml:id="ch051_vss-intro">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Hypervisor selection</title>
|
|
<para>Virtualization provides flexibility and other key benefits
|
|
that enable cloud building. However, a virtualization stack must
|
|
also be secured appropriately to reduce the risks associated with
|
|
hypervisor breakout attacks. That is, while a virtualization stack
|
|
can provide isolation between instances, or guest virtual
|
|
machines, that isolation can be less than perfect in some
|
|
situations. Making intelligent selections for virtualization stack
|
|
as well as following the best practices outlined in this chapter
|
|
can be included in a layered approach to cloud security. Finally,
|
|
securing your virtualization stack is critical to deliver on the
|
|
promise of multi-tenant, either between customers in a public
|
|
cloud, between business units in a private cloud, or some mixture
|
|
of the two in a hybrid cloud.</para>
|
|
<para>This chapter discusses the hypervisor selection process. The
|
|
chapters that follow provide foundational information needed for
|
|
securing a virtualization stack.</para>
|
|
<section xml:id="ch051_vss-intro-idp236592">
|
|
<title>Hypervisors in OpenStack</title>
|
|
<para>Whether OpenStack is deployed within private data centers or
|
|
as a public cloud service, the underlying virtualization
|
|
technology provides enterprise-level capabilities in the realms
|
|
of scalability, resource efficiency, and uptime. While such
|
|
high-level benefits are generally available across many
|
|
OpenStack-supported hypervisor technologies, there are
|
|
significant differences in the security architecture and
|
|
features for each hypervisor, particularly when considering the
|
|
security threat vectors which are unique to elastic OpenStack
|
|
environments. As applications consolidate into single
|
|
Infrastructure-as-a-Service (IaaS) platforms, instance isolation
|
|
at the hypervisor level becomes paramount. The requirement for
|
|
secure isolation holds true across commercial, government, and
|
|
military communities.</para>
|
|
<para>Within the OpenStack framework, you can choose among many
|
|
hypervisor platforms and corresponding OpenStack plug-ins to
|
|
optimize your cloud environment. In the context of this guide,
|
|
hypervisor selection considerations are highlighted as they
|
|
pertain to feature sets that are critical to security. However,
|
|
these considerations are not meant to be an exhaustive
|
|
investigation into the pros and cons of particular hypervisors.
|
|
NIST provides additional guidance in Special Publication
|
|
800-125, "<emphasis>Guide to Security for Full Virtualization
|
|
Technologies</emphasis>".</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp242144">
|
|
<title>Selection criteria</title>
|
|
<para>As part of your hypervisor selection process, you must
|
|
consider a number of important factors to help increase your
|
|
security posture. Specifically, you must become familiar with
|
|
these areas:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Team expertise</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Product or project maturity</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Common criteria</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Certifications and attestations</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Hardware concerns</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Hypervisor vs. baremetal</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Additional security features</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Additionally, the following security-related criteria are
|
|
highly encouraged to be evaluated when selecting a hypervisor
|
|
for OpenStack deployments:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Has the hypervisor undergone Common Criteria
|
|
certification? If so, to what levels?</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Is the underlying cryptography certified by a
|
|
third-party?</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<section xml:id="team_expertise">
|
|
<title>Team expertise</title>
|
|
<para>Most likely, the most important aspect in hypervisor
|
|
selection is the expertise of your staff in managing and
|
|
maintaining a particular hypervisor platform. The more
|
|
familiar your team is with a given product, its configuration,
|
|
and its eccentricities, the fewer the configuration mistakes.
|
|
Additionally, having staff expertise spread across an
|
|
organization on a given hypervisor increases availability of
|
|
your systems, allows segregation of duties, and mitigates
|
|
problems in the event that a team member is
|
|
unavailable.</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp252752">
|
|
<title>Product or project maturity</title>
|
|
<para>The maturity of a given hypervisor product or project is
|
|
critical to your security posture as well. Product maturity
|
|
has a number of effects once you have deployed your
|
|
cloud:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Availability of expertise</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Active developer and user communities</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Timeliness and availability of updates</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Incidence response</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>One of the biggest indicators of a hypervisor's maturity
|
|
is the size and vibrancy of the community that surrounds it.
|
|
As this concerns security, the quality of the community
|
|
affects the availability of expertise if you need additional
|
|
cloud operators. It is also a sign of how widely deployed the
|
|
hypervisor is, in turn leading to the battle readiness of any
|
|
reference architectures and best practices.</para>
|
|
<para>Further, the quality of community, as it surrounds an open
|
|
source hypervisor like KVM or Xen, has a direct impact on the
|
|
timeliness of bug fixes and security updates. When
|
|
investigating both commercial and open source hypervisors, you
|
|
must look into their release and support cycles as well as the
|
|
time delta between the announcement of a bug or security issue
|
|
and a patch or response. Lastly, the supported capabilities of
|
|
OpenStack compute vary depending on the hypervisor chosen. See
|
|
the <link
|
|
xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
|
|
>OpenStack Hypervisor Support Matrix</link> for OpenStack
|
|
compute feature support by hypervisor.</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp260720">
|
|
<title>Certifications and attestations</title>
|
|
<para>One additional consideration when selecting a hypervisor
|
|
is the availability of various formal certifications and
|
|
attestations. While they may not be requirements for your
|
|
specific organization, these certifications and attestations
|
|
speak to the maturity, production readiness, and thoroughness
|
|
of the testing a particular hypervisor platform has been
|
|
subjected to.</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp262672">
|
|
<title>Common criteria</title>
|
|
<para>Common Criteria is an internationally standardized
|
|
software evaluation process, used by governments and
|
|
commercial companies to validate software technologies perform
|
|
as advertised. In the government sector, NSTISSP No. 11
|
|
mandates that U.S. Government agencies only procure software
|
|
which has been Common Criteria certified, a policy which has
|
|
been in place since July 2002. It should be specifically noted
|
|
that OpenStack has not undergone Common Criteria
|
|
certification, however many of the available hypervisors
|
|
have.</para>
|
|
<para>In addition to validating a technologies capabilities, the
|
|
Common Criteria process evaluates <emphasis>how</emphasis>
|
|
technologies are developed.</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>How is source code management performed?</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>How are users granted access to build systems?</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Is the technology cryptographically signed before
|
|
distribution?</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>The KVM hypervisor has been Common Criteria certified
|
|
through the U.S. Government and commercial distributions,
|
|
which have been validated to separate the runtime environment
|
|
of virtual machines from each other, providing foundational
|
|
technology to enforce instance isolation. In addition to
|
|
virtual machine isolation, KVM has been Common Criteria
|
|
certified to</para>
|
|
<blockquote>
|
|
<para>"<emphasis>provide system-inherent separation mechanisms
|
|
to the resources of virtual machines. This separation
|
|
ensures that large software component used for
|
|
virtualizing and simulating devices executing for each
|
|
virtual machine cannot interfere with each other. Using
|
|
the SELinux multi-category mechanism, the virtualization
|
|
and simulation software instances are isolated. The
|
|
virtual machine management framework configures SELinux
|
|
multi-category settings transparently to the
|
|
administrator</emphasis>"</para>
|
|
</blockquote>
|
|
<para>While many hypervisor vendors, such as Red Hat, Microsoft,
|
|
and VMWare have achieved Common Criteria Certification their
|
|
underlying certified feature set differs. It is recommended to
|
|
evaluate vendor claims to ensure they minimally satisfy the
|
|
following requirements:</para>
|
|
<informaltable rules="all" width="80%">
|
|
<colgroup>
|
|
<col/>
|
|
<col/>
|
|
</colgroup>
|
|
<tbody>
|
|
<tr>
|
|
<td><para>Identification and Authentication</para></td>
|
|
<td><para>Identification and authentication using
|
|
pluggable authentication modules (PAM) based upon user
|
|
passwords. The quality of the passwords used can be
|
|
enforced through configuration options.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Audit</para></td>
|
|
<td><para>The system provides the capability to audit a
|
|
large number of events including individual system
|
|
calls as well as events generated by trusted
|
|
processes. Audit data is collected in regular files in
|
|
ASCII format. The system provides a program for the
|
|
purpose of searching the audit
|
|
records.</para><para>The system administrator can
|
|
define a rule base to restrict auditing to the events
|
|
they are interested in. This includes the ability to
|
|
restrict auditing to specific events, specific users,
|
|
specific objects or a combination of all of
|
|
this.</para><para>Audit records can be transferred to
|
|
a remote audit daemon.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Discretionary Access Control</para></td>
|
|
<td>
|
|
<para>Discretionary Access Control
|
|
(<glossterm>DAC</glossterm>) restricts access to
|
|
file system objects based on <glossterm
|
|
baseform="access control list">Access Control
|
|
Lists</glossterm> (ACLs) that include the standard
|
|
UNIX permissions for user, group and others. Access
|
|
control mechanisms also protect IPC objects from
|
|
unauthorized access.</para>
|
|
<para>The system includes the ext4 file system, which
|
|
supports POSIX ACLs. This allows defining access
|
|
rights to files within this type of file system down
|
|
to the granularity of a single user.</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Mandatory Access Control</para></td>
|
|
<td><para>Mandatory Access Control (MAC) restricts access
|
|
to objects based on labels assigned to subjects and
|
|
objects. Sensitivity labels are automatically attached
|
|
to processes and objects. The access control policy
|
|
enforced using these labels is derived from the
|
|
BellLaPadula access control model.</para><para>SELinux
|
|
categories are attached to virtual machines and its
|
|
resources. The access control policy enforced using
|
|
these categories grant virtual machines access to
|
|
resources if the category of the virtual machine is
|
|
identical to the category of the accessed
|
|
resource.</para><para>The TOE implements
|
|
non-hierarchical categories to control access to
|
|
virtual machines.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Role-Based Access Control</para></td>
|
|
<td><para>Role-based access control (RBAC) allows
|
|
separation of roles to eliminate the need for an
|
|
all-powerful system administrator.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Object Reuse</para></td>
|
|
<td><para>File system objects and memory and IPC objects
|
|
are cleared before they can be reused by a process
|
|
belonging to a different user.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Security Management</para></td>
|
|
<td><para>The management of the security critical
|
|
parameters of the system is performed by
|
|
administrative users. A set of commands that require
|
|
root privileges (or specific roles when RBAC is used)
|
|
are used for system management. Security parameters
|
|
are stored in specific files that are protected by the
|
|
access control mechanisms of the system against
|
|
unauthorized access by users that are not
|
|
administrative users.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Secure Communication</para></td>
|
|
<td><para>The system supports the definition of trusted
|
|
channels using SSH. Password based authentication is
|
|
supported. Only a restricted number of cipher suites
|
|
are supported for those protocols in the evaluated
|
|
configuration.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Storage Encryption</para></td>
|
|
<td><para>The system supports encrypted block devices to
|
|
provide storage confidentiality via
|
|
dm_crypt.</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>TSF Protection</para></td>
|
|
<td><para>While in operation, the kernel software and data
|
|
are protected by the hardware memory protection
|
|
mechanisms. The memory and process management
|
|
components of the kernel ensure a user process cannot
|
|
access kernel storage or storage belonging to other
|
|
processes.</para><para>Non-kernel TSF software and
|
|
data are protected by DAC and process isolation
|
|
mechanisms. In the evaluated configuration, the
|
|
reserved user ID root owns the directories and files
|
|
that define the TSF configuration. In general, files
|
|
and directories containing internal TSF data, such as
|
|
configuration files and batch job queues, are also
|
|
protected from reading by DAC
|
|
permissions.</para><para>The system and the hardware
|
|
and firmware components are required to be physically
|
|
protected from unauthorized access. The system kernel
|
|
mediates all access to the hardware mechanisms
|
|
themselves, other than program visible CPU instruction
|
|
functions.</para><para>In addition, mechanisms for
|
|
protection against stack overflow attacks are
|
|
provided.</para></td>
|
|
</tr>
|
|
</tbody>
|
|
</informaltable>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp324896">
|
|
<title>Cryptography standards</title>
|
|
<para>Several cryptography algorithms are available within
|
|
OpenStack for identification and authorization, data transfer
|
|
and protection of data at rest. When selecting a hypervisor,
|
|
the following are recommended algorithms and implementation
|
|
standards to ensure the virtualization layer supports:</para>
|
|
<informaltable rules="all" width="80%">
|
|
<colgroup>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
</colgroup>
|
|
<thead>
|
|
<tr>
|
|
<th>Algorithm</th>
|
|
<th>Key length</th>
|
|
<th>Intended purpose</th>
|
|
<th>Security function</th>
|
|
<th>Implementation standard</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>AES</td>
|
|
<td>128, 192, or 256 bits</td>
|
|
<td>Encryption / decryption</td>
|
|
<td>Protected data transfer, protection for data at
|
|
rest</td>
|
|
<td>RFC 4253</td>
|
|
</tr>
|
|
<tr>
|
|
<td>TDES</td>
|
|
<td>168 bits</td>
|
|
<td>Encryption / decryption</td>
|
|
<td>Protected data transfer</td>
|
|
<td>RFC 4253</td>
|
|
</tr>
|
|
<tr>
|
|
<td>RSA</td>
|
|
<td>1024, 2048, or 3072 bits</td>
|
|
<td>Authentication, key exchange</td>
|
|
<td>Identification and authentication, protected
|
|
data transfer</td>
|
|
<td>U.S. NIST FIPS PUB 186-3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>DSA</td>
|
|
<td>L=1024, N=160 bits</td>
|
|
<td>Authentication, key exchange</td>
|
|
<td>Identification and authentication, protected
|
|
data transfer</td>
|
|
<td>U.S. NIST FIPS PUB 186-3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Serpent</td>
|
|
<td>128, 192, or 256 bits</td>
|
|
<td>Encryption / decryption</td>
|
|
<td>Protection of data at rest</td>
|
|
<td><link
|
|
xlink:href="http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf"
|
|
>http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf</link></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Twofish</td>
|
|
<td>128, 192, or 256 bit</td>
|
|
<td>Encryption / decryption</td>
|
|
<td>Protection of data at rest</td>
|
|
<td><link
|
|
xlink:href="http://www.schneier.com/paper-twofish-paper.html"
|
|
>http://www.schneier.com/paper-twofish-paper.html</link></td>
|
|
</tr>
|
|
<tr>
|
|
<td>SHA-1</td>
|
|
<td>-</td>
|
|
<td>Message Digest</td>
|
|
<td>Protection of data at rest, protected data
|
|
transfer</td>
|
|
<td>U.S. NIST FIPS 180-3</td>
|
|
</tr>
|
|
<tr>
|
|
<td>SHA-2 (224, 256, 384, or 512 bits)</td>
|
|
<td>-</td>
|
|
<td>Message Digest</td>
|
|
<td>Protection for data at rest, identification and
|
|
authentication</td>
|
|
<td>U.S. NIST FIPS 180-3</td>
|
|
</tr>
|
|
</tbody>
|
|
</informaltable>
|
|
<section xml:id="ch051_vss-intro-idp362768">
|
|
<title>FIPS 140-2</title>
|
|
<para>In the United States the National Institute of Science
|
|
and Technology (NIST) certifies cryptographic algorithms
|
|
through a process known the Cryptographic Module Validation
|
|
Program. NIST certifies algorithms for conformance against
|
|
Federal Information Processing Standard 140-2 (FIPS 140-2),
|
|
which ensures:</para>
|
|
<blockquote>
|
|
<para><emphasis>Products validated as conforming to FIPS
|
|
140-2 are accepted by the Federal agencies of both
|
|
countries [United States and Canada] for the protection
|
|
of sensitive information (United States) or Designated
|
|
Information (Canada). The goal of the CMVP is to promote
|
|
the use of validated cryptographic modules and provide
|
|
Federal agencies with a security metric to use in
|
|
procuring equipment containing validated cryptographic
|
|
modules.</emphasis></para>
|
|
</blockquote>
|
|
<para>When evaluating base hypervisor technologies, consider
|
|
if the hypervisor has been certified against FIPS 140-2. Not
|
|
only is conformance against FIPS 140-2 mandated per U.S.
|
|
Government policy, formal certification indicates that a
|
|
given implementation of a cryptographic algorithm has been
|
|
reviewed for conformance against module specification,
|
|
cryptographic module ports and interfaces; roles, services,
|
|
and authentication; finite state model; physical security;
|
|
operational environment; cryptographic key management;
|
|
electromagnetic interference/electromagnetic compatibility
|
|
(EMI/EMC); self-tests; design assurance; and mitigation of
|
|
other attacks.</para>
|
|
</section>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp367552">
|
|
<title>Hardware concerns</title>
|
|
<para>Further, when you evaluate a hypervisor platform, consider
|
|
the supportability of the hardware on which the hypervisor
|
|
will run. Additionally, consider the additional features
|
|
available in the hardware and how those features are supported
|
|
by the hypervisor you chose as part of the OpenStack
|
|
deployment. To that end, hypervisors each have their own
|
|
hardware compatibility lists (HCLs). When selecting compatible
|
|
hardware it is important to know in advance which
|
|
hardware-based virtualization technologies are important from
|
|
a security perspective.</para>
|
|
<informaltable rules="all" width="80%">
|
|
<colgroup>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
</colgroup>
|
|
<thead>
|
|
<tr>
|
|
<td>Description</td>
|
|
<td>Technology</td>
|
|
<td>Explanation</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>I/O MMU</td>
|
|
<td>VT-d / AMD-Vi</td>
|
|
<td>Required for protecting
|
|
PCI-passthrough</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Intel Trusted Execution Technology</td>
|
|
<td>Intel TXT / SEM</td>
|
|
<td>Required for dynamic attestation
|
|
services</td>
|
|
</tr>
|
|
<tr>
|
|
<td><anchor
|
|
xml:id="PCI-SIG_I.2FO_virtualization_.28IOV.29"
|
|
/>PCI-SIG I/O virtualization</td>
|
|
<td>SR-IOV, MR-IOV, ATS</td>
|
|
<td>Required to allow secure sharing of PCI Express
|
|
devices</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Network virtualization</td>
|
|
<td>VT-c</td>
|
|
<td>Improves performance of network I/O on
|
|
hypervisors</td>
|
|
</tr>
|
|
</tbody>
|
|
</informaltable>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp396976">
|
|
<title>Hypervisor vs. baremetal</title>
|
|
<para>It is important to recognise the difference between using
|
|
LXC (Linux Containers) or Baremetal systems vs using a
|
|
hypervisor like KVM. Specifically, the focus of this security
|
|
guide is largely based on having a hypervisor and
|
|
virtualization platform. However, should your implementation
|
|
require the use of a baremetal or LXC environment, you must
|
|
pay attention to the particular differences in regard to
|
|
deployment of that environment.</para>
|
|
<para>In particular, you must assure your end users that the
|
|
node has been properly sanitized of their data prior to
|
|
re-provisioning. Additionally, prior to reusing a node, you
|
|
must provide assurances that the hardware has not been
|
|
tampered or otherwise compromised.</para>
|
|
<note>
|
|
<para>While OpenStack has a baremetal project, a discussion of
|
|
the particular security implications of running baremetal is
|
|
beyond the scope of this book.</para>
|
|
</note>
|
|
<para>Finally, due to the time constraints around a book sprint,
|
|
the team chose to use KVM as the hypervisor in our example
|
|
implementations and architectures.</para>
|
|
<note>
|
|
<para>There is an OpenStack Security Note pertaining to the
|
|
<link
|
|
xlink:href="https://bugs.launchpad.net/ossn/+bug/1098582"
|
|
>use of LXC in Compute</link>.</para>
|
|
</note>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idpKMSTPS">
|
|
<title>Hypervisor memory optimization</title>
|
|
<para>Many hypervisors use memory optimization techniques to
|
|
overcommit memory to guest virtual machines. This is a useful
|
|
feature that allows you to deploy very dense compute clusters.
|
|
One way to achieve this is through de-duplication or “sharing”
|
|
of memory pages. When two virtual machines have identical data
|
|
in memory, there are advantages to having them reference the
|
|
same memory.</para>
|
|
<para>Typically this is achieved through Copy-On-Write (COW)
|
|
mechanisms. These mechanisms have been shown to be vulnerable
|
|
to side-channel attacks where one VM can infer something about
|
|
the state of another and might not be appropriate for
|
|
multi-tenant environments where not all tenants are trusted or
|
|
share the same levels of trust.</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idpKMS">
|
|
<title>KVM Kernel Samepage Merging</title>
|
|
<para>Introduced into the Linux kernel in version 2.6.32, Kernel
|
|
Samepage Merging (KSM) consolidates identical memory pages
|
|
between Linux processes. As each guest VM under the KVM
|
|
hypervisor runs in its own process, KSM can be used to
|
|
optimize memory use between VMs.</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idpTPS">
|
|
<title>XEN transparent page sharing</title>
|
|
<para>XenServer 5.6 includes a memory overcommitment feature
|
|
named Transparent Page Sharing (TPS). TPS scans memory in 4 KB
|
|
chunks for any duplicates. When found, the Xen Virtual Machine
|
|
Monitor (VMM) discards one of the duplicates and records the
|
|
reference of the second one.</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idpKMSTPSCons">
|
|
<title>Security considerations for memory optimization</title>
|
|
<para>Traditionally, memory de-duplication systems are
|
|
vulnerable to side channel attacks. Both KSM and TPS have
|
|
demonstrated to be vulnerable to some form of attack. In
|
|
academic studies<footnote>
|
|
<para>Fine grain Cross-VM Attacks on Xen and VMware are
|
|
possible - Apecechea and others. <link
|
|
xlink:href="https://eprint.iacr.org/2014/248.pdf"
|
|
>https://eprint.iacr.org/2014/248.pdf</link></para>
|
|
</footnote><footnote>
|
|
<para>Memory Deduplication as a Threat to the Guest OS -
|
|
Suzaki and others. <link
|
|
xlink:href="https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf"
|
|
>https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf</link></para>
|
|
</footnote>attackers were able to identify software packages
|
|
and versions running on neighboring virtual machines as well
|
|
as software downloads and other sensitive information through
|
|
analyzing memory access times on the attacker VM.</para>
|
|
<para>If a cloud deployment requires strong separation of
|
|
tenants, as is the situation with public clouds and some
|
|
private clouds, deployers should consider disabling TPS and
|
|
KSM memory optimizations.</para>
|
|
</section>
|
|
<section xml:id="ch051_vss-intro-idp401408">
|
|
<title>Additional security features</title>
|
|
<para>Another thing to look into when selecting a hypervisor
|
|
platform is the availability of specific security features. In
|
|
particular, we are referring to features like Xen Server's XSM
|
|
or Xen Security Modules, sVirt, Intel TXT, and AppArmor. The
|
|
presence of these features increase your security profile as
|
|
well as provide a good foundation.</para>
|
|
<para>The following table calls out these features by common
|
|
hypervisor platforms.</para>
|
|
<informaltable rules="all" width="80%">
|
|
<colgroup>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
<col/>
|
|
</colgroup>
|
|
<tbody>
|
|
<tr>
|
|
<td><para/></td>
|
|
<td><para>XSM</para></td>
|
|
<td><para>sVirt</para></td>
|
|
<td><para>TXT</para></td>
|
|
<td><para>AppArmor</para></td>
|
|
<td><para>cgroups</para></td>
|
|
<td><para>MAC Policy</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>KVM</para></td>
|
|
<td><para/></td>
|
|
<td><para>&CHECK;</para></td>
|
|
<td><para>&CHECK;</para></td>
|
|
<td><para>&CHECK;</para></td>
|
|
<td><para>&CHECK;</para></td>
|
|
<td><para>&CHECK;</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Xen</para></td>
|
|
<td><para>&CHECK;</para></td>
|
|
<td><para/></td>
|
|
<td><para>&CHECK;</para></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
<td><para>&CHECK;</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>ESXi</para></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
<td><para>&CHECK;</para></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
</tr>
|
|
<tr>
|
|
<td><para>Hyper-V</para></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
<td><para/></td>
|
|
</tr>
|
|
</tbody>
|
|
</informaltable>
|
|
<para><link xlink:href="http://www.linux-kvm.org/page/KSM">KVM:
|
|
Kernel Samepage Merging</link></para>
|
|
<para><link
|
|
xlink:href="http://wiki.xen.org/wiki/Xen_Security_Modules_:_XSM-FLASK"
|
|
>XSM: Xen Security Modules</link></para>
|
|
<para><link xlink:href="http://selinuxproject.org/page/SVirt"
|
|
>xVirt: Mandatory Access Control for Linux-based
|
|
virtualization</link></para>
|
|
<para><link xlink:href="http://www.intel.com/txt">TXT: Intel
|
|
Trusted Execution Technology</link></para>
|
|
<para><link
|
|
xlink:href="http://wiki.apparmor.net/index.php/Main_Page"
|
|
>AppArmor: Linux security module implementing
|
|
MAC</link></para>
|
|
<para><link
|
|
xlink:href="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt"
|
|
>cgroups: Linux kernel feature to control resource
|
|
usage</link></para>
|
|
<para>MAC Policy: Mandatory Access Control; may be implemented
|
|
with SELinux or other operating systems</para>
|
|
<para>* Features in this table might not be applicable to all
|
|
hypervisors or directly mappable between hypervisors.</para>
|
|
</section>
|
|
</section>
|
|
</chapter>
|