openstack/openstack-manuals
Code Issues Proposed changes

Merge "Adds link for KVM-KSM"

Browse Source
This commit is contained in:
Jenkins 2014-05-11 18:33:23 +00:00 committed by Gerrit Code Review
commit 41f9ff0834
1 changed files with 673 additions and 386 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

719
doc/security-guide/ch051_vss-intro.xml
View File

@ -3,77 +3,118 @@
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent"> <!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
%openstack; %openstack;
]> ]>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
<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?> 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> <title>Hypervisor selection</title>
<para>Virtualization provides flexibility and other key benefits <para>Virtualization provides flexibility and other key benefits
that enable cloud building. However, a virtualization stack also that enable cloud building. However, a virtualization stack must
needs to be secured appropriately to reduce the risks associated also be secured appropriately to reduce the risks associated with
with hypervisor breakout attacks. That is, while a virtualization hypervisor breakout attacks. That is, while a virtualization stack
stack can provide isolation between instances, or guest virtual can provide isolation between instances, or guest virtual
machines, there are situations where that isolation can be less machines, that isolation can be less than perfect in some
than perfect. Making intelligent selections for virtualization situations. Making intelligent selections for virtualization stack
stack as well as following the best practices outlined in this as well as following the best practices outlined in this chapter
chapter can be included in a layered approach to cloud security. can be included in a layered approach to cloud security. Finally,
Finally, securing your virtualization stack is critical in order securing your virtualization stack is critical to deliver on the
to deliver on the promise of multi-tenant, either between promise of multi-tenant, either between customers in a public
customers in a public cloud, between business units in a private cloud, between business units in a private cloud, or some mixture
cloud, or some mixture of the two in a hybrid cloud.</para> of the two in a hybrid cloud.</para>
<para>In this chapter, we discuss the hypervisor selection process. In the chapters that follow, we provide the foundational information needed for securing a virtualization stack.</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"> <section xml:id="ch051_vss-intro-idp236592">
<title>Hypervisors in OpenStack</title> <title>Hypervisors in OpenStack</title>
<para>Whether OpenStack is deployed within private data centers <para>Whether OpenStack is deployed within private data centers or
or as a public cloud service, the underlying virtualization as a public cloud service, the underlying virtualization
technology provides enterprise-level capabilities in the realms technology provides enterprise-level capabilities in the realms
of scalability, resource efficiency, and uptime. While such of scalability, resource efficiency, and uptime. While such
high-level benefits are generally available across many high-level benefits are generally available across many
OpenStack-supported hypervisor technologies, there are OpenStack-supported hypervisor technologies, there are
significant differences in each hypervisor's security significant differences in the security architecture and
architecture and features, particularly when considering the features for each hypervisor, particularly when considering the
security threat vectors which are unique to elastic OpenStack security threat vectors which are unique to elastic OpenStack
environments. As applications consolidate into single environments. As applications consolidate into single
Infrastructure-as-a-Service (IaaS) platforms, instance isolation Infrastructure-as-a-Service (IaaS) platforms, instance isolation
at the hypervisor level becomes paramount. The requirement for at the hypervisor level becomes paramount. The requirement for
secure isolation holds true across commercial, government, and secure isolation holds true across commercial, government, and
military communities.</para> military communities.</para>
<para>Within the framework of OpenStack you can choose from any number of hypervisor platforms and corresponding OpenStack plug-ins to optimize your cloud environment. In the context of the OpenStack Security guide, we will be highlighting hypervisor selection considerations 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> <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>
<section xml:id="ch051_vss-intro-idp242144"> <section xml:id="ch051_vss-intro-idp242144">
<title>Selection criteria</title> <title>Selection criteria</title>
<para>As part of your hypervisor selection process, you will need to consider a number of important factors to help increase your security posture. Specifically, we will be looking into the following areas:</para> <para>As part of your hypervisor selection process, you must
<itemizedlist><listitem> 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> <para>Team expertise</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Product or project maturity</para> <para>Product or project maturity</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Certifications, attestations</para> <para>Common criteria</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Additional security features</para> <para>Certifications and attestations</para>
</listitem>
<listitem>
<para>Hypervisor vs. baremetal</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Hardware concerns</para> <para>Hardware concerns</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Common Criteria</para> <para>Hypervisor vs. baremetal</para>
</listitem>
</itemizedlist>
<para>Additionally, the following security-related criteria are highly encouraged to be evaluated when selecting a hypervisor for OpenStack deployments:<itemizedlist><listitem>
<para>Has the hypervisor undergone Common Criteria certification? If so, to what levels?</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Is the underlying cryptography certified by a third-party?</para> <para>Additional security features</para>
</listitem> </listitem>
</itemizedlist><bridgehead>Team Expertise</bridgehead> 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 less likely will there be configuration mistakes. Additionally, having staff expertise spread across an organization on a given hypervisor will increase availability of your systems, allow for developing a segregation of duties, and mitigate problems in the event that a team member is unavailable.</para> </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"> <section xml:id="ch051_vss-intro-idp252752">
<title>Product or project maturity</title> <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 will have a number of effects once you have deployed your cloud, in the context of this security guide we are interested in the following:</para> <para>The maturity of a given hypervisor product or project is
<itemizedlist><listitem> 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> <para>Availability of expertise</para>
</listitem> </listitem>
<listitem> <listitem>
@ -86,277 +127,508 @@
<para>Incidence response</para> <para>Incidence response</para>
</listitem> </listitem>
</itemizedlist> </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 will affect the availability of expertise should 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>One of the biggest indicators of a hypervisor's maturity
<para>Further, the quality of community, as it surrounds an open source hypervisor like KVM or Xen, will have a direct impact on the timeliness of bug fixes and security updates. When investigating both commercial and open source hypervisors, you will want to 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. Refer to the <link xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix">OpenStack Hypervisor Support Matrix</link> for OpenStack compute feature support by hypervisor.</para> 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>
<section xml:id="ch051_vss-intro-idp260720"> <section xml:id="ch051_vss-intro-idp260720">
<title>Certifications and attestations</title> <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> <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>
<section xml:id="ch051_vss-intro-idp262672"> <section xml:id="ch051_vss-intro-idp262672">
<title>Common criteria</title> <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>Common Criteria is an internationally standardized
<para>In addition to validating a technologies capabilities, the Common Criteria process evaluates <emphasis>how</emphasis> technologies are developed.</para> software evaluation process, used by governments and
<itemizedlist><listitem> 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> <para>How is source code management performed?</para>
</listitem> </listitem>
<listitem> <listitem>
<para>How are users granted access to build systems?</para> <para>How are users granted access to build systems?</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Is the technology cryptographically signed before distribution?</para> <para>Is the technology cryptographically signed before
distribution?</para>
</listitem> </listitem>
</itemizedlist> </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> <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> <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> <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> </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> <para>While many hypervisor vendors, such as Red Hat, Microsoft,
and VMWare have achieved Common Criteria Certification their
<informaltable rules="all" width="80%"><colgroup><col/><col/></colgroup> 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> <tbody>
<tr> <tr>
<td><para>Identification and authentication</para></td> <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> <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>
<tr> <tr>
<td><para>Audit</para></td> <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> <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>
<tr> <tr>
<td><para>Discretionary Access Control</para></td> <td><para>Discretionary Access Control</para></td>
<td> <td>
<para>Discretionary Access Control <para>Discretionary Access Control
(<glossterm>DAC</glossterm>) restricts access to file (<glossterm>DAC</glossterm>) restricts access to
system objects based on file system objects based on <glossterm
<glossterm baseform="access control list">Access Control baseform="access control list">Access Control
Lists</glossterm> (ACLs) Lists</glossterm> (ACLs) that include the standard
that include the standard UNIX permissions for user, UNIX permissions for user, group and others. Access
group and others. Access control mechanisms also control mechanisms also protect IPC objects from
protect IPC objects from unauthorized unauthorized access.</para>
access.</para> <para>The system includes the ext4 file system, which
<para>The system includes the ext4 file supports POSIX ACLs. This allows defining access
system, which supports POSIX ACLs. This allows rights to files within this type of file system down
defining access rights to files within this type of to the granularity of a single user.</para>
file system down to the granularity of a single
user.</para>
</td> </td>
</tr> </tr>
<tr> <tr>
<td><para>Mandatory Access Control</para></td> <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> <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>
<tr> <tr>
<td><para>Role-Based Access Control</para></td> <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> <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>
<tr> <tr>
<td><para>Object reuse</para></td> <td><para>Object Reuse</para></td>
<td><para>File system objects as well as memory and IPC objects will be cleared before they can be reused by a process belonging to a different user.</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>
<tr> <tr>
<td><para>Security management</para></td> <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> <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>
<tr> <tr>
<td><para>Secure communication</para></td> <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> <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>
<tr> <tr>
<td><para>Storage encryption</para></td> <td><para>Storage Encryption</para></td>
<td><para>The system supports encrypted block devices to provide storage confidentiality via dm_crypt.</para></td> <td><para>The system supports encrypted block devices to
provide storage confidentiality via
dm_crypt.</para></td>
</tr> </tr>
<tr> <tr>
<td><para>TSF protection</para></td> <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 <td><para>While in operation, the kernel software and data
process isolation mechanisms. In the evaluated are protected by the hardware memory protection
configuration, the reserved user ID root owns the mechanisms. The memory and process management
directories and files that define the TSF components of the kernel ensure a user process cannot
configuration. In general, files and directories access kernel storage or storage belonging to other
containing internal TSF data, such as configuration processes.</para><para>Non-kernel TSF software and
files and batch job queues, are also protected from data are protected by DAC and process isolation
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> 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> </tr>
</tbody> </tbody>
</informaltable> </informaltable>
</section> </section>
<section xml:id="ch051_vss-intro-idp324896"> <section xml:id="ch051_vss-intro-idp324896">
<title>Cryptography standards</title> <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> <para>Several cryptography algorithms are available within
OpenStack for identification and authorization, data transfer
<informaltable rules="all" width="80%"><colgroup><col/><col/><col/><col/><col/></colgroup> and protection of data at rest. When selecting a hypervisor,
<thead> the following are recommended algorithms and implementation
<tr> standards to ensure the virtualization layer supports:</para>
<td>Algorithm</td> <informaltable rules="all" width="80%">
<td>Key length</td> <colgroup>
<td>Intended purpose</td> <col/>
<td>Security function</td> <col/>
<td>Implementation standard</td> <col/>
</tr> <col/>
</thead> <col/>
</colgroup>
<tbody> <tbody>
<tr> <tr>
<td>AES</td> <td><para><emphasis role="bold"
<td>128, 192, or 256 bits</td> >Algorithm</emphasis></para></td>
<td>Encryption / decryption</td> <td><para><emphasis role="bold">Key
<td>Protected data transfer, protection for data at rest</td> Length</emphasis></para></td>
<td>RFC 4253</td> <td><para><emphasis role="bold">Intended
Purpose</emphasis></para></td>
<td><para><emphasis role="bold">Security
Function</emphasis></para></td>
<td><para><emphasis role="bold">Implementation
Standard</emphasis></para></td>
</tr> </tr>
<tr> <tr>
<td>TDES</td> <td><para>AES</para></td>
<td>168 bits</td> <td><para>128, 192, or 256 bits</para></td>
<td>Encryption / decryption</td> <td><para>Encryption / Decryption</para></td>
<td>Protected data transfer</td> <td><para>Protected Data Transfer, Protection for Data at
<td>RFC 4253</td> Rest</para></td>
<td><para>RFC 4253</para></td>
</tr> </tr>
<tr> <tr>
<td>RSA</td> <td><para>TDES</para></td>
<td>1024, 2048, or 3072 bits</td> <td><para>168 bits</para></td>
<td>Authentication, key exchange</td> <td><para>Encryption / Decryption</para></td>
<td>Identification and authentication, protected data transfer</td> <td><para>Protected Data Transfer</para></td>
<td>U.S. NIST FIPS PUB 186-3</td> <td><para>RFC 4253</para></td>
</tr> </tr>
<tr> <tr>
<td>DSA</td> <td><para>RSA</para></td>
<td>L=1024, N=160 bits</td> <td><para>1024, 2048, or 3072 bits</para></td>
<td>Authentication, key exchange</td> <td><para>Authentication, Key Exchange</para></td>
<td>Identification and authentication, protected data transfer</td> <td><para>Identification and Authentication, Protected
<td>U.S. NIST FIPS PUB 186-3</td> Data Transfer</para></td>
<td><para>U.S. NIST FIPS PUB 186-3</para></td>
</tr> </tr>
<tr> <tr>
<td>Serpent</td> <td><para>DSA</para></td>
<td>128, 192, or 256 bits</td> <td><para>L=1024, N=160 bits</para></td>
<td>Encryption / decryption</td> <td><para>Authentication, Key Exchange</para></td>
<td>Protection of data at rest</td> <td><para>Identification and Authentication, Protected
<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> Data Transfer</para></td>
<td><para>U.S. NIST FIPS PUB 186-3</para></td>
</tr> </tr>
<tr> <tr>
<td>Twofish</td> <td><para>Serpent</para></td>
<td>128, 192, or 256 bits</td> <td><para>128, 192, or 256 bits</para></td>
<td>Encryption / decryption</td> <td><para>Encryption / Decryption</para></td>
<td>Protection of data at rest</td> <td><para>Protection of Data at Rest</para></td>
<td><link xlink:href="http://www.schneier.com/paper-twofish-paper.html">http://www.schneier.com/paper-twofish-paper.html</link></td> <td><para><link
xlink:href="http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf"
>http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf</link></para></td>
</tr> </tr>
<tr> <tr>
<td>SHA-1</td> <td><para>Twofish</para></td>
<td>-</td> <td><para>128, 192, or 256 bit</para></td>
<td>Message Digest</td> <td><para>Encryption / Decryption</para></td>
<td>Protection of data at rest, protected data transfer</td> <td><para>Protection of Data at Rest</para></td>
<td>U.S. NIST FIPS 180-3</td> <td><para><link
xlink:href="http://www.schneier.com/paper-twofish-paper.html"
>http://www.schneier.com/paper-twofish-paper.html</link></para></td>
</tr> </tr>
<tr> <tr>
<td>SHA-2 (224, 256, 384, or 512 bits)</td> <td><para>SHA-1</para></td>
<td>-</td> <td><para>-</para></td>
<td>Message digest</td> <td><para>Message Digest</para></td>
<td>Protection for data at rest, identification and authentication</td> <td><para>Protection of Data at Rest, Protected Data
<td>U.S. NIST FIPS 180-3</td> Transfer</para></td>
<td><para>U.S. NIST FIPS 180-3</para></td>
</tr>
<tr>
<td><para>SHA-2 (224, 256, 384, or 512 bits)</para></td>
<td><para>-</para></td>
<td><para>Message Digest</para></td>
<td><para>Protection for Data at Rest, Identification and
Authentication</para></td>
<td><para>U.S. NIST FIPS 180-3</para></td>
</tr> </tr>
</tbody> </tbody>
</informaltable> </informaltable>
<section xml:id="ch051_vss-intro-idp362768"> <section xml:id="ch051_vss-intro-idp362768">
<title>FIPS 140-2</title> <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> <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> <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> <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> </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> <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> </section>
<section xml:id="ch051_vss-intro-idp367552"> <section xml:id="ch051_vss-intro-idp367552">
<title>Hardware concerns</title> <title>Hardware concerns</title>
<para>Further, when evaluating a hypervisor platform the supportability of the hardware the hypervisor will run on should be considered. 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 will 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> <para>Further, when you evaluate a hypervisor platform, consider
the supportability of the hardware on which the hypervisor
<informaltable rules="all" width="80%"><colgroup><col/><col/><col/></colgroup> 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>
<tbody> <tbody>
<tr> <tr>
<td><para><emphasis role="bold">Description</emphasis></para></td> <td><para><emphasis role="bold"
<td><para><emphasis role="bold">Technology</emphasis></para></td> >Description</emphasis></para></td>
<td><para><emphasis role="bold">Explanation</emphasis></para></td> <td><para><emphasis role="bold"
>Technology</emphasis></para></td>
<td><para><emphasis role="bold"
>Explanation</emphasis></para></td>
</tr> </tr>
<tr> <tr>
<td><para>I/O MMU</para></td> <td><para>I/O MMU</para></td>
<td><para>VT-d / AMD-Vi</para></td> <td><para>VT-d / AMD-Vi</para></td>
<td><para>Required for protecting PCI-passthrough</para></td> <td><para>Required for protecting
PCI-passthrough</para></td>
</tr> </tr>
<tr> <tr>
<td><para>Intel Trusted Execution Technology</para></td> <td><para>Intel Trusted Execution Technology</para></td>
<td><para>Intel TXT / SEM</para></td> <td><para>Intel TXT / SEM</para></td>
<td><para>Required for dynamic attestation services</para></td> <td><para>Required for dynamic attestation
services</para></td>
</tr> </tr>
<tr> <tr>
<td><para><anchor xml:id="PCI-SIG_I.2FO_virtualization_.28IOV.29"/>PCI-SIG I/O virtualization</para></td> <td><para><anchor
xml:id="PCI-SIG_I.2FO_virtualization_.28IOV.29"
/>PCI-SIG I/O virtualization</para></td>
<td><para>SR-IOV, MR-IOV, ATS</para></td> <td><para>SR-IOV, MR-IOV, ATS</para></td>
<td><para>Required to allow secure sharing of PCI Express devices</para></td> <td><para>Required to allow secure sharing of PCI Express
devices</para></td>
</tr> </tr>
<tr> <tr>
<td><para>Network virtualization</para></td> <td><para>Network virtualization</para></td>
<td><para>VT-c</para></td> <td><para>VT-c</para></td>
<td><para>Improves performance of network I/O on hypervisors</para></td> <td><para>Improves performance of network I/O on
hypervisors</para></td>
</tr> </tr>
</tbody> </tbody>
</informaltable> </informaltable>
</section> </section>
<section xml:id="ch051_vss-intro-idp396976"> <section xml:id="ch051_vss-intro-idp396976">
<title>Hypervisor vs. baremetal</title> <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 will be largely based on having a hypervisor and virtualization platform. However, should your implementation require the use of a baremetal or LXC environment, you will want to pay attention to the particular differences in regard to deployment of that environment. In particular, you will need to provide your end users with assurances that the node has been properly sanitized of their data prior to re-provisioning. Additionally, prior to reusing a node, you will need to provide assurances that the hardware has not been tampered or otherwise compromised.</para> <para>It is important to recognise the difference between using
<para>It should be noted that while OpenStack has a baremetal project, a discussion of the particular security implications of running baremetal is beyond the scope of this book.</para> LXC (Linux Containers) or Baremetal systems vs using a
<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> hypervisor like KVM. Specifically, the focus of this security
<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> 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>
<section xml:id='ch051_vss-intro-idpKMSTPS'> <section xml:id="ch051_vss-intro-idpKMSTPS">
<title>Hypervisor memory optimization</title> <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. 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 may not be appropriate for multi-tenant environments where not all tenants are trusted (or share the same levels of trust).</para> <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>
<section xml:id='ch051_vss-intro-idpKMS'> <section xml:id="ch051_vss-intro-idpKMS">
<title>KVM Kernel Samepage Merging</title> <title>KVM Kernel Samepage Merging</title>
<para>Introduced into the Linux kernel in version 2.6.32, Kernel <para>Introduced into the Linux kernel in version 2.6.32, Kernel
Samepage Merging (KSM) consolidates identical memory pages between Linux Samepage Merging (KSM) consolidates identical memory pages
processes. As each guest VM under the KVM hypervisor runs in its own process, between Linux processes. As each guest VM under the KVM
KSM can be used to optimize memory use between VMs.</para> hypervisor runs in its own process, KSM can be used to
optimize memory use between VMs.</para>
</section> </section>
<section xml:id='ch051_vss-intro-idpTPS'> <section xml:id="ch051_vss-intro-idpTPS">
<title>XEN Transparent Page Sharing</title> <title>XEN transparent page sharing</title>
<para>XenServer 5.6 includes a memory overcommitment feature named <para>XenServer 5.6 includes a memory overcommitment feature
Transparent Page Sharing (TPS). TPS scans memory in 4 KB chunks for any named Transparent Page Sharing (TPS). TPS scans memory in 4 KB
duplicates. When found, the Xen Virtual Machine Monitor (VMM) discards one of chunks for any duplicates. When found, the Xen Virtual Machine
the duplicates and records the reference of the second one.</para> Monitor (VMM) discards one of the duplicates and records the
reference of the second one.</para>
</section> </section>
<section xml:id="ch051_vss-intro-idpKMSTPSCons"> <section xml:id="ch051_vss-intro-idpKMSTPSCons">
<title>Security considerations for memory optimization</title> <title>Security considerations for memory optimization</title>
<para>Traditionally, memory de-duplication systems are vulnerable to <para>Traditionally, memory de-duplication systems are
side channel attacks. Both KSM and TPS have demonstrated to be vulnerable to vulnerable to side channel attacks. Both KSM and TPS have
some form of attack. In academic studies<footnote><para>Fine grain Cross-VM demonstrated to be vulnerable to some form of attack. In
Attacks on Xen and VMware are possible - Apecechea, et al. <link academic studies<footnote>
xlink:href="https://eprint.iacr.org/2014/248.pdf">https://eprint.iacr.org/2014/248.pdf</link></para></footnote><footnote><para>Memory <para>Fine grain Cross-VM Attacks on Xen and VMware are
Deduplication as a Threat to the Guest OS - Suzaki, et al. <link possible - Apecechea 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 xlink:href="https://eprint.iacr.org/2014/248.pdf"
were able to identify software packages and versions running on neighboring >https://eprint.iacr.org/2014/248.pdf</link></para>
virtual machines as well as software downloads and other sensitive information </footnote><footnote>
through analyzing memory access times on the attacker VM.</para> <para>If a <para>Memory Deduplication as a Threat to the Guest OS -
cloud deployment requires strong separation of tenants, Suzaki and others. <link
as is the situation with public clouds and some private clouds, deployers xlink:href="https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf"
should consider disabling TPS and KSM memory optimizations.</para> >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>
<section xml:id="ch051_vss-intro-idp401408"> <section xml:id="ch051_vss-intro-idp401408">
<title>Additional security features</title> <title>Additional security features</title>
<para>Another thing to look into when selecting a hypervisor platform <para>Another thing to look into when selecting a hypervisor
is the availability of specific security features. In particular, we are platform is the availability of specific security features. In
referring to features like Xen Server's XSM or Xen Security Modules, sVirt, particular, we are referring to features like Xen Server's XSM
Intel TXT, and AppArmor. The presence of these features will help increase your or Xen Security Modules, sVirt, Intel TXT, and AppArmor. The
security profile as well as provide a good foundation.</para> <para>The presence of these features increase your security profile as
following table calls out these features by common hypervisor platforms.</para> well as provide a good foundation.</para>
<informaltable rules="all" width="80%"><colgroup><col/><col/><col/><col/><col/><col/><col/></colgroup> <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> <tbody>
<tr> <tr>
<td><para></para></td> <td><para/></td>
<td><para>XSM</para></td> <td><para>XSM</para></td>
<td><para>sVirt</para></td> <td><para>sVirt</para></td>
<td><para>TXT</para></td> <td><para>TXT</para></td>
@ -366,7 +638,7 @@ following table calls out these features by common hypervisor platforms.</para>
</tr> </tr>
<tr> <tr>
<td><para>KVM</para></td> <td><para>KVM</para></td>
<td><para></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> <td><para>&CHECK;</para></td>
@ -376,39 +648,54 @@ following table calls out these features by common hypervisor platforms.</para>
<tr> <tr>
<td><para>Xen</para></td> <td><para>Xen</para></td>
<td><para>&CHECK;</para></td> <td><para>&CHECK;</para></td>
<td><para></para></td> <td><para/></td>
<td><para>&CHECK;</para></td> <td><para>&CHECK;</para></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
<td><para>&CHECK;</para></td> <td><para>&CHECK;</para></td>
</tr> </tr>
<tr> <tr>
<td><para>ESXi</para></td> <td><para>ESXi</para></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
<td><para>&CHECK;</para></td> <td><para>&CHECK;</para></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
</tr> </tr>
<tr> <tr>
<td><para>Hyper-V</para></td> <td><para>Hyper-V</para></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
<td><para></para></td> <td><para/></td>
</tr> </tr>
</tbody> </tbody>
</informaltable> </informaltable>
<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://www.linux-kvm.org/page/KSM">KVM:
<para><link xlink:href="http://selinuxproject.org/page/SVirt">xVirt: Mandatory Access Control for Linux-based virtualization</link></para> Kernel Samepage Merging</link></para>
<para><link xlink:href="http://www.intel.com/txt">TXT: Intel Trusted Execution Technology</link></para> <para><link
<para><link xlink:href="http://wiki.apparmor.net/index.php/Main_Page">AppArmor: Linux security module implementing MAC</link></para> xlink:href="http://wiki.xen.org/wiki/Xen_Security_Modules_:_XSM-FLASK"
<para><link xlink:href="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups: Linux kernel feature to control resource usage</link></para> >XSM: Xen Security Modules</link></para>
<para>MAC Policy: Mandatory Access Control; may be implemented with SELinux or other operating systems</para> <para><link xlink:href="http://selinuxproject.org/page/SVirt"
<para>* Features in this table may not be applicable to all hypervisors or directly mappable between hypervisors.</para> >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>
</section> </section>
</chapter> </chapter>