Fix use of non-breaking-spaces in manuals

Non-breaking spaces should only be used where necessary to
prevent line breaks.

This patch removes and replaces non-breaking spaces as appropriate.

Closes-Bug: #1314498

Change-Id: I43565603a8d0ff8672c23cfee049b04b612070f8

doc/admin-guide-cloud/networking/section_networking_adv_features.xml

@@ -14,8 +14,8 @@
             credentials, specifying the details of how the network is physically realized, usually
             to match some existing network in the data center.</para>
         <para>Provider networks enable cloud administrators to create Networking networks that map
-            directly to the physical networks in the data center. This is commonly used to give
+            directly to the physical networks in the data center. This is commonly used to give
-            tenants direct access to a public network that can be used to reach the Internet. It
+            tenants direct access to a public network that can be used to reach the Internet. It
             might also be used to integrate with VLANs in the network that already have a defined
             meaning (for example, enable a VM from the "marketing" department to be placed on the
             same VLAN as bare-metal marketing hosts in the same data center).</para>
@@ -437,7 +437,7 @@
                                 Networking network associated with the subnet. The router also gets
                                 a gateway interface to the specified external network. This provides
                                 SNAT connectivity to the external network as well as support for
-                                floating IPs allocated on that external networks. Commonly an
+                                floating IPs allocated on that external networks. Commonly an
                                 external network maps to a network in the provider</para>
                         </td>
                     </tr>

doc/common/section_cli_nova_host_aggregates.xml

@@ -9,7 +9,7 @@
     xml:id="host-aggregates">
     <title>Host aggregates</title>
     <para>Host aggregates are a mechanism to further partition an
-        availability zone; while availability zones are visible to
+        availability zone; while availability zones are visible to
         users, host aggregates are only visible to administrators.
         Host Aggregates provide a mechanism to allow administrators to
         assign key-value pairs to groups of machines. Each node can

doc/config-reference/block-storage/drivers/coraid-driver.xml

@@ -123,7 +123,7 @@
       <step>
         <para>Download the latest Coraid AoE driver.</para>
         <para>
-          <screen><prompt>$</prompt> <userinput>wget http://support.coraid.com/support/linux/aoeXXX.tar.gz</userinput></screen>
+          <screen><prompt>$</prompt> <userinput>wget http://support.coraid.com/support/linux/aoeXXX.tar.gz</userinput></screen>
         </para>
       </step>
       <step>

doc/config-reference/object-storage/section_object-storage-features.xml

@@ -76,7 +76,7 @@
         <para>OpenStack Object Storage works best on the XFS file
             system, and this document assumes that the hardware being
             used is configured appropriately to be mounted with the
-                <command>nobarriers</command> option.   For more
+                <command>nobarriers</command> option. For more
             information, refer to the XFS FAQ: <link
                 xlink:href="http://xfs.org/index.php/XFS_FAQ"
                 >http://xfs.org/index.php/XFS_FAQ</link>

doc/image-guide/ch_creating_images_automatically.xml

@@ -134,7 +134,7 @@ echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules
         <title>BoxGrinder</title>
         <para>
             <link xlink:href="http://boxgrinder.org/"
-                >BoxGrinder</link>  is another tool for creating
+                >BoxGrinder</link> is another tool for creating
             virtual machine images, which it calls appliances.
             BoxGrinder can create Fedora, Red Hat Enterprise Linux, or
             CentOS images. BoxGrinder is currently only supported on

doc/image-guide/ch_creating_images_manually.xml

@@ -61,7 +61,7 @@ default              active     yes</computeroutput></screen>
             interact with the guest's graphical console.</para>
         <para>If you are building the image on a headless server, and
             you have an X server on your local machine, you can launch
-                <command>virt-manager</command>  using ssh X11
+                <command>virt-manager</command> using ssh X11
             forwarding to access the GUI. Since virt-manager interacts
             directly with libvirt, you typically need to be root to
             access it. If you can ssh directly in as root (or with a

doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch002_why-and-how-we-wrote-this-book"><?dbhtml stop-chunking?>
     <title>Why and how we wrote this book</title>
-    <para>As OpenStack adoption continues to grow and the product matures, security has become a priority. The OpenStack Security Group has recognized the need for a comprehensive and authoritative security guide. The <emphasis role="bold">OpenStack Security Guide</emphasis> has been written to provide an overview of security best practices, guidelines, and recommendations for increasing the security of an OpenStack deployment. The authors bring their expertise from deploying and securing OpenStack in a variety of environments.</para>
+    <para>As OpenStack adoption continues to grow and the product matures, security has become a priority. The OpenStack Security Group has recognized the need for a comprehensive and authoritative security guide. The <emphasis role="bold">OpenStack Security Guide</emphasis> has been written to provide an overview of security best practices, guidelines, and recommendations for increasing the security of an OpenStack deployment. The authors bring their expertise from deploying and securing OpenStack in a variety of environments.</para>
     <para>The guide augments the <link xlink:href="http://docs.openstack.org/ops/"><citetitle>OpenStack Operations Guide</citetitle></link> and can be referenced to harden existing OpenStack deployments or to evaluate the security controls of OpenStack cloud providers.</para>
     <section xml:id="ch002_why-and-how-we-wrote-this-book-idp117696">
       <title>Objectives</title>
@@ -25,7 +25,7 @@
     <section xml:id="ch002_why-and-how-we-wrote-this-book-idp123024">
       <title>How</title>
       <para>As with the OpenStack Operations Guide, we followed the book sprint methodology. The book sprint process allows for rapid development and production of large bodies of written work. Coordinators from the OpenStack Security Group re-enlisted the services of Adam Hyde as facilitator. Corporate support was obtained and the project was formally announced during the OpenStack summit in Portland, Oregon.</para>
-      <para>The team converged in Annapolis, MD due to the close proximity of some key members of the group. This was a remarkable collaboration between public sector intelligence community members, silicon valley startups and some large, well-known technology companies. The book sprint ran during the last week in June 2013 and the first edition was created in five days.</para>
+      <para>The team converged in Annapolis, MD due to the close proximity of some key members of the group. This was a remarkable collaboration between public sector intelligence community members, silicon valley startups and some large, well-known technology companies. The book sprint ran during the last week in June 2013 and the first edition was created in five days.</para>
       <para><inlinemediaobject><imageobject role="html">
             <imagedata contentdepth="450" contentwidth="540" fileref="static/group.png" format="PNG" scalefit="1"/>
           </imageobject>

doc/security-guide/ch004_book-introduction.xml

@@ -7,8 +7,8 @@
   <?dbhtml stop-chunking?>
   <title>Introduction to OpenStack</title>
   <para>This guide provides security insight into OpenStack
-    deployments. The intended audience is cloud architects, deployers,
+    deployments. The intended audience is cloud architects, deployers,
-    and administrators. In addition, cloud users will find the guide
+    and administrators. In addition, cloud users will find the guide
     both educational and helpful in provider selection, while auditors
     will find it useful as a reference document to support their
     compliance certification efforts. This guide is also recommended
@@ -60,7 +60,7 @@
     <section xml:id="ch004_book-introduction-idp121488">
       <title>Private cloud</title>
       <para>At the opposite end of the spectrum is the private cloud.
-        As NIST defines it, a private cloud is provisioned for
+        As NIST defines it, a private cloud is provisioned for
         exclusive use by a single organization comprising multiple
         consumers, such as business units. It may be owned, managed,
         and operated by the organization, a third-party, or some
@@ -71,7 +71,7 @@
     <section xml:id="ch004_book-introduction-idp123456">
       <title>Community cloud</title>
       <para>NIST defines a community cloud as one whose
-         infrastructure is provisioned for the exclusive use by a
+        infrastructure is provisioned for the exclusive use by a
         specific community of consumers from organizations that have
         shared concerns. For example, mission, security requirements,
         policy, and compliance considerations. It may be owned,
@@ -218,7 +218,7 @@
         between several of its services. By default, OpenStack uses
         message queues based on the Advanced Message Queue Protocol
         (<glossterm baseform="Advanced Message Queuing Protocol (AMQP)">AMQP
-        </glossterm>). Similar to most OpenStack services, it supports
+        </glossterm>). Similar to most OpenStack services, it supports
         pluggable components. Today the implementation backend could be
           <glossterm>RabbitMQ</glossterm>,
         <glossterm>Qpid</glossterm>, or

doc/security-guide/ch005_security-domains.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch005_security-domains"><?dbhtml stop-chunking?>
     <title>Security Boundaries and Threats</title>
-    <para>A cloud can be abstracted as a collection of logical components by virtue of their function, users, and shared security concerns, which we call security domains. Threat actors and vectors are classified based on their motivation and access to resources. Our goal is to provide you a sense of the security concerns with respect to each domain depending on your risk/vulnerability protection objectives.</para>
+    <para>A cloud can be abstracted as a collection of logical components by virtue of their function, users, and shared security concerns, which we call security domains. Threat actors and vectors are classified based on their motivation and access to resources. Our goal is to provide you a sense of the security concerns with respect to each domain depending on your risk/vulnerability protection objectives.</para>
     <section xml:id="ch005_security-domains-idp39040">
       <title>Security Domains</title>
       <para>A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization (AuthN/Z) requirements and users.</para>
@@ -35,7 +35,7 @@
       <section xml:id="ch005_security-domains-idp52768">
         <title>Guest</title>
         <para>Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud but not services that support the operation of the cloud, such as API calls.</para>
-        <para>Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to VMs should consider this domain to be <emphasis>untrusted</emphasis>. Private cloud providers may want to consider this network as internal and therefore <emphasis>trusted</emphasis> only if they have controls in place to assert that they trust instances and all their tenants.</para>
+        <para>Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to VMs should consider this domain to be <emphasis>untrusted</emphasis>. Private cloud providers may want to consider this network as internal and therefore <emphasis>trusted</emphasis> only if they have controls in place to assert that they trust instances and all their tenants.</para>
       </section>
       <section xml:id="ch005_security-domains-idp55632">
         <title>Management</title>
@@ -101,13 +101,13 @@
       </section>
       <section xml:id="ch005_security-domains-idp111680">
         <title>Public / Private Considerations</title>
-        <para>Private clouds are typically deployed by enterprises or institutions inside their networks and behind their firewalls. Enterprises will have strict policies on what data is allowed to exit their network and may even have different clouds for specific purposes. Users of a private cloud are typically employees of the organization that owns the cloud and are able to be held accountable for their actions. Employees often attend training sessions before accessing the cloud and will likely take part in regular scheduled security awareness training. Public clouds by contrast cannot make any assertions about their users, cloud use-cases or user motivations. This immediately pushes the guest security domain into a completely <emphasis>untrusted</emphasis> state for public cloud providers.</para>
+        <para>Private clouds are typically deployed by enterprises or institutions inside their networks and behind their firewalls. Enterprises will have strict policies on what data is allowed to exit their network and may even have different clouds for specific purposes. Users of a private cloud are typically employees of the organization that owns the cloud and are able to be held accountable for their actions. Employees often attend training sessions before accessing the cloud and will likely take part in regular scheduled security awareness training. Public clouds by contrast cannot make any assertions about their users, cloud use-cases or user motivations. This immediately pushes the guest security domain into a completely <emphasis>untrusted</emphasis> state for public cloud providers.</para>
         <para>A notable difference in the attack surface of public clouds is that they must provide internet access to their services. Instance connectivity, access to files over the internet and the ability to interact with the cloud controlling fabric such as the API endpoints and dashboard are must-haves for the public cloud.</para>
         <para>Privacy concerns for public and private cloud users are typically diametrically opposed. The data generated and stored in private clouds is normally owned by the operator of the cloud, who is able to deploy technologies such as data loss prevention (DLP) protection, file inspection, deep packet inspection and prescriptive firewalling. In contrast, privacy is one of the primary barriers to adoption for the public cloud, as many of these controls do not exist.</para>
       </section>
       <section xml:id="ch005_security-domains-idp116736">
         <title>Outbound attacks and reputational risk</title>
-        <para>Careful consideration should be given to potential outbound abuse from a cloud deployment.  Whether public or private, clouds tend to have lots of resource available. An attacker who has established a point of presence within the cloud, either through hacking in or via entitled access (rogue employee), can bring these resources to bear against the internet at large. Clouds with Compute services make for ideal DDoS and brute force engines. This is perhaps a more pressing issue for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks.  Major damage can be inflicted upon a company's reputation if it becomes known for hosting malicious software or launching attacks on other networks. Methods of prevention include egress security groups, outbound traffic inspection, customer education and awareness, and fraud and abuse mitigation strategies.</para>
+        <para>Careful consideration should be given to potential outbound abuse from a cloud deployment. Whether public or private, clouds tend to have lots of resource available. An attacker who has established a point of presence within the cloud, either through hacking in or via entitled access (rogue employee), can bring these resources to bear against the internet at large. Clouds with Compute services make for ideal DDoS and brute force engines. This is perhaps a more pressing issue for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks. Major damage can be inflicted upon a company's reputation if it becomes known for hosting malicious software or launching attacks on other networks. Methods of prevention include egress security groups, outbound traffic inspection, customer education and awareness, and fraud and abuse mitigation strategies.</para>
       </section>
       <section xml:id="ch005_security-domains-idp120000">
         <title>Attack Types</title>

doc/security-guide/ch008_system-roles-types.xml

@@ -79,7 +79,7 @@
       between the security domains. Network ingress and egress points
       should be identified along with any OpenStack logical system
       boundaries. Multiple diagrams may be needed to provide complete
-      visual coverage of the system.  A network topology document
+      visual coverage of the system. A network topology document
       should include virtual networks created on behalf of tenants by
       the system along with virtual machine instances and gateways
       created by OpenStack.</para>

doc/security-guide/ch009_case-studies.xml

@@ -4,7 +4,7 @@
     <para>In this case study we discuss how Alice and Bob would address their system documentation requirements. The documentation suggested above includes hardware and software records, network diagrams, and system configuration details.</para>
     <section xml:id="ch009_case-studies-idp44480">
       <title>Alice's Private Cloud</title>
-      <para>Alice needs detailed documentation to satisfy FedRamp requirements.  She sets up a configuration management database (CMDB) to store information regarding all of the hardware, firmware, and software versions used throughout the cloud. She also creates a network diagram detailing the cloud architecture, paying careful attention to the security domains and the services that span multiple security domains.</para>
+      <para>Alice needs detailed documentation to satisfy FedRamp requirements. She sets up a configuration management database (CMDB) to store information regarding all of the hardware, firmware, and software versions used throughout the cloud. She also creates a network diagram detailing the cloud architecture, paying careful attention to the security domains and the services that span multiple security domains.</para>
       <para>Alice also needs to record each network service running in the cloud, what interfaces and ports it binds to, the security domains for each service, and why the service is needed. Alice decides to build automated tools to log into each system in the cloud over secure shell (SSH) using the <link xlink:href="http://fabfile.org">Python Fabric library</link>. The tools collect and store the information in the CMDB, which simplifies the audit process.</para>
     </section>
     <section xml:id="ch009_case-studies-idp47344">

doc/security-guide/ch012_configuration-management.xml

@@ -92,12 +92,12 @@
         </colgroup>
         <tbody>
           <tr>
-            <td><para> </para></td>
+            <td><para> </para></td>
             <td colspan="4"><para><emphasis>Attacker Position /
                   Privilege Level</emphasis></para></td>
           </tr>
           <tr>
-            <td><para><emphasis role="bold"> </emphasis></para></td>
+            <td><para><emphasis role="bold"> </emphasis></para></td>
             <td><para><emphasis role="bold"
               >External</emphasis></para></td>
             <td><para><emphasis role="bold">Cloud
@@ -237,7 +237,7 @@
       <para>Whenever a policy or configuration management is changed,
         it is good practice to log the activity, and backup a copy of
         the new set. Often, such policies and configurations are
-        stored in a version controlled repository such as git.</para>
+        stored in a version controlled repository such as git.</para>
     </section>
   </section>
   <section xml:id="ch012_configuration-management-idp10160">
@@ -288,7 +288,7 @@
         </listitem>
         <listitem>
           <para><link xlink:href="http://www.music-piracy.com/?p=494"
-              >OpenStack Security Primer</link></para>
+              >OpenStack Security Primer</link></para>
         </listitem>
       </itemizedlist>
     </section>
@@ -296,7 +296,7 @@
   <section xml:id="ch012_configuration-management-idp131856">
     <title>Security Auditing Tools</title>
     <para>Security auditing tools can complement the configuration
-      management tools.  Security auditing tools automate the process
+      management tools. Security auditing tools automate the process
       of verifying that a large number of security controls are
       satisfied for a given system configuration. These tools help to
       bridge the gap from security configuration guidance
@@ -315,7 +315,7 @@
       help to maintain a cloud that satisfies security requirements
       ranging from basic hardening to compliance validation.</para>
     <para>Configuration management and security auditing tools will
-      introduce another layer of complexity into the cloud.  This
+      introduce another layer of complexity into the cloud. This
       complexity brings additional security concerns with it. We view
       this as an acceptable risk trade-off, given their security
       benefits. Securing the operational use of these tools is beyond

doc/security-guide/ch013_node-bootstrapping.xml

@@ -84,7 +84,7 @@
         as iPXE, provide this support. Typically this involves
         building the PXE firmware with knowledge of the allowed SSL
         certificate chain(s) so that it can properly validate the
-        server certificate.  This raises the bar for an attacker by
+        server certificate. This raises the bar for an attacker by
         limiting the number of insecure, plain text network
         operations.</para>
     </section>
@@ -100,7 +100,7 @@
         In both cases, the first step is to measure each piece of code
         before it is run. In this context, a measurement is
         effectively a SHA-1 hash of the code, taken before it is
-        executed.  The hash is stored in a platform configuration
+        executed. The hash is stored in a platform configuration
         register (PCR) in the TPM.</para>
       <para>Note: SHA-1 is used here because this is what the TPM
         chips support.</para>
@@ -143,50 +143,50 @@
           </tr>
           <tr>
             <td><para>PCR-02</para></td>
-            <td><para>Option ROM Code </para></td>
+            <td><para>Option ROM Code</para></td>
             <td><para>Hardware</para></td>
           </tr>
           <tr>
             <td><para>PCR-03</para></td>
-            <td><para>Option ROM Configuration and Data </para></td>
+            <td><para>Option ROM Configuration and Data</para></td>
-            <td><para>Hardware </para></td>
+            <td><para>Hardware</para></td>
           </tr>
           <tr>
             <td><para>PCR-04</para></td>
             <td><para>Initial Program Loader (IPL) Code. For example,
                 master boot record.</para></td>
-            <td><para>Software </para></td>
+            <td><para>Software</para></td>
           </tr>
           <tr>
             <td><para>PCR-05</para></td>
-            <td><para>IPL Code Configuration and Data </para></td>
+            <td><para>IPL Code Configuration and Data</para></td>
-            <td><para>Software </para></td>
+            <td><para>Software</para></td>
           </tr>
           <tr>
             <td><para>PCR-06</para></td>
-            <td><para>State Transition and Wake Events </para></td>
+            <td><para>State Transition and Wake Events</para></td>
-            <td><para>Software </para></td>
+            <td><para>Software</para></td>
           </tr>
           <tr>
             <td><para>PCR-07</para></td>
-            <td><para>Host Platform Manufacturer Control </para></td>
+            <td><para>Host Platform Manufacturer Control</para></td>
-            <td><para>Software </para></td>
+            <td><para>Software</para></td>
           </tr>
           <tr>
             <td><para>PCR-08</para></td>
             <td><para>Platform specific, often Kernel, Kernel
                 Extensions, and Drivers</para></td>
-            <td><para>Software </para></td>
+            <td><para>Software</para></td>
           </tr>
           <tr>
             <td><para>PCR-09</para></td>
             <td><para>Platform specific, often Initramfs</para></td>
-            <td><para>Software </para></td>
+            <td><para>Software</para></td>
           </tr>
           <tr>
             <td><para>PCR-10 to PCR-23</para></td>
-            <td><para>Platform specific </para></td>
+            <td><para>Platform specific</para></td>
-            <td><para>Software </para></td>
+            <td><para>Software</para></td>
           </tr>
         </tbody>
       </informaltable>
@@ -201,12 +201,12 @@
         validation. Typically the PCR values listed under the software
         context in the table above are the ones that a cloud architect
         has direct control over. But even these may change as the
-        software in the cloud is upgraded.  Configuration management
+        software in the cloud is upgraded. Configuration management
         should be linked into the PCR policy engine to ensure that the
         validation is always up to date.</para>
       <para>Each manufacturer must provide the BIOS and firmware code
         for their servers. Different servers, hypervisors, and
-        operating systems will choose to populate different PCRs.  In
+        operating systems will choose to populate different PCRs. In
         most real world deployments, it will be impossible to validate
         every PCR against a known good quantity ("golden
         measurement"). Experience has shown that, even within a single
@@ -245,8 +245,8 @@
         correct kernel and underlying components. There are many paths
         for hardening a given operating system deployment. The
         specifics on these steps are outside of the scope of this
-        book.  We recommend following the guidance from a hardening
+        book. We recommend following the guidance from a hardening
-        guide specific to your operating system.  For example, the
+        guide specific to your operating system. For example, the
           <link xlink:href="http://iase.disa.mil/stigs/">security
           technical implementation guides</link> (STIG) and the <link
           xlink:href="http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/"
@@ -257,14 +257,14 @@
       <itemizedlist>
         <listitem>
           <para>Use a read-only file system where possible. Ensure
-            that writeable file systems do not permit execution.  This
+            that writeable file systems do not permit execution. This
             can be handled through the mount options provided in
               <literal>/etc/fstab</literal>.</para>
         </listitem>
         <listitem>
           <para>Use a mandatory access control policy to contain the
             instances, the node services, and any other critical
-            processes and data on the node.  See the discussions on
+            processes and data on the node. See the discussions on
             sVirt / SELinux and AppArmor below.</para>
         </listitem>
         <listitem>
@@ -384,7 +384,7 @@
         <listitem>
           <para>In some deployments it may be required to add
             host-based IDS on sensitive components on security domain
-            bridges.  A host-based IDS may detect anomalous activity
+            bridges. A host-based IDS may detect anomalous activity
             by compromised or unauthorized processes on the component.
             The IDS should transmit alert and log information on the
             Management network.</para>

doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml

@@ -36,7 +36,7 @@
       <title>Cryptographic Algorithms, Cipher Modes, and Protocols</title>
       <para>We recommend only using TLS v1.1 or v1.2. SSLv3 and TLSv1.0 may be used for compatibility but we recommend using caution and only enabling these protocols if you have a strong requirement to do so. Other SSL/TLS versions, explicitly older versions, should not be used. These older versions include SSLv1 and SSLv2. As this book does not intend to be a thorough reference on cryptography we do not wish to be prescriptive about what specific algorithms or cipher modes you should enable or disable in your OpenStack services. However, there are some authoritative references we would like to recommend for further information:</para>
       <itemizedlist><listitem>
-          <para><link xlink:href="http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml">National Security Agency, Suite B Cryptography</link></para>
+          <para><link xlink:href="http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml">National Security Agency, Suite B Cryptography</link></para>
         </listitem>
 <listitem>
           <para><link xlink:href="https://www.owasp.org/index.php/Guide_to_Cryptography">OWASP Guide to Cryptography</link></para>

doc/security-guide/ch020_ssl-everywhere.xml

@@ -94,7 +94,7 @@ ciphers = "kEECDH:kEDH:kRSA:HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"
  </variablelist>
       <section xml:id="ch020_ssl-everywhere-idp45712">
         <title>Pound - with AES-NI acceleration</title>
-        <screen> 
+        <screen>
 ## see pound(8) for details
 daemon      1
 ######################################################################
@@ -147,8 +147,8 @@ End</screen>
       </section>
       <section xml:id="ch020_ssl-everywhere-idp50320">
         <title>Stud</title>
-        <para>This stud example enables SSL v3 for client compatibility.  The ciphers line can be tweaked based on your needs, however this is a reasonable starting place.</para>
+        <para>This stud example enables SSL v3 for client compatibility. The ciphers line can be tweaked based on your needs, however this is a reasonable starting place.</para>
-        <screen> 
+        <screen>
 # SSL x509 certificate file.
 pem-file = "
 # SSL protocol.
@@ -187,7 +187,7 @@ write-proxy = off</screen>
     <section xml:id="ch020_ssl-everywhere-idp53424">
       <title>nginx</title>
       <para>This nginx example requires TLS v1.1 or v1.2 for maximum security. The ssl_ciphers line can be tweaked based on your needs, however this is a reasonable starting place.</para>
-      <screen> 
+      <screen>
 server {
     listen : ssl;
     ssl_certificate ;
@@ -204,7 +204,7 @@ server {
 }</screen>
       <section xml:id="ch020_ssl-everywhere-idp55264">
         <title>Apache</title>
-        <screen> 
+        <screen>
 &lt;VirtualHost &lt;ip address&gt;:80&gt;
   ServerName &lt;site FQDN&gt;
   RedirectPermanent / https://&lt;site FQDN&gt;/
@@ -231,7 +231,7 @@ server {
 &lt;/VirtualHost&gt;</screen>
         <para>Compute API SSL endpoint in Apache2, which needs to be paired with
         a short WSGI script.</para>
-        <screen> 
+        <screen>
 &lt;VirtualHost &lt;ip address&gt;:8447&gt;
   ServerName &lt;site FQDN&gt;
   SSLEngine On

doc/security-guide/ch021_paste-and-middleware.xml

@@ -5,12 +5,12 @@
     <section xml:id="ch021_paste-and-middleware-idp38176">
       <title>Internal API Communications</title>
       <para>OpenStack provides both public facing and private API endpoints. By default, OpenStack components use the publicly defined endpoints. The recommendation is to configure these components to use the API endpoint within the proper security domain.</para>
-      <para>Services select their respective API endpoints based on the OpenStack service catalog.  The issue here is these services may not obey the listed public or internal API end point values. This can lead to internal management traffic being routed to external API endpoints.</para>
+      <para>Services select their respective API endpoints based on the OpenStack service catalog. The issue here is these services may not obey the listed public or internal API end point values. This can lead to internal management traffic being routed to external API endpoints.</para>
       <section xml:id="ch021_paste-and-middleware-idp40496">
         <title>Configure Internal URLs in Identity Service Catalog</title>
         <para>The Identity Service catalog should be aware of your internal URLs. While this feature is not utilized by default, it may be leveraged through configuration. Additionally, it should be forward-compatible with expectant changes once this behavior becomes the default.</para>
         <para>To register an internal URL for an endpoint:</para>
-        <screen> 
+        <screen>
 $ keystone endpoint-create \
  --region RegionOne \
  --service-id=1ff4ece13c3e48d8a6461faebd9cd38f \
@@ -20,11 +20,11 @@ $ keystone endpoint-create \
       </section>
       <section xml:id="ch021_paste-and-middleware-idp43360">
         <title>Configure Applications for Internal URLs</title>
-        <para>Some services can be forced to use specific API endpoints.  Therefore, it is recommended that each OpenStack service communicating to the API of another service must be explicitly configured to access the proper internal API endpoint.</para>
+        <para>Some services can be forced to use specific API endpoints. Therefore, it is recommended that each OpenStack service communicating to the API of another service must be explicitly configured to access the proper internal API endpoint.</para>
         <para>Each project may present an inconsistent way of defining target API endpoints. Future releases of OpenStack seek to resolve these inconsistencies through consistent use of the Identity Service catalog.</para>
         <section xml:id="ch021_paste-and-middleware-idp45520">
           <title>Configuration Example #1: Nova</title>
-          <screen> 
+          <screen>
 [DEFAULT]
 cinder_catalog_info='volume:cinder:internalURL'
 glance_protocol='https'
@@ -56,13 +56,13 @@ glance_host='https://glance-server'</screen>
       </section>
       <section xml:id="ch021_paste-and-middleware-idp55232">
         <title>Network Policy</title>
-        <para>API endpoints typically bridge multiple security domains, as such particular attention should be paid to the compartmentalization of the API processes.  See the <emphasis>Security Domain Bridging</emphasis> section for additional information in this area.</para>
+        <para>API endpoints typically bridge multiple security domains, as such particular attention should be paid to the compartmentalization of the API processes. See the <emphasis>Security Domain Bridging</emphasis> section for additional information in this area.</para>
         <para>With careful modeling, network ACLs and IDS technologies can be use to enforce explicit point to point communication between network services. As critical cross domain service, this type of explicit enforcement works well for OpenStack's message queue service.</para>
         <para>Policy enforcement can be implemented through the configuration of services, host-based firewalls (such as IPTables), local policy (SELinux or AppArmor), and optionally enforced through global network policy.</para>
       </section>
       <section xml:id="ch021_paste-and-middleware-idp58704">
         <title>Mandatory Access Controls</title>
-        <para>API endpoint processes should be isolated from each other and other processes on a machine. The configuration for those processes should be restricted to those processes not only by Discretionary Access Controls, but through Mandatory Access Controls. The goal of these enhanced access control is to aid in the containment and escalation of API endpoint security breaches.  With mandatory access controls, such breaches will severely limit access to resources and provide earlier alerting on such events.</para>
+        <para>API endpoint processes should be isolated from each other and other processes on a machine. The configuration for those processes should be restricted to those processes not only by Discretionary Access Controls, but through Mandatory Access Controls. The goal of these enhanced access control is to aid in the containment and escalation of API endpoint security breaches. With mandatory access controls, such breaches will severely limit access to resources and provide earlier alerting on such events.</para>
       </section>
     </section>
   </chapter>

doc/security-guide/ch022_case-studies-api-endpoints.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch022_case-studies-api-endpoints"><?dbhtml stop-chunking?>
     <title>Case Studies: API Endpoints</title>
-    <para>In this case study we discuss how Alice and Bob would address endpoint configuration to secure their private and public clouds. Alice's cloud is not publicly accessible, but she is still concerned about securing the endpoints against improper use.  Bob's cloud, being public, must take measures to reduce the risk of attacks by external adversaries.</para>
+    <para>In this case study we discuss how Alice and Bob would address endpoint configuration to secure their private and public clouds. Alice's cloud is not publicly accessible, but she is still concerned about securing the endpoints against improper use. Bob's cloud, being public, must take measures to reduce the risk of attacks by external adversaries.</para>
     <section xml:id="ch022_case-studies-api-endpoints-idp3824">
       <title>Alice's Private Cloud</title>
       <para>Alice's organization requires that the security architecture protect the access to the public and private endpoints, so she elects to use the Apache SSL proxy on both public and internal services. Alice's organization has implemented its own certificate authority. Alice contacts the PKI office in her agency that manages her PKI and certificate issuance. Alice obtains certificates issued by this CA and configures the services within both the public and management security domains to use these certificates. Since Alice's OpenStack deployment exists entirely on a disconnected from the Internet network, she makes sure to remove all default CA bundles that contain external public CA providers to ensure the OpenStack services only accept client certificates issued by her agency's CA. Alice has registered all of the services in the Keystone Services Catalog, using the internal URLs for access by internal services. She has installed host-based intrusion detection on all of the API endpoints.</para>

doc/security-guide/ch024_authentication.xml

@@ -95,7 +95,7 @@
         changes to the LDAP directory. This would allow privilege
         escalation within the wider organization or facilitate
         unauthorized access to other information and resources. In
-        such a deployment, user provisioning would be out of the realm
+        such a deployment, user provisioning would be out of the realm
         of the OpenStack deployment.</para>
       <note>
         <para>There is an <link

doc/security-guide/ch025_web-dashboard.xml

@@ -178,12 +178,12 @@
   <section xml:id="ch025_web-dashboard-idp264272">
     <title>Cookies</title>
     <para>Session Cookies should be set to HTTPONLY:</para>
-    <screen> 
+    <screen>
 SESSION_COOKIE_HTTPONLY = True</screen>
     <para>Never configure CSRF or session cookies to have a wild card
       domain with a leading dot. Horizon's session and CSRF cookie
       should be secured when deployed with HTTPS:</para>
-    <screen> 
+    <screen>
 Code CSRF_COOKIE_SECURE = True
 SESSION_COOKIE_SECURE = True</screen>
   </section>

doc/security-guide/ch026_compute.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch026_compute"><?dbhtml stop-chunking?>
     <title>Compute</title>
-    <para>The Compute service (nova) is one of the more complex OpenStack services.  It runs in many locations throughout the cloud and interacts with a variety of internal services.  For this reason, most of our recommendations regarding best practices for Compute service configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database.</para>
+    <para>The Compute service (nova) is one of the more complex OpenStack services. It runs in many locations throughout the cloud and interacts with a variety of internal services. For this reason, most of our recommendations regarding best practices for Compute service configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database.</para>
     <section xml:id="ch026_compute-idp45072">
       <title>Virtual Console Selection</title>
       <para>One decision a cloud architect will need to make regarding
@@ -11,12 +11,12 @@
       the differences between these options.</para>
       <section xml:id="ch026_compute-idp46336">
         <title>Virtual Network Computer (VNC)</title>
-        <para>OpenStack can be configured to provide remote desktop console access to instances for tenants and/or administrators using the Virtual Network Computer (VNC) protocol.  </para>
+        <para>OpenStack can be configured to provide remote desktop console access to instances for tenants and/or administrators using the Virtual Network Computer (VNC) protocol.</para>
       </section>
       <section xml:id="ch026_compute-idp48352">
         <title>Capabilities</title>
         <itemizedlist><listitem>
-            <para>The OpenStack Dashboard (Horizon) can provide a VNC console for instances directly on the web page using the HTML5 noVNC client.  This requires the <systemitem class="service">nova-novncproxy</systemitem> service to bridge from the public network to the management network.</para>
+            <para>The OpenStack Dashboard (Horizon) can provide a VNC console for instances directly on the web page using the HTML5 noVNC client. This requires the <systemitem class="service">nova-novncproxy</systemitem> service to bridge from the public network to the management network.</para>
           </listitem>
 <listitem>
             <para>The <command>nova</command> command-line utility can
@@ -50,7 +50,7 @@
         <section xml:id="ch026_compute-idp57120">
           <title>Capabilities</title>
           <itemizedlist><listitem>
-              <para>SPICE is supported by the OpenStack Dashboard (Horizon) directly on the instance web page.  This requires the nova-spicehtml5proxy service.</para>
+              <para>SPICE is supported by the OpenStack Dashboard (Horizon) directly on the instance web page. This requires the nova-spicehtml5proxy service.</para>
             </listitem>
 <listitem>
               <para>The nova command-line utility can return a URL for SPICE console for access by a SPICE-html client.</para>
@@ -60,7 +60,7 @@
         <section xml:id="ch026_compute-idm4576">
           <title>Limitations</title>
           <itemizedlist><listitem>
-              <para>Although SPICE has many advantages over VNC, the spice-html5 browser integration currently doesn't really allow admins to take advantage of any of the benefits. To take advantage of SPICE features like multi-monitor, USB pass through, etc. admins are recommended to use a standalone SPICE client within the Management Network.</para>
+              <para>Although SPICE has many advantages over VNC, the spice-html5 browser integration currently doesn't really allow admins to take advantage of any of the benefits. To take advantage of SPICE features like multi-monitor, USB pass through, etc. admins are recommended to use a standalone SPICE client within the Management Network.</para>
             </listitem>
 </itemizedlist>
         </section>

doc/security-guide/ch028_case-studies-identity-management.xml

@@ -5,13 +5,13 @@
     <section xml:id="ch028_case-studies-identity-management-idp87424">
       <title>Alice's Private Cloud</title>
       <para>Alice's enterprise has a well-established directory service with two-factor authentication for all users. She configures Keystone to support an external authentication service supporting authentication with government-issued access cards. She also uses an external LDAP server to provide role information for the users that is integrated with the access control policy. Due to FedRAMP compliance requirements, Alice implements two-factor authentication on the Management network for all administrator access.</para>
-      <para>Alice also deploys the Dashboard to manage many aspects of the cloud.  She deploys the Dashboard with HSTS to ensure that only HTTPS is used.  The Dashboard resides within an internal subdomain of the private network domain name system.</para>
+      <para>Alice also deploys the Dashboard to manage many aspects of the cloud. She deploys the Dashboard with HSTS to ensure that only HTTPS is used. The Dashboard resides within an internal subdomain of the private network domain name system.</para>
-      <para>Alice decides to use SPICE instead of VNC for the virtual console.  She wants to take advantage of the emerging capabilities in SPICE.</para>
+      <para>Alice decides to use SPICE instead of VNC for the virtual console. She wants to take advantage of the emerging capabilities in SPICE.</para>
     </section>
     <section xml:id="ch028_case-studies-identity-management-idp131936">
       <title>Bob's Public Cloud</title>
       <para>Bob must support authentication by the general public, so he elects to use provide for username / password authentication. He has concerns about brute force attacks attempting to crack user passwords, so he also uses an external authentication extension that throttles the number of failed login attempts. Bob's Management network is separate from the other networks within his cloud, but can be reached from his corporate network via ssh. As recommended earlier, Bob requires administrators to use two-factor authentication on the Management network to reduce the risk from compromised administrator passwords.</para>
-      <para>Bob also deploys the Dashboard to manage many aspects of the cloud.  He deploys the Dashboard with HSTS to ensure that only HTTPS is used.  He has ensured that the Dashboard is deployed on a second-level domain due to the limitations of the same-origin policy. He also disables HORIZON_IMAGES_ALLOW_UPLOAD to prevent resource exhaustion.</para>
+      <para>Bob also deploys the Dashboard to manage many aspects of the cloud. He deploys the Dashboard with HSTS to ensure that only HTTPS is used. He has ensured that the Dashboard is deployed on a second-level domain due to the limitations of the same-origin policy. He also disables HORIZON_IMAGES_ALLOW_UPLOAD to prevent resource exhaustion.</para>
       <para>Bob decides to use VNC for his virtual console for its maturity and security features.</para>
     </section>
   </chapter>

doc/security-guide/ch031_neutron-architecture.xml

@@ -29,7 +29,7 @@
 </inlinemediaobject></para>
     <section xml:id="ch031_neutron-architecture-idp61360">
       <title>OS Networking Service placement on Physical Servers</title>
-      <para>In this guide, we focus primarily on a standard architecture that includes a <emphasis>cloud controller</emphasis> host, a <emphasis>network</emphasis> host, and a set of <emphasis>compute</emphasis> hypervisors for running VMs.</para>
+      <para>In this guide, we focus primarily on a standard architecture that includes a <emphasis>cloud controller</emphasis> host, a <emphasis>network</emphasis> host, and a set of <emphasis>compute</emphasis> hypervisors for running VMs.</para>
       <section xml:id="ch031_neutron-architecture-idp63888">
         <title>Network Connectivity of Physical Servers</title>
         <para><inlinemediaobject><imageobject role="html">
@@ -50,7 +50,7 @@
             <para><emphasis role="bold">External network</emphasis> Used to provide VMs with Internet access in some deployment scenarios. The IP addresses on this network should be reachable by anyone on the Internet and is considered to be in the Public Security Domain.</para>
           </listitem>
 <listitem>
-            <para><emphasis role="bold">API network</emphasis> Exposes all OpenStack APIs, including the OpenStack Networking API, to tenants. The IP addresses on this network should be reachable by anyone on the Internet. This may be the same network as the external network, as it is possible to create a subnet for the external network that uses IP allocation ranges to use only less than the full range of IP addresses in an IP block. This network is considered the Public Security Domain.</para>
+            <para><emphasis role="bold">API network</emphasis> Exposes all OpenStack APIs, including the OpenStack Networking API, to tenants. The IP addresses on this network should be reachable by anyone on the Internet. This may be the same network as the external network, as it is possible to create a subnet for the external network that uses IP allocation ranges to use only less than the full range of IP addresses in an IP block. This network is considered the Public Security Domain.</para>
           </listitem>
 </itemizedlist>
         <para>For additional information see the <link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html">Networking chapter</link> in the

doc/security-guide/ch032_networking-best-practices.xml

@@ -9,7 +9,7 @@
       <section xml:id="ch032_networking-best-practices-idp46832">
         <title>VLANs</title>
         <para>VLANs are realized as packets on a specific physical network containing IEEE 802.1Q headers with a specific VLAN ID (VID) field value. VLAN networks sharing the same physical network are isolated from each other at L2, and can even have overlapping IP address spaces. Each distinct physical network supporting VLAN networks is treated as a separate VLAN trunk, with a distinct space of VID values. Valid VID values are 1 through 4094.</para>
-        <para>VLAN configuration complexity depends on your OpenStack design requirements. In order to allow OpenStack Networking to efficiently use VLANs, you must allocate a VLAN range (one for each tenant) and turn each compute node physical switch port into a VLAN trunk port.</para>
+        <para>VLAN configuration complexity depends on your OpenStack design requirements. In order to allow OpenStack Networking to efficiently use VLANs, you must allocate a VLAN range (one for each tenant) and turn each compute node physical switch port into a VLAN trunk port.</para>
         <note>
           <para>NOTE: If you intend for your network to support more than 4094 tenants VLAN is probably not the correct option for you as multiple 'hacks' are required to extend the VLAN tags to more than 4094 tenants.</para>
         </note>
@@ -39,7 +39,7 @@
       </section>
       <section xml:id="ch032_networking-best-practices-idp62880">
         <title>Quality of Service (QoS)</title>
-        <para>The ability to set QoS on the virtual interface ports of tenant instances is a current deficiency for OpenStack Networking. The application of QoS for traffic shaping and rate-limiting at the physical network edge device is insufficient due to the dynamic nature of workloads in an OpenStack deployment and can not be leveraged in the traditional way.  QoS-as-a-Service (QoSaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. QoSaaS is planning to provide the following services:</para>
+        <para>The ability to set QoS on the virtual interface ports of tenant instances is a current deficiency for OpenStack Networking. The application of QoS for traffic shaping and rate-limiting at the physical network edge device is insufficient due to the dynamic nature of workloads in an OpenStack deployment and can not be leveraged in the traditional way. QoS-as-a-Service (QoSaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. QoSaaS is planning to provide the following services:</para>
         <itemizedlist><listitem>
             <para>Traffic shaping via DSCP markings</para>
           </listitem>
@@ -57,11 +57,11 @@
       </section>
       <section xml:id="ch032_networking-best-practices-idp69408">
         <title>Load Balancing</title>
-        <para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.</para>
+        <para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.</para>
       </section>
       <section xml:id="ch032_networking-best-practices-idp71664">
         <title>Firewalls</title>
-        <para>FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plug-ins in development for extensions in OpenStack Networking to support this.</para>
+        <para>FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plug-ins in development for extensions in OpenStack Networking to support this.</para>
         <para>It is critical during the design of an OpenStack Networking infrastructure to understand the current features and limitations of network services that are available. Understanding where the boundaries of your virtual and physical networks will help you add the required security controls in your environment.</para>
       </section>
     </section>

doc/security-guide/ch033_securing-neutron-services.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch033_securing-neutron-services"><?dbhtml stop-chunking?>
     <title>Securing OpenStack Networking Services</title>
-    <para>In order to secure OpenStack Networking, an understanding of the workflow process for tenant instance creation needs to be mapped to security domains. </para>
+    <para>In order to secure OpenStack Networking, an understanding of the workflow process for tenant instance creation needs to be mapped to security domains.</para>
     <para>There are four main services that interact with OpenStack Networking. In a typical OpenStack deployment these services map to the following security domains:</para>
     <itemizedlist><listitem>
         <para>OpenStack Dashboard: Public and Management</para>
@@ -33,7 +33,7 @@
       <section xml:id="ch033_securing-neutron-services-idp56016">
         <title>Restrict Bind Address of the API server: neutron-server</title>
         <para>To restrict the interface or IP address on which the OpenStack Networking API service binds a network socket for incoming client connections, specify the bind_host and bind_port in the neutron.conf file as shown:</para>
-        <screen> 
+        <screen>
 # Address to bind the API server
 bind_host = &lt;ip address of server&gt;
 

doc/security-guide/ch034_tenant-secure-networking-best-practices.xml

@@ -41,7 +41,7 @@
     <section xml:id="ch034_tenant-secure-networking-best-practices-idp58016">
       <title>Quotas</title>
       <para>Quotas provide the ability to limit the number of network resources available to tenants. You can enforce default quotas for all tenants.</para>
-      <screen> 
+      <screen>
 /etc/neutron/neutron.conf
 [QUOTAS]
 # resource name(s) that are supported in quota features
@@ -68,7 +68,7 @@ quota_security_group_rule = 100
 # default driver to use for quota checks
 quota_driver = neutron.quota.ConfDriver</screen>
       <para>OpenStack Networking also supports per-tenant quotas limit via a quota extension API. To enable per-tenant quotas, you need to set <literal>quota_driver</literal> in <literal>neutron.conf</literal>.</para>
-      <screen> 
+      <screen>
 quota_driver = neutron.db.quota_db.DbQuotaDriver</screen>
     </section>
   </chapter>

doc/security-guide/ch038_transport-security.xml

@@ -9,7 +9,7 @@
       <section xml:id="ch038_transport-security-idp40512">
         <title>RabbitMQ Server SSL Configuration</title>
         <para>The following lines should be added to the system-wide RabbitMQ configuration file, typically /etc/rabbitmq/rabbitmq.config:</para>
-        <screen> 
+        <screen>
 [
   {rabbit, [
      {tcp_listeners, [] },
@@ -49,10 +49,10 @@
       <section xml:id="ch038_transport-security-idp52640">
         <title>Authentication Configuration Example - RabbitMQ</title>
         <para>On the RabbitMQ server, delete the default 'guest' user:</para>
-        <screen> 
+        <screen>
 rabbitmqctl delete_user quest</screen>
         <para>On the RabbitMQ server, for each OpenStack service or node that communicates with the message queue set up user accounts and privileges:</para>
-        <screen> 
+        <screen>
 rabbitmqctl add_user compute01 password
 rabbitmqctl set_permissions compute01 ".*"".*"".*"</screen>
         <para>For additional configuration information see:</para>
@@ -117,7 +117,7 @@ qpid_sasl_mechanisms=&lt;space separated list of SASL mechanisms to use for auth
       <section xml:id="ch038_transport-security-idp70304">
         <title>Namespaces</title>
         <para>Network namespaces are highly recommended for all services running on OpenStack Compute Hypervisors. This will help prevent against the bridging of network traffic between VM guests and the management network.</para>
-        <para>When using ZeroMQ messaging, each host must run at least one ZeroMQ message receiver to receive messages from the network and forward messages to local processes via IPC. It is possible and advisable to run an independent message receiver per project within an IPC namespace, along with other services within the same project.</para>
+        <para>When using ZeroMQ messaging, each host must run at least one ZeroMQ message receiver to receive messages from the network and forward messages to local processes via IPC. It is possible and advisable to run an independent message receiver per project within an IPC namespace, along with other services within the same project.</para>
       </section>
       <section xml:id="ch038_transport-security-idp72736">
         <title>Network Policy</title>

doc/security-guide/ch042_database-overview.xml

@@ -5,7 +5,7 @@
     <section xml:id="ch042_database-overview-idp44624">
       <title>OpenStack Database Access Model</title>
       <para>All of the services within an OpenStack project access a single database. There are presently no reference policies for creating table or row based access restrictions to the database.</para>
-      <para>There are no general provisions for granular control of database operations in OpenStack. Access and privileges are granted simply based on whether a node has access to the database or not.  In this scenario, nodes with access to the database may have full privileges to DROP, INSERT, or UPDATE functions.</para>
+      <para>There are no general provisions for granular control of database operations in OpenStack. Access and privileges are granted simply based on whether a node has access to the database or not. In this scenario, nodes with access to the database may have full privileges to DROP, INSERT, or UPDATE functions.</para>
       <section xml:id="ch042_database-overview-idp46912">
         <title>Granular Access Control</title>
         <para>By default, each of the OpenStack services and their processes access the database using a shared set of credentials. This makes auditing database operations and revoking access privileges from a service and its processes to the database particularly difficult.</para>
@@ -45,7 +45,7 @@
     </section>
     <section xml:id="ch042_database-overview-idp83456">
       <title>Database Authentication and Access Control</title>
-      <para>Given the risks around access to the database, we strongly recommend that unique database user accounts be created per node needing access to the database. Doing this facilitates better analysis and auditing for ensuring compliance or in the event of a compromise of a node allows you to isolate the compromised host by removing access for that node to the database upon detection. When creating these per service endpoint database user accounts, care should be taken to ensure that they are configured to require SSL.  Alternatively, for increased security it is recommended that the database accounts be configured using X.509 certificate authentication in addition to usernames and passwords.</para>
+      <para>Given the risks around access to the database, we strongly recommend that unique database user accounts be created per node needing access to the database. Doing this facilitates better analysis and auditing for ensuring compliance or in the event of a compromise of a node allows you to isolate the compromised host by removing access for that node to the database upon detection. When creating these per service endpoint database user accounts, care should be taken to ensure that they are configured to require SSL. Alternatively, for increased security it is recommended that the database accounts be configured using X.509 certificate authentication in addition to usernames and passwords.</para>
       <section xml:id="ch042_database-overview-idp85888">
         <title>Privileges</title>
         <para>A separate database administrator (DBA) account should be created and protected that has full privileges to create/drop databases, create user accounts, and update user privileges. This simple means of separation of responsibility helps prevent accidental misconfiguration, lowers risk and lowers scope of compromise.</para>
@@ -56,13 +56,13 @@
       <title>Require User Accounts to Require SSL Transport</title>
       <section xml:id="ch042_database-overview-idp88784">
         <title>Configuration Example #1: (MySQL)</title>
-        <screen> 
+        <screen>
 GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SSL;</screen>
       </section>
       <section xml:id="ch042_database-overview-idp90096">
         <title>Configuration Example #2: (PostgreSQL)</title>
         <para>In file pg_hba.conf:</para>
-        <screen> 
+        <screen>
 hostssl dbname compute01 hostname md5</screen>
         <para>Note this command only adds the ability to communicate over SSL and is non-exclusive. Other access methods that may allow unencrypted transport should be disabled so that SSL is the sole access method.</para>
         <para>The 'md5' parameter defines the authentication method as a hashed password. We provide a secure authentication example in the section below.</para>
@@ -70,17 +70,17 @@ hostssl dbname compute01 hostname md5</screen>
     </section>
     <section xml:id="ch042_database-overview-idp93120">
       <title>Authentication with X.509 Certificates</title>
-      <para>Security may be enhanced by requiring X.509 client certificates for authentication.  Authenticating to the database in this manner provides greater identity assurance of the client making the connection to the database and ensures that the communications are encrypted.</para>
+      <para>Security may be enhanced by requiring X.509 client certificates for authentication. Authenticating to the database in this manner provides greater identity assurance of the client making the connection to the database and ensures that the communications are encrypted.</para>
       <section xml:id="ch042_database-overview-idp94704">
         <title>Configuration Example #1: (MySQL)</title>
-        <screen> 
+        <screen>
 GRANT ALL on dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SUBJECT
 '/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=compute01' AND ISSUER
 '/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=cloud-ca';</screen>
       </section>
       <section xml:id="ch042_database-overview-idp96192">
         <title>Configuration Example #2: (PostgreSQL)</title>
-        <screen> 
+        <screen>
 hostssl dbname compute01 hostname cert</screen>
       </section>
     </section>
@@ -109,7 +109,7 @@ charset=utf8&amp;ssl_ca=/etc/mysql/cacert.pem&amp;ssl_cert=/etc/mysql/server-cer
       <para>Note, as <systemitem class="service">nova-conductor</systemitem> only applies to OpenStack Compute, direct database access from compute hosts may still be necessary for the operation of other OpenStack components such as Telemetry (Ceilometer), Networking, and Block Storage.</para>
       <para>Implementors should weigh the benefits and risks of both configurations before enabling or disabling the <systemitem class="service">nova-conductor</systemitem> service. We are not yet prepared to recommend the use of <systemitem class="service">nova-conductor</systemitem> in the Grizzly release. However, we do believe that this recommendation will change as additional features are added into OpenStack.</para>
       <para>To disable the <systemitem class="service">nova-conductor</systemitem>, place the following into your <filename>nova.conf</filename> file (on your compute hosts):</para>
-      <screen> 
+      <screen>
 [conductor]
 use_local = true</screen>
     </section>

doc/security-guide/ch043_database-transport-security.xml

@@ -8,7 +8,7 @@
       <section xml:id="ch043_database-transport-security-idp39696">
         <title>Restricting Bind Address for MySQL</title>
         <para>In my.cnf:</para>
-        <screen> 
+        <screen>
 [mysqld]
 ...
 bind-address &lt;ip address or hostname of management network interface&gt;</screen>
@@ -16,13 +16,13 @@ bind-address &lt;ip address or hostname of management network interface&gt;</scr
       <section xml:id="ch043_database-transport-security-idp41568">
         <title>Restricting Listen Address for PostgreSQL</title>
         <para>In postgresql.conf:</para>
-        <screen> 
+        <screen>
-listen_addresses = &lt;ip address or hostname of management network interface&gt;</screen>
+listen_addresses = &lt;ip address or hostname of management network interface&gt;</screen>
       </section>
     </section>
     <section xml:id="ch043_database-transport-security-idp43520">
       <title>Database Transport</title>
-      <para>In addition to restricting database communications to the management network, we also strongly recommend that the cloud administrator configure their database backend to require SSL. Using SSL for the database client connections  protects the communications from tampering and eavesdropping. As will be discussed in the next section, using SSL also provides the framework for doing database user authentication via X.509 certificates (commonly referred to as PKI). Below is guidance on how SSL is typically configured for the two popular database backends MySQL and PostgreSQL.</para>
+      <para>In addition to restricting database communications to the management network, we also strongly recommend that the cloud administrator configure their database backend to require SSL. Using SSL for the database client connections protects the communications from tampering and eavesdropping. As will be discussed in the next section, using SSL also provides the framework for doing database user authentication via X.509 certificates (commonly referred to as PKI). Below is guidance on how SSL is typically configured for the two popular database backends MySQL and PostgreSQL.</para>
       <note>
         <para>NOTE: When installing the certificate and key files, ensure that the file permissions are restricted, for example <literal>chmod 0600</literal>, and the ownership is restricted to the database daemon user to prevent unauthorized access by other processes and users on the database server.</para>
       </note>

doc/security-guide/ch044_case-studies-database.xml

@@ -8,6 +8,6 @@
     </section>
     <section xml:id="ch044_case-studies-database-idp40064">
       <title>Bob's Public Cloud</title>
-      <para>Bob is concerned about strong separation of his tenants' data, so he has elected to use the Postgres database , known for its stronger security features.  The database resides on the Management network and uses SSL with mutual authentication with the services. Since the database is on the Management network, the database uses certificates signed with the company's self-signed root certificate. Bob creates separate user accounts for each database user, and configures the database to use both passwords and X.509 certificates for authentication. He elects not to use the <systemitem class="service">nova-conductor</systemitem> sub-service due to a desire for fine-grained access control.</para>
+      <para>Bob is concerned about strong separation of his tenants' data, so he has elected to use the Postgres database , known for its stronger security features. The database resides on the Management network and uses SSL with mutual authentication with the services. Since the database is on the Management network, the database uses certificates signed with the company's self-signed root certificate. Bob creates separate user accounts for each database user, and configures the database to use both passwords and X.509 certificates for authentication. He elects not to use the <systemitem class="service">nova-conductor</systemitem> sub-service due to a desire for fine-grained access control.</para>
     </section>
   </chapter>

doc/security-guide/ch046_data-residency.xml

@@ -100,7 +100,7 @@
 </itemizedlist>
       <section xml:id="ch046_data-residency-idp73264">
         <title>Data not securely erased</title>
-        <para>Within OpenStack some data may be deleted, but not securely erased in the context of the NIST standards outlined above. This is generally applicable to most or all of the above-defined metadata and information stored in the database. This may be remediated with database and/or system configuration for auto vacuuming and periodic free-space wiping.</para>
+        <para>Within OpenStack some data may be deleted, but not securely erased in the context of the NIST standards outlined above. This is generally applicable to most or all of the above-defined metadata and information stored in the database. This may be remediated with database and/or system configuration for auto vacuuming and periodic free-space wiping.</para>
       </section>
       <section xml:id="ch046_data-residency-idp75184">
         <title>Instance memory scrubbing</title>

doc/security-guide/ch047_data-encryption.xml

@@ -18,7 +18,7 @@
 </itemizedlist>
     <section xml:id="ch047_data-encryption-idp50112">
       <title>Object Storage Objects</title>
-      <para>The ability to encrypt objects in Object Storage is presently limited to disk-level encryption per node. However, there does exist third-party extensions and modules for per-object encryption. These modules have been proposed upstream, but have not per this writing been formally accepted. Below are some pointers: </para>
+      <para>The ability to encrypt objects in Object Storage is presently limited to disk-level encryption per node. However, there does exist third-party extensions and modules for per-object encryption. These modules have been proposed upstream, but have not per this writing been formally accepted. Below are some pointers:</para>
       <para><link xmlns:xl="http://www.w3.org/1999/xlink" xl:href="https://github.com/Mirantis/swift-encrypt">https://github.com/Mirantis/swift-encrypt</link></para>
       <para><link xmlns:xl="http://www.w3.org/1999/xlink" xl:href="http://www.mirantis.com/blog/on-disk-encryption-prototype-for-openstack-swift/">http://www.mirantis.com/blog/on-disk-encryption-prototype-for-openstack-swift/</link></para>
     </section>
@@ -26,7 +26,7 @@
       <title>Block Storage Volumes &amp; Instance Ephemeral Filesystems</title>
       <para>The ability to encrypt volumes depends on the service backends chosen. Some backends may not support this at all.</para>
       <para>As both block storage and compute support LVM backed storage, we can easily provide an example applicable to both systems. In deployments using LVM, encryption may be performed against the backing physical volumes. An encrypted block device would be created using the standard Linux tools, with the LVM physical volume (PV) created on top of the decrypted block device using pvcreate. Then, the vgcreate or vgmodify tool may be used to add the encrypted physical volume to an LVM volume group (VG).</para>
-      <para>A feature aimed for the Havana release provides encryption of the VM's data before it is written to disk. This allows the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This feature presents a normal block storage device to the VM but encrypts the bytes in the virtualization host before writing them to the disk. The block server operates exactly as it does when reading and writing unencrypted blocks, except special handling will be required for Block Storage features such as snapshots and live migration.  Note that this feature uses an independent key manager.</para>
+      <para>A feature aimed for the Havana release provides encryption of the VM's data before it is written to disk. This allows the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This feature presents a normal block storage device to the VM but encrypts the bytes in the virtualization host before writing them to the disk. The block server operates exactly as it does when reading and writing unencrypted blocks, except special handling will be required for Block Storage features such as snapshots and live migration. Note that this feature uses an independent key manager.</para>
     </section>
     <section xml:id="ch047_data-encryption-idp57488">
       <title>Network Data</title>

doc/security-guide/ch048_key-management.xml

@@ -3,7 +3,7 @@
     <title>Key Management</title>
     <para>To address the often mentioned concern of tenant data privacy and limiting cloud provider liability, there is greater interest within the OpenStack community to make data encryption more ubiquitous. It is relatively easy for an end-user to encrypt their data prior to saving it to the cloud, and this is a viable path for tenant objects such as media files, database archives among others. However, when client side encryption is used for virtual machine images, block storage etc, client intervention is necessary in the form of presenting keys to unlock the data for further use. To seamlessly secure the data and yet have it accessible without burdening the client with having to manage their keys and interactively provide them calls for a key management service within OpenStack. Providing encryption and key management services as part of OpenStack eases data-at-rest security adoption, addresses customer concerns about the privacy and misuse of their data with the added advantage of limiting cloud provider liability. Provider liability is of concern in multi-tenant public clouds with respect to handing over tenant data during a misuse investigation.</para>
     <para>A key management service is in the early stages of being developed and has a way to go before becoming an official component of OpenStack. Refer to <link xlink:href="https://github.com/cloudkeep/barbican/wiki/_pages">https://github.com/cloudkeep/barbican/wiki/_pages</link> for details.</para>
-    <para>It shall support the creation of keys, and their secure saving (with a service master-key). Some of the design questions still being debated are how much of the Key Management Interchange Protocol (KMIP) to support, key formats, and certificate management.  The key manager will be pluggable to facilitate deployments that need a third-party Hardware Security Module (HSM).</para>
+    <para>It shall support the creation of keys, and their secure saving (with a service master-key). Some of the design questions still being debated are how much of the Key Management Interchange Protocol (KMIP) to support, key formats, and certificate management. The key manager will be pluggable to facilitate deployments that need a third-party Hardware Security Module (HSM).</para>
     <para>OpenStack Block Storage, Cinder, is the first service looking to integrate with the key manager to provide volume encryption.</para>
     <section xml:id="ch048_key-management-idp47776">
       <title>References:</title>

doc/security-guide/ch051_vss-intro.xml

@@ -19,7 +19,7 @@
     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>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>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>
     <section xml:id="ch051_vss-intro-idp236592">
       <title>Hypervisors in OpenStack</title>
       <para>Whether OpenStack is deployed within private data centers
@@ -123,7 +123,7 @@
               </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>
+                <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>
@@ -171,7 +171,7 @@
               <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
+                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
@@ -266,7 +266,7 @@
           <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>
+          <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">
@@ -317,7 +317,7 @@
       <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 will help 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>
+        <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/><col/></colgroup>
 
@@ -330,7 +330,7 @@
 
             <tbody>
               <tr>
-                <td><para> </para></td>
+                <td><para></para></td>
                 <td><para>KSM</para></td>
                 <td><para>XSM</para></td>
                 <td><para>sVirt</para></td>
@@ -342,7 +342,7 @@
               <tr>
                 <td><para>KVM</para></td>
                 <td><para>&CHECK;</para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
                 <td><para>&CHECK;</para></td>
                 <td><para>&CHECK;</para></td>
                 <td><para>&CHECK;</para></td>
@@ -351,33 +351,33 @@
               </tr>
               <tr>
                 <td><para>Xen</para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
                 <td><para>&CHECK;</para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
                 <td><para>&CHECK;</para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
                 <td><para>&CHECK;</para></td>
               </tr>
               <tr>
                 <td><para>ESXi</para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
                 <td><para>&CHECK;</para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
               </tr>
               <tr>
                 <td><para>Hyper-V</para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
-                <td><para> </para></td>
+                <td><para></para></td>
               </tr>
             </tbody>
           </informaltable>

doc/security-guide/ch052_devices.xml

@@ -14,7 +14,7 @@
         </listitem>
 </itemizedlist>
       <note>
-        <para>The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
+        <para>The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
       </note>
       <para>A hardware infection occurs when an instance makes a malicious modification to the firmware or some other part of a device. As this device is used by other instances, or even the host OS, the malicious code can spread into these systems. The end result is that one instance can run code outside of its security domain. This is a potential problem in any hardware sharing scenario. The problem is specific to this scenario because it is harder to reset the state of physical hardware than virtual hardware.</para>
       <para>Solutions to the hardware infection problem are domain specific. The strategy is to identify how an instance can modify hardware state then determine how to reset any modifications when the instance is done using the hardware. For example, one option could be to re-flash the firmware after use. Clearly there is a need to balance hardware longevity with security as some firmwares will fail after a large number of writes. TPM technology, described in <literal>link:Management/Node Bootstrapping</literal>, provides a solution for detecting unauthorized firmware changes. Regardless of the strategy selected, it is important to understand the risks associated with this kind of hardware sharing so that they can be properly mitigated for a given deployment scenario.</para>
@@ -47,10 +47,10 @@
         <title>Minimizing the Qemu Code base</title>
         <para>One classic security principle is to remove any unused components from your system. QEMU provides support for many different virtual hardware devices. However, only a small number of devices are needed for a given instance. Most instances will use the virtio devices. However, some legacy instances will need access to specific hardware, which can be specified using glance metadata:</para>
         <screen>glance image-update \
-    --property hw_disk_bus=ide \
+    --property hw_disk_bus=ide \
-    --property hw_cdrom_bus=ide \
+    --property hw_cdrom_bus=ide \
-    --property hw_vif_model=e1000 \
+    --property hw_vif_model=e1000 \
-    f16-x86_64-openstack-sda</screen>
+    f16-x86_64-openstack-sda</screen>
         <para>A cloud architect should decide what devices to make available to cloud users. Anything that is not needed should be removed from QEMU. This step requires recompiling QEMU after modifying the options passed to the QEMU configure script. For a complete list of up-to-date options simply run <literal>./configure --help</literal> from within the QEMU source directory. Decide what is needed for your deployment, and disable the remaining options.</para>
       </section>
       <section xml:id="ch052_devices-idp494336">
@@ -67,7 +67,7 @@
             <para><emphasis>Never eXecute (NX)</emphasis>: Also known as Data Execution Prevention (DEP), ensures that data sections of the executable can not be executed.</para>
           </listitem>
 <listitem>
-            <para><emphasis>Position Independent Executable (PIE)</emphasis>: Produces a position independent executable, which is necessary for ASLR.  </para>
+            <para><emphasis>Position Independent Executable (PIE)</emphasis>: Produces a position independent executable, which is necessary for ASLR.</para>
           </listitem>
 <listitem>
             <para><emphasis>Address Space Layout Randomization (ASLR)</emphasis> : This ensures that both code and data regions will be randomized. Enabled by the kernel (all modern linux kernels support ASLR), when the executable is built with PIE.</para>
@@ -134,7 +134,7 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-
             <imagedata contentdepth="100%" fileref="static/sVirt Diagram 1.png" format="PNG" scalefit="1" width="100%"/>
           </imageobject>
 </inlinemediaobject></para>
-      <para>As shown above, sVirt isolation is provided regardless of the guest Operating System running inside the virtual machine -- Linux or Windows VMs can be used. Additionally, many Linux distributions provide SELinux within the operating system, allowing the virtual machine to protect internal virtual resources from threats. </para>
+      <para>As shown above, sVirt isolation is provided regardless of the guest Operating System running inside the virtual machine -- Linux or Windows VMs can be used. Additionally, many Linux distributions provide SELinux within the operating system, allowing the virtual machine to protect internal virtual resources from threats.</para>
       <section xml:id="ch052_devices-idp523744">
         <title>Labels and Categories</title>
         <para>KVM-based virtual machine instances are labelled with their own SELinux data type, known as svirt_image_t. Kernel level protections prevent unauthorized system processes, such as malware, from manipulating the virtual machine image files on disk. When virtual machines are powered off, images are stored as svirt_image_t as shown below:</para>
@@ -159,7 +159,7 @@ system_u:object_r:svirt_image_t:s0:419,c172 image2</screen>
             <tbody>
               <tr>
                 <td><para><emphasis role="bold">sVirt SELinux Boolean</emphasis></para></td>
-                <td><para><emphasis role="bold"> Description</emphasis></para></td>
+                <td><para><emphasis role="bold">Description</emphasis></para></td>
               </tr>
               <tr>
                 <td><para>virt_use_common</para></td>

doc/security-guide/ch053_case-studies-instance-isolation.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch053_case-studies-instance-isolation"><?dbhtml stop-chunking?>
     <title>Case Studies: Instance Isolation</title>
-    <para>In this case study we discuss how Alice and Bob would ensure that  their instances are properly isolated. First we consider hypervisor selection, and then techniques for hardening QEMU and applying mandatory access controls.</para>
+    <para>In this case study we discuss how Alice and Bob would ensure that their instances are properly isolated. First we consider hypervisor selection, and then techniques for hardening QEMU and applying mandatory access controls.</para>
     <section xml:id="ch053_case-studies-instance-isolation-idp480000">
       <title>Alice's Private Cloud</title>
       <para>Alice chooses Xen for the hypervisor in her cloud due to a strong internal knowledge base and a desire to use the Xen security modules (XSM) for fine-grained policy enforcement.</para>

doc/security-guide/ch055_security-services-for-instances.xml

@@ -48,7 +48,7 @@
           </imageobject>
 </inlinemediaobject></para>
       <para>The use of scheduler filters may be used to segregate customers, data, or even discard machines of the cloud that cannot be attested as secure. This generally applies to all OpenStack projects offering a scheduler. When building a cloud, you may choose to implement scheduling filters for a variety of security-related purposes.</para>
-      <para>Below we highlight a few of the filters that may be useful in a security context, depending on your requirements, the full set of filter documentation is documented in the <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/filter-scheduler.html">Filter Scheduler</link> section of the <citetitle>OpenStack Configuration Reference</citetitle>.</para>
+      <para>Below we highlight a few of the filters that may be useful in a security context, depending on your requirements, the full set of filter documentation is documented in the <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/filter-scheduler.html">Filter Scheduler</link> section of the <citetitle>OpenStack Configuration Reference</citetitle>.</para>
       <para><emphasis role="bold">Tenant Driven Whole Host Reservation</emphasis></para>
       <para>There currently exists a <link xlink:href="https://blueprints.launchpad.net/nova/+spec/whole-host-allocation">blueprint for whole host reservation</link> -  This would allow a tenant to exclusively reserve hosts for only it's instances, incurring extra costs.</para>
       <section xml:id="ch055_security-services-for-instances-idp140080">
@@ -73,7 +73,7 @@
       </section>
       <section xml:id="ch055_security-services-for-instances-idp146208">
         <title>GroupAntiAffinityFilter</title>
-        <para>The GroupAntiAffinityFilter ensures that each instance in a group is on a different host. To take advantage of this filter, the requester must pass a scheduler hint, using <literal>group</literal> as the key and a list of instance uuids as the value.</para>
+        <para>The GroupAntiAffinityFilter ensures that each instance in a group is on a different host. To take advantage of this filter, the requester must pass a scheduler hint, using <literal>group</literal> as the key and a list of instance uuids as the value.</para>
       </section>
       <section xml:id="ch055_security-services-for-instances-idp148000">
         <title>Trusted Compute Pools</title>
@@ -88,18 +88,18 @@
         <title>Image Creation Process</title>
         <para>The OpenStack Documentation provides guidance on how to create and upload an image to Glance. Additionally it is assumed that you have a process by which you install and harden operating systems. Thus, the following items will provide additional guidance on how to ensure your images are built securely prior to upload. There are a variety of options for obtaining images. Each has specific steps that help validate the image's provenance.</para>
         <para>The first option is to obtain boot media from a trusted source.</para>
-        <screen> 
+        <screen>
 mkdir -p /tmp/download_directorycd /tmp/download_directory
 
 wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso
 wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS
 wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg
-gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
+gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
 gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2&gt;&amp;1 | grep OK
         </screen>
         <para>The second option is to use the <link xlink:href="http://docs.openstack.org/trunk/image-guide/content/"><citetitle>OpenStack Virtual Machine Image Guide</citetitle></link>. In this case, you will want to follow your organizations OS hardening guidelines or those provided by a trusted third-party such as the <link xlink:href="http://iase.disa.mil/stigs/os/unix/red_hat.html">RHEL6 STIG</link>.</para>
         <para>The final option is to use an automated image builder. The following example uses the Oz image builder. The OpenStack community has recently created a newer tool worth investigating: disk-image-builder. We have not evaluated this tool from a security perspective.</para>
-        <para>Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section <emphasis>AC-19(d) in</emphasis> Oz.</para>
+        <para>Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section<emphasis>AC-19(d) in</emphasis> Oz.</para>
         <screen>
 &lt;template&gt;
 &lt;name&gt;centos64&lt;/name&gt;
@@ -198,7 +198,7 @@ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2&gt;&amp;1 | grep
         <section xml:id="ch055_security-services-for-instances-idp187568">
           <title>Disable Live Migration</title>
           <para>At this time, live migration is enabled in OpenStack by default. Live migrations can be disabled by adding the following lines to the nova policy.json file:</para>
-          <screen> 
+          <screen>
 "compute_extension:admin_actions:migrate": "!",
 "compute_extension:admin_actions:migrateLive": "!",</screen>
         </section>

doc/security-guide/ch058_forensicsincident-response.xml

@@ -4,12 +4,12 @@
     <para>A lot of activity goes on within a cloud environment. It is a mix of hardware, operating systems, virtual machine managers, the OpenStack services, cloud-user activity such as creating instances and attaching storage, the network underlying the whole, and finally end-users using the applications running on the various instances.</para>
     <para>The generation and collection of logs is an important component of securely monitoring an OpenStack infrastructure. Logs provide visibility into the day-to-day actions of administrators, tenants, and guests, in addition to the activity in the compute, networking, and storage and other components that comprise your OpenStack deployment.</para>
     <para>The basics of logging: configuration, setting log level, location of the log files, and how to use and customize logs, as well as how to do centralized collections of logs is well covered in the <link xlink:href="http://docs.openstack.org/ops/"><citetitle>OpenStack Operations Guide</citetitle></link>.</para>
-    <para>Logs are not only valuable for proactive security and continuous compliance activities, but they are also a valuable information  source for investigating and responding to incidents.</para>
+    <para>Logs are not only valuable for proactive security and continuous compliance activities, but they are also a valuable information source for investigating and responding to incidents.</para>
     <para>For instance, analyzing the access logs of Identity Service or its replacement authentication system would alert us to failed logins, their frequency, origin IP, whether the events are restricted to select accounts etc. Log analysis supports detection.</para>
     <para>On detection, further action may be to black list an IP, or recommend strengthening user passwords, or even de-activating a user account if it is deemed dormant.</para>
     <section xml:id="ch058_forensicsincident-response-idp60511">
         <title>Monitoring Use Cases</title>
-    <para>Monitoring events is more pro-active and provides real-time detection and response.  There are several tools to aid in monitoring.</para>
+    <para>Monitoring events is more pro-active and provides real-time detection and response. There are several tools to aid in monitoring.</para>
     <para>In the case of an OpenStack cloud instance, we need to monitor the hardware, the OpenStack services, and the cloud resource usage. The last stems from wanting to be elastic, to scale to the dynamic needs of the users.</para>
     <para>Here are a few important use cases to consider when implementing log aggregation, analysis and monitoring. These use cases can be implemented and monitored through various commercial and open source tools, homegrown scripts, etc. These tools and scripts can generate events that can then be sent to the administrators through email or integrated dashboard. It is important to consider additional use cases that may apply to your specific network and what you may consider anomalous behavior.</para>
     <itemizedlist><listitem>
@@ -29,11 +29,11 @@
       </listitem>
 </itemizedlist>
     <itemizedlist><listitem>
-        <para>Other events that are actionable are networking bridges going down, ip tables being flushed on compute nodes and consequential loss of access to instances resulting in unhappy customers. </para>
+        <para>Other events that are actionable are networking bridges going down, ip tables being flushed on compute nodes and consequential loss of access to instances resulting in unhappy customers.</para>
       </listitem>
 </itemizedlist>
     <itemizedlist><listitem>
-        <para>To reduce security risks from orphan instances on a user/tenant/domain deletion in the Identity service there is discussion to generate notifications in the system and have OpenStack components respond to these events as appropriate such as terminating instances, disconnecting attached volumes, reclaiming CPU and storage resources etc. </para>
+        <para>To reduce security risks from orphan instances on a user/tenant/domain deletion in the Identity service there is discussion to generate notifications in the system and have OpenStack components respond to these events as appropriate such as terminating instances, disconnecting attached volumes, reclaiming CPU and storage resources etc.</para>
       </listitem>
 </itemizedlist>
     <para>A cloud will host many virtual instances, and monitoring these instances goes beyond hardware monitoring and log files which may just contain CRUD events.</para>

doc/security-guide/ch061_compliance-overview.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch061_compliance-overview"><?dbhtml stop-chunking?>
     <title>Compliance Overview</title>
-    <para>An OpenStack deployment may require compliance activities for many purposes, such as regulatory and legal requirements, customer need, privacy considerations, and security best practices. Compliance, when done correctly, unifies and strengthens the other security topics discussed in this guide. This chapter has several objectives:</para>
+    <para>An OpenStack deployment may require compliance activities for many purposes, such as regulatory and legal requirements, customer need, privacy considerations, and security best practices. Compliance, when done correctly, unifies and strengthens the other security topics discussed in this guide. This chapter has several objectives:</para>
     <itemizedlist><listitem>
         <para>Review common security principles.</para>
       </listitem>
@@ -25,7 +25,7 @@
           <para><emphasis>Fail Securely</emphasis>: In the case of failure, systems should be configured to fail into a closed secure state. For example, SSL certificate verification should fail closed by severing the network connection if the CNAME doesn't match the server's DNS name. Software often fails open in this situation, allowing the connection to proceed without a CNAME match, which is less secure and not recommended.</para>
         </listitem>
 <listitem>
-          <para><emphasis>Least Privilege</emphasis>: Only the minimum level of access for users and system services is granted. This access is based upon role, responsibility and job function. This security principal of least privilege is written into several international government security policies, such as NIST 800-53 Section AC-6 within the United States. </para>
+          <para><emphasis>Least Privilege</emphasis>: Only the minimum level of access for users and system services is granted. This access is based upon role, responsibility and job function. This security principal of least privilege is written into several international government security policies, such as NIST 800-53 Section AC-6 within the United States.</para>
         </listitem>
 <listitem>
           <para><emphasis>Compartmentalize</emphasis>: Systems should be segregated in a such way that if one machine, or system-level service, is compromised the security of the other systems will remain intact. Practically, the enablement and proper usage of SELinux helps accomplish this goal.</para>

doc/security-guide/ch062_audit-guidance.xml

@@ -6,7 +6,7 @@
         <para><emphasis role="bold">Implementation and Operation of Security Controls</emphasis>Aligning the information system with in-scope standards and regulations involves internal tasks which must be conducted before a formal assessment. Auditors may be involved at this state to conduct gap analysis, provide guidance, and increase the likelihood of successful certification.</para>
       </listitem>
 <listitem>
-        <para><emphasis role="bold">Independent Verification and Validation</emphasis>Demonstration to a neutral third-party that system security controls are implemented and operating effectively, in compliance with in-scope standards and regulations, is required before many information systems achieve certified status. Many certifications require periodic audits to ensure continued certification, considered part of an overarching continuous monitoring practice.  </para>
+        <para><emphasis role="bold">Independent Verification and Validation</emphasis>Demonstration to a neutral third-party that system security controls are implemented and operating effectively, in compliance with in-scope standards and regulations, is required before many information systems achieve certified status. Many certifications require periodic audits to ensure continued certification, considered part of an overarching continuous monitoring practice.</para>
       </listitem>
 </orderedlist>
     <section xml:id="ch062_audit-guidance-idp48608">
@@ -41,10 +41,10 @@
     </section>
     <section xml:id="ch062_audit-guidance-idp62672">
       <title>External Audit</title>
-      <para>This is the formal audit process. Auditors will test security controls in scope for a specific certification, and demand evidentiary requirements to prove that these controls were also in place for the audit window (for example SOC 2 audits generally evaluate security controls over a 6-12 months period).  Any control failures are logged, and will be documented in the external auditors final report.  Dependent on the type of OpenStack deployment, these reports may be viewed by customers, so it is important to avoid control failures. This is why audit preparation is so important.</para>
+      <para>This is the formal audit process. Auditors will test security controls in scope for a specific certification, and demand evidentiary requirements to prove that these controls were also in place for the audit window (for example SOC 2 audits generally evaluate security controls over a 6-12 months period). Any control failures are logged, and will be documented in the external auditors final report. Dependent on the type of OpenStack deployment, these reports may be viewed by customers, so it is important to avoid control failures. This is why audit preparation is so important.</para>
     </section>
     <section xml:id="ch062_audit-guidance-idp65008">
       <title>Compliance Maintenance</title>
-      <para>The process doesn't end with a single external audit. Most certifications require continual compliance activities which means repeating the audit process periodically.  We recommend integrating automated compliance verification tools into a cloud to ensure that it is compliant at all times. This should be in done in addition to other security monitoring tools. Remember that the goal is both security <emphasis>and</emphasis> compliance. Failing on either of these fronts will significantly complicate future audits.</para>
+      <para>The process doesn't end with a single external audit. Most certifications require continual compliance activities which means repeating the audit process periodically. We recommend integrating automated compliance verification tools into a cloud to ensure that it is compliant at all times. This should be in done in addition to other security monitoring tools. Remember that the goal is both security <emphasis>and</emphasis> compliance. Failing on either of these fronts will significantly complicate future audits.</para>
     </section>
   </chapter>

doc/security-guide/ch064_certifications-compliance-statements.xml

@@ -28,7 +28,7 @@
       processing credit card transactions will need PCI-DSS, clouds
       storing health care information require HIPAA, and clouds within
       the federal government may require FedRAMP/FISMA, and ITAR,
-      certifications. </para>
+      certifications.</para>
     <section
       xml:id="ch064_certifications-compliance-statements-idp47472">
       <title>SOC 1 (SSAE 16) / ISAE 3402</title>
@@ -130,7 +130,7 @@
       specifications for an Information Security Management System
       (ISMS). An ISMS is a comprehensive set of policies and processes
       that an organization creates and maintains to manage risk to
-      information assets.  These risks are based upon the
+      information assets. These risks are based upon the
       confidentiality, integrity, and availability (CIA) of user
       information. The CIA security triad has been used as a
       foundation for much of the chapters in this book.</para>
@@ -149,14 +149,14 @@
       unauthorized persons and that encryption for data 'at-rest' and
       'inflight' should be addressed.</para>
     <para>HIPAA is not a certification, rather a guide for protecting
-      healthcare data.  Similar to the PCI-DSS, the most important
+      healthcare data. Similar to the PCI-DSS, the most important
       issues with both PCI and HIPPA is that a breach of credit card
       information, and health data, does not occur. In the instance of a
       breach the cloud provider will be scrutinized for compliance
       with PCI and HIPPA controls. If proven compliant, the provider
       can be expected to immediately implement remedial controls,
       breach notification responsibilities, and significant
-      expenditure on additional compliance activities.  If not
+      expenditure on additional compliance activities. If not
       compliant, the cloud provider can expect on-site audit teams,
       fines, potential loss of merchant ID (PCI), and massive
       reputation impact.</para>
@@ -192,14 +192,14 @@
         an external Qualified Security Assessor (QSA) who creates a
         Report on Compliance (ROC), or by a Self-Assessment
         Questionnaire (SAQ) dependent on volume of card-holder
-        transactions.  </para>
+        transactions.</para>
       <para>OpenStack deployments which stores, processes, or
         transmits payment card details are in scope for the PCI-DSS.
         All OpenStack components that are not properly segmented from
         systems or networks that handle payment data fall under the
-        guidelines of the PCI-DSS. Segmentation in the context of
+        guidelines of the PCI-DSS. Segmentation in the context of
         PCI-DSS does not support multi-tenancy, but rather physical
-        separation (host/network). </para>
+        separation (host/network).</para>
       <para>For more details see <link
           xlink:href="https://www.pcisecuritystandards.org/security_standards/"
           >PCI security standards</link>.</para>

doc/user-guide-admin/section_cli_nova_manage_flavors.xml

@@ -111,7 +111,7 @@
                 <para>To create a flavor, specify a name, ID, RAM
                     size, disk size, and the number of VCPUs for the
                     flavor, as follows:</para>
-                <screen><prompt>$</prompt> <userinput>nova flavor-create <replaceable>FLAVOR_NAME</replaceable> <replaceable>FLAVOR_ID</replaceable> <replaceable>RAM_IN_MB ROOT_DISK_IN_GB</replaceable> <replaceable>NUMBER_OF_VCPUS</replaceable></userinput></screen>
+                <screen><prompt>$</prompt> <userinput>nova flavor-create <replaceable>FLAVOR_NAME</replaceable> <replaceable>FLAVOR_ID</replaceable> <replaceable>RAM_IN_MB ROOT_DISK_IN_GB</replaceable> <replaceable>NUMBER_OF_VCPUS</replaceable></userinput></screen>
                 <note>
                     <para>The flavor ID is a number from 1 to 255 and
                         cannot contain special characters or