Merge "Fix screen usage in Security Guide"

doc/security-guide/ch020_ssl-everywhere.xml

@@ -94,8 +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>
+        <programlisting>## see pound(8) for details
-## see pound(8) for details
 daemon      1
 ######################################################################
 ## global options:
@@ -143,13 +142,12 @@ ListenHTTPS
             Port    80
         End
     End
-End</screen>
+End</programlisting>
       </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>
-        <screen>
+        <programlisting># SSL x509 certificate file.
-# SSL x509 certificate file.
 pem-file = "
 # SSL protocol.
 ssl = on
@@ -181,14 +179,13 @@ syslog-facility = "daemon"
 daemon = off
 # Report client address using SENDPROXY protocol for haproxy
 # Disabling this until we upgrade to HAProxy 1.5
-write-proxy = off</screen>
+write-proxy = off</programlisting>
       </section>
     </section>
     <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>
+      <programlisting>server {
-server {
     listen : ssl;
     ssl_certificate ;
     ssl_certificate_key ;
@@ -201,11 +198,10 @@ server {
     location / {
 
     }
-}</screen>
+}</programlisting>
       <section xml:id="ch020_ssl-everywhere-idp55264">
         <title>Apache</title>
-        <screen>
+        <programlisting>&lt;VirtualHost &lt;ip address&gt;:80&gt;
-&lt;VirtualHost &lt;ip address&gt;:80&gt;
   ServerName &lt;site FQDN&gt;
   RedirectPermanent / https://&lt;site FQDN&gt;/
 &lt;/VirtualHost&gt;
@@ -228,11 +224,10 @@ server {
     # Or, in Apache http server 2.4 and later:
     # Require all granted
   &lt;/Directory&gt;
-&lt;/VirtualHost&gt;</screen>
+&lt;/VirtualHost&gt;</programlisting>
         <para>Compute API SSL endpoint in Apache2, which needs to be paired with
         a short WSGI script.</para>
-        <screen>
+        <programlisting>&lt;VirtualHost &lt;ip address&gt;:8447&gt;
-&lt;VirtualHost &lt;ip address&gt;:8447&gt;
   ServerName &lt;site FQDN&gt;
   SSLEngine On
   SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2,
@@ -250,14 +245,13 @@ server {
     # Or, in Apache http server 2.4 and later:
     # Require all granted
   &lt;/Directory&gt;
-&lt;/VirtualHost&gt;</screen>
+&lt;/VirtualHost&gt;</programlisting>
       </section>
     </section>
     <section xml:id="ch020_ssl-everywhere-idp59152">
       <title>HTTP Strict Transport Security</title>
       <para>We recommend that all production deployments use HSTS. This header prevents browsers from making insecure connections after they have made a single secure one. If you have deployed your HTTP services on a public or an untrusted domain, HSTS is especially important. To enable HSTS, configure your web server to send a header like this with all requests:</para>
-      <screen>
+      <screen><computeroutput>Strict-Transport-Security: max-age=31536000; includeSubDomains</computeroutput></screen>
-Strict-Transport-Security: max-age=31536000; includeSubDomains</screen>
       <para>Start with a short timeout of 1 day during testing, and raise it to one year after testing has shown that you haven't introduced problems for users. Note that once this header is set to a large timeout, it is (by design) very difficult to disable.</para>
     </section>
   </chapter>

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

@@ -10,13 +10,12 @@
         <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><prompt>$</prompt> <userinput>keystone endpoint-create \
-$ keystone endpoint-create \
  --region RegionOne \
  --service-id=1ff4ece13c3e48d8a6461faebd9cd38f \
  --publicurl='https://public-ip:8776/v1/%(tenant_id)s' \
  --internalurl='https://management-ip:8776/v1/%(tenant_id)s' \
- --adminurl='https://management-ip:8776/v1/%(tenant_id)s'</screen>
+ --adminurl='https://management-ip:8776/v1/%(tenant_id)s'</userinput></screen>
       </section>
       <section xml:id="ch021_paste-and-middleware-idp43360">
         <title>Configure Applications for Internal URLs</title>
@@ -24,19 +23,17 @@ $ keystone endpoint-create \
         <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>
+          <programlisting language="ini">[DEFAULT]
-[DEFAULT]
 cinder_catalog_info='volume:cinder:internalURL'
 glance_protocol='https'
 neutron_url='https://neutron-host:9696'
 neutron_admin_auth_url='https://neutron-host:9696'
 s3_host='s3-host'
-s3_use_ssl=True</screen>
+s3_use_ssl=True</programlisting>
         </section>
         <section xml:id="ch021_paste-and-middleware-idp47184">
           <title>Configuration Example #2: Cinder</title>
-          <screen>
+          <programlisting language="ini">glance_host='https://glance-server'</programlisting>
-glance_host='https://glance-server'</screen>
         </section>
       </section>
     </section>

doc/security-guide/ch025_web-dashboard.xml

@@ -178,14 +178,12 @@
   <section xml:id="ch025_web-dashboard-idp264272">
     <title>Cookies</title>
     <para>Session Cookies should be set to HTTPONLY:</para>
-    <screen>
+    <programlisting>SESSION_COOKIE_HTTPONLY = True</programlisting>
-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>
+    <programlisting>Code CSRF_COOKIE_SECURE = True
-Code CSRF_COOKIE_SECURE = True
+SESSION_COOKIE_SECURE = True</programlisting>
-SESSION_COOKIE_SECURE = True</screen>
   </section>
   <section xml:id="ch025_web-dashboard-idp266976">
     <title>Password Auto Complete</title>
@@ -228,8 +226,7 @@ SESSION_COOKIE_SECURE = True</screen>
     <para>Configure your web server to send a restrictive CORS header
       with each response, allowing only the Horizon domain and
       protocol:</para>
-    <screen>
+    <programlisting>Access-Control-Allow-Origin: https://example.com/</programlisting>
-Access-Control-Allow-Origin: https://example.com/</screen>
     <para>Never allow the wild card origin.</para>
   </section>
   <section xml:id="ch025_web-dashboard-idp275056">

doc/security-guide/ch027_storage.xml

@@ -130,11 +130,9 @@
             <para>/etc/swift contains information about the ring
                 topology and environment configuration. The following
                 permissions are recommended:</para>
-            <screen>
+            <screen><prompt>#</prompt> <userinput>chown -R root:swift /etc/swift/*</userinput>
-                <prompt>#</prompt><userinput>chown -R root:swift /etc/swift/*</userinput>
+<prompt>#</prompt> <userinput>find /etc/swift/ -type f -exec chmod 640 {} \;</userinput>
-                <prompt>#</prompt><userinput>find /etc/swift/ -type f -exec chmod 640 {} \;</userinput>
+<prompt>#</prompt> <userinput>find /etc/swift/ -type d -exec chmod 750 {} \;</userinput></screen>
-                <prompt>#</prompt><userinput>find /etc/swift/ -type d -exec chmod 750 {} \;</userinput>
-            </screen>
             <para>This restricts only root to be able to modify
                 configuration files while allowing the services to
                 read them via their group membership in

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

@@ -33,12 +33,12 @@
       <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>
+        <programlisting language="ini">
 # Address to bind the API server
-bind_host = &lt;ip address of server&gt;
+bind_host = <replaceable>IP ADDRESS OF SERVER</replaceable>
 
 # Port the bind the API server to
-bind_port = 9696</screen>
+bind_port = 9696</programlisting>
       </section>
       <section xml:id="ch033_securing-neutron-services-idp58320">
         <title>Restrict DB and RPC communication of the OpenStack Networking services:</title>

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

@@ -40,10 +40,13 @@
     </section>
     <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>
+      <para>Quotas provide the ability to limit the number of network
-/etc/neutron/neutron.conf
+      resources available to tenants. You can enforce default quotas
-[QUOTAS]
+      for all tenants. The
+      <filename>/etc/neutron/neutron.conf</filename> includes these
+      options for quota:</para>
+      <programlisting language="ini">[QUOTAS]
 # resource name(s) that are supported in quota features
 quota_items = network,subnet,port
 
@@ -66,9 +69,11 @@ quota_security_group = 10
 quota_security_group_rule = 100
 
 # default driver to use for quota checks
-quota_driver = neutron.quota.ConfDriver</screen>
+quota_driver = neutron.quota.ConfDriver</programlisting>
-      <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>
+      <para>OpenStack Networking also supports per-tenant quotas limit
-      <screen>
+      via a quota extension API. To enable per-tenant quotas, you must
-quota_driver = neutron.db.quota_db.DbQuotaDriver</screen>
+      set the <literal>quota_driver</literal> option in
+      <filename>neutron.conf</filename>.</para>
+      <programlisting language="ini">quota_driver = neutron.db.quota_db.DbQuotaDriver</programlisting>
     </section>
   </chapter>

doc/security-guide/ch038_transport-security.xml

@@ -8,9 +8,11 @@
       <para>We highly recommend enabling transport-level cryptography for your message queue. Using SSL for the messaging client connections provides protection of the communications from tampering and eavesdropping in-transit to the messaging server. Below is guidance on how SSL is typically configured for the two popular messaging servers Qpid and RabbitMQ. When configuring the trusted certificate authority (CA) bundle that your messaging server uses to verify client connections, it is recommended that this be limited to only the CA used for your nodes, preferably an internally managed CA. The bundle of trusted CAs will determine which client certificates will be authorized and pass the client-server verification step of the setting up the SSL connection. Note, when installing the certificate and key files, ensure that the file permissions are restricted, for example chmod 0600, and the ownership is restricted to the messaging server daemon user to prevent unauthorized access by other processes and users on the messaging server.</para>
       <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>
+        <para>The following lines should be added to the system-wide
-        <screen>
+        RabbitMQ configuration file, typically
-[
+        <filename>/etc/rabbitmq/rabbitmq.config</filename>:
+        </para>
+        <programlisting>[
   {rabbit, [
      {tcp_listeners, [] },
      {ssl_listeners, [{"&lt;ip address or hostname of management network interface", 5671}] },
@@ -20,11 +22,17 @@
                     {verify,verify_peer},
                     {fail_if_no_peer_cert,true}]}
    ]}
-].</screen>
+].</programlisting>
-        <para>Note, the 'tcp_listeners' option is set to '[]' to prevent it from listening an on non-SSL port. 'ssl_listeners' option should be restricted to only listen on the management network for the services.</para>
+        <para>Note, the <literal>tcp_listeners</literal> option is set
+        to <literal>[]</literal> to prevent it from listening an on
+        non-SSL port. The <literal>ssl_listeners</literal> option
+        should be restricted to only listen on the management network
+        for the services.</para>
         <para>For more information on RabbitMQ SSL configuration see:</para>
         <itemizedlist><listitem>
-            <para><link xlink:href="http://www.rabbitmq.com/configure.html">RabbitMQ Configuration</link></para>
+            <para>
+              <link xlink:href="http://www.rabbitmq.com/configure.html">RabbitMQ Configuration</link>
+            </para>
           </listitem>
 <listitem>
             <para><link xlink:href="http://www.rabbitmq.com/ssl.html">RabbitMQ SSL</link></para>
@@ -45,16 +53,20 @@
       <para>RabbitMQ and Qpid offer authentication and access control mechanisms for controlling access to queues. ZeroMQ offers no such mechanisms.</para>
       <para>Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. Both RabbitMQ and Qpid offer SASL and other pluggable authentication mechanisms beyond simple usernames and passwords that allow for increased authentication security. While RabbitMQ supports SASL, support in OpenStack does not currently allow for requesting a specific SASL authentication mechanism. RabbitMQ support in OpenStack allows for either username and password authentication over an unencrypted connection or username and password in conjunction with X.509 client certificates to establish the secure SSL connection.</para>
       <para>We recommend configuring X.509 client certificates on all the OpenStack service nodes for client connections to the messaging queue and where possible (currently only Qpid) perform authentication with X.509 client certificates. When using usernames and passwords, accounts should be created per-service and node for finer grained auditability of access to the queue.</para>
-      <para>The SSL libraries in use by these queuing servers should also be considered prior to deployment. Qpid uses Mozilla's NSS library, whereas RabbitMQ uses Erlang's SSL module which uses OpenSSL.</para>
+      <para>
+        Before deployment, consider the SSL libraries that the queuing
+        servers use. Qpid uses Mozilla's NSS library, whereas RabbitMQ
+        uses Erlang's SSL module which uses OpenSSL.</para>
       <section xml:id="ch038_transport-security-idp52640">
         <title>Authentication Configuration Example - RabbitMQ</title>
-        <para>On the RabbitMQ server, delete the default 'guest' user:</para>
+        <para>On the RabbitMQ server, delete the default
-        <screen>
+        <literal>guest</literal> user:</para>
-rabbitmqctl delete_user quest</screen>
+        <screen><prompt>#</prompt> <userinput>rabbitmqctl delete_user quest</userinput></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>
+        <para>On the RabbitMQ server, for each OpenStack service or
-        <screen>
+        node that communicates with the message queue set up user
-rabbitmqctl add_user compute01 password
+        accounts and privileges:</para>
-rabbitmqctl set_permissions compute01 ".*"".*"".*"</screen>
+        <screen><prompt>#</prompt> <userinput>rabbitmqctl add_user compute01 password</userinput>
+<prompt>#</prompt> <userinput>rabbitmqctl set_permissions compute01 ".*"".*"".*"</userinput></screen>
         <para>For additional configuration information see:</para>
         <itemizedlist><listitem>
             <para><link xlink:href="http://www.rabbitmq.com/access-control.html">RabbitMQ Access Control</link></para>
@@ -72,8 +84,7 @@ rabbitmqctl set_permissions compute01 ".*"".*"".*"</screen>
       </section>
       <section xml:id="ch038_transport-security-idp59648">
         <title>OpenStack Service Configuration - RabbitMQ</title>
-        <screen>
+        <programlisting language="ini">[DEFAULT]
-[DEFAULT]
 rpc_backend=nova.openstack.common.rpc.impl_kombu
 rabbit_use_ssl=True
 rabbit_host=
@@ -82,7 +93,7 @@ rabbit_user=compute01
 rabbit_password=password
 kombu_ssl_keyfile=/etc/ssl/node-key.pem
 kombu_ssl_certfile=/etc/ssl/node-cert.pem
-kombu_ssl_ca_certs=/etc/ssl/cacert.pem</screen>
+kombu_ssl_ca_certs=/etc/ssl/cacert.pem</programlisting>
       </section>
       <section xml:id="ch038_transport-security-idp62112">
         <title>Authentication Configuration Example - Qpid</title>
@@ -97,17 +108,16 @@ kombu_ssl_ca_certs=/etc/ssl/cacert.pem</screen>
       </section>
       <section xml:id="ch038_transport-security-idp65584">
         <title>OpenStack Service Configuration - Qpid</title>
-        <screen>
+        <programlisting language="ini">
 [DEFAULT]
 rpc_backend=nova.openstack.common.rpc.impl_qpid
 qpid_protocol=ssl
 qpid_hostname=&lt;ip or hostname of management network interface of messaging server&gt;
 qpid_port=5671qpid_username=compute01
 
-qpid_password=password</screen>
+qpid_password=password</programlisting>
         <para>Optionally, if using SASL with Qpid specify the SASL mechanisms in use by adding:</para>
-        <screen>
+        <programlisting language="ini">qpid_sasl_mechanisms=&lt;space separated list of SASL mechanisms to use for auth&gt;</programlisting>
-qpid_sasl_mechanisms=&lt;space separated list of SASL mechanisms to use for auth&gt;</screen>
       </section>
     </section>
     <section xml:id="ch038_transport-security-idp68512">

doc/security-guide/ch042_database-overview.xml

@@ -56,14 +56,12 @@
       <title>Require User Accounts to Require SSL Transport</title>
       <section xml:id="ch042_database-overview-idp88784">
         <title>Configuration Example #1: (MySQL)</title>
-        <screen>
+        <programlisting>GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SSL;</programlisting>
-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>
+        <programlisting>hostssl dbname compute01 hostname md5</programlisting>
-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>
       </section>
@@ -73,24 +71,21 @@ hostssl dbname compute01 hostname md5</screen>
       <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>
+        <programlisting>GRANT ALL on dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SUBJECT
-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>
+'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=cloud-ca';</programlisting>
       </section>
       <section xml:id="ch042_database-overview-idp96192">
         <title>Configuration Example #2: (PostgreSQL)</title>
-        <screen>
+        <programlisting>hostssl dbname compute01 hostname cert</programlisting>
-hostssl dbname compute01 hostname cert</screen>
       </section>
     </section>
     <section xml:id="ch042_database-overview-idp97536">
       <title>OpenStack Service Database Configuration</title>
       <para>If your database server is configured to require X.509 certificates for authentication you will need to specify the appropriate SQLAlchemy query parameters for the database backend. These parameters specify the certificate, private key, and certificate authority information for use with the initial connection string.</para>
       <para>Example of an <literal>:sql_connection</literal> string for X.509 certificate authentication to MySQL:</para>
-      <screen>
+      <programlisting language="ini">sql_connection = mysql://compute01:password@localhost/nova?
-sql_connection = mysql://compute01:password@localhost/nova?
+charset=utf8&amp;ssl_ca=/etc/mysql/cacert.pem&amp;ssl_cert=/etc/mysql/server-cert.pem&amp;ssl_key=/etc/mysql/server-key.pem</programlisting>
-charset=utf8&amp;ssl_ca=/etc/mysql/cacert.pem&amp;ssl_cert=/etc/mysql/server-cert.pem&amp;ssl_key=/etc/mysql/server-key.pem</screen>
     </section>
     <section xml:id="ch042_database-overview-idp100688">
       <title>Nova Conductor</title>
@@ -109,8 +104,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>
+      <programlisting language="ini">[conductor]
-[conductor]
+use_local = true</programlisting>
-use_local = true</screen>
     </section>
   </chapter>

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

@@ -8,16 +8,14 @@
       <section xml:id="ch043_database-transport-security-idp39696">
         <title>Restricting Bind Address for MySQL</title>
         <para>In my.cnf:</para>
-        <screen>
+        <programlisting>[mysqld]
-[mysqld]
 ...
-bind-address &lt;ip address or hostname of management network interface&gt;</screen>
+bind-address &lt;ip address or hostname of management network interface&gt;</programlisting>
       </section>
       <section xml:id="ch043_database-transport-security-idp41568">
         <title>Restricting Listen Address for PostgreSQL</title>
         <para>In postgresql.conf:</para>
-        <screen>
+        <programlisting>listen_addresses = &lt;ip address or hostname of management network interface&gt;</programlisting>
-listen_addresses = &lt;ip address or hostname of management network interface&gt;</screen>
       </section>
     </section>
     <section xml:id="ch043_database-transport-security-idp43520">
@@ -31,25 +29,21 @@ listen_addresses = &lt;ip address or hostname of management network interface&gt
       <title>MySQL SSL Configuration</title>
       <para>The following lines should be added in the system-wide MySQL configuration file:</para>
       <para>In my.cnf:</para>
-      <screen>
+      <programlisting>[[mysqld]]
-[[mysqld]]
 ...
 ssl-ca=/path/to/ssl/cacert.pem
 ssl-cert=/path/to/ssl/server-cert.pem
-ssl-key=/path/to/ssl/server-key.pem</screen>
+ssl-key=/path/to/ssl/server-key.pem</programlisting>
       <para>Optionally, if you wish to restrict the set of SSL ciphers
       used for the encrypted connection. See <link xlink:href="http://www.openssl.org/docs/apps/ciphers.html">http://www.openssl.org/docs/apps/ciphers.html</link> for a list of ciphers and the syntax for specifying the cipher string:</para>
-      <screen>
+      <programlisting>ssl-cipher='cipher:list'</programlisting>
-ssl-cipher='cipher:list'</screen>
     </section>
     <section xml:id="ch043_database-transport-security-idp50288">
       <title>PostgreSQL SSL Configuration</title>
       <para>The following lines should be added in the system-wide PostgreSQL configuration file, <literal>postgresql.conf</literal>.</para>
-      <screen>
+      <programlisting>ssl = true</programlisting>
-ssl = true</screen>
       <para>Optionally, if you wish to restrict the set of SSL ciphers used for the encrypted connection. See <link xlink:href="http://www.openssl.org/docs/apps/ciphers.html">http://www.openssl.org/docs/apps/ciphers.html</link> for a list of ciphers and the syntax for specifying the cipher string:</para>
-      <screen>
+      <programlisting>ssl-ciphers = 'cipher:list'</programlisting>
-ssl-ciphers = 'cipher:list'</screen>
       <para>The server certificate, key, and certificate authority (CA) files should be placed in the $PGDATA directory in the following files:</para>
       <itemizedlist><listitem>
           <para>$PGDATA/server.crt - Server certificate</para>

doc/security-guide/ch052_devices.xml

@@ -46,11 +46,11 @@
       <section xml:id="ch052_devices-idp490976">
         <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 \
+        <screen><prompt>$</prompt> <userinput>glance image-update \
     --property hw_disk_bus=ide \
     --property hw_cdrom_bus=ide \
     --property hw_vif_model=e1000 \
-    f16-x86_64-openstack-sda</screen>
+    f16-x86_64-openstack-sda</userinput></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">
@@ -74,8 +74,7 @@
           </listitem>
 </itemizedlist>
         <para>Putting this all together, and adding in some additional useful protections, we recommend the following compiler options for gcc when compiling QEMU:</para>
-        <screen>
+        <programlisting>CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 -pie -fPIE -ftrapv -D_FORTIFY_SOURCE=2 -O2 -Wl,-z,relro,-z,now"</programlisting>
-CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 -pie -fPIE -ftrapv -D_FORTIFY_SOURCE=2 -O2 -Wl,-z,relro,-z,now"</screen>
         <para>We recommend testing your QEMU executable file after it is compiled to ensure that the compiler hardening worked properly.</para>
         <para>Most cloud deployments will not want to build software such as QEMU by hand. It is better to use packaging to ensure that the process is repeatable and to ensure that the end result can be easily deployed throughout the cloud. The references below provide some additional details on applying compiler hardening options to existing packages.</para>
         <itemizedlist><listitem>
@@ -138,15 +137,14 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-
       <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>
-        <screen>
+        <programlisting>system_u:object_r:svirt_image_t:SystemLow image1
-system_u:object_r:svirt_image_t:SystemLow image1
 system_u:object_r:svirt_image_t:SystemLow image2
 system_u:object_r:svirt_image_t:SystemLow image3
-system_u:object_r:svirt_image_t:SystemLow image4</screen>
+system_u:object_r:svirt_image_t:SystemLow image4</programlisting>
         <para>The svirt_image_t label uniquely identifies image files on disk, allowing for the SELinux policy to restrict access. When a KVM-based Compute image is powered on, sVirt appends a random numerical identifier to the image. sVirt is technically capable of assigning numerical identifiers to 524,288 virtual machines per hypervisor node, however OpenStack deployments are highly unlikely to encounter this limitation.</para>
         <para>This example shows the sVirt category identifier:</para>
-        <screen>system_u:object_r:svirt_image_t:s0:c87,c520 image1
+        <programlisting>system_u:object_r:svirt_image_t:s0:c87,c520 image1
-system_u:object_r:svirt_image_t:s0:419,c172 image2</screen>
+system_u:object_r:svirt_image_t:s0:419,c172 image2</programlisting>
       </section>
       <section xml:id="ch052_devices-idp527632">
         <title>Booleans</title>

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

@@ -88,20 +88,16 @@
         <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><prompt>$</prompt> <userinput>mkdir -p /tmp/download_directorycd /tmp/download_directory</userinput>
-mkdir -p /tmp/download_directorycd /tmp/download_directory
+<prompt>$</prompt> <userinput>wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso</userinput>
-
+<prompt>$</prompt> <userinput>wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS</userinput>
-wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso
+<prompt>$</prompt> <userinput>wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg</userinput>
-wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS
+<prompt>$</prompt> <userinput>gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451</userinput>
-wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg
+<prompt>$</prompt> <userinput>gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2&gt;&amp;1 | grep OK</userinput></screen>
-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>
-        <screen>
+        <programlisting>&lt;template&gt;
-&lt;template&gt;
 &lt;name&gt;centos64&lt;/name&gt;
 &lt;os&gt;
   &lt;name&gt;RHEL-6&lt;/name&gt;
@@ -135,7 +131,7 @@ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2&gt;&amp;1 | grep
   service autofs stop
   &lt;/command&gt;
 &lt;/commands&gt;
-&lt;/template&gt;</screen>
+&lt;/template&gt;</programlisting>
         <para>Note, it is the recommendation of this guide to shy away from the manual image building process as it is complex and prone to error. Further, using an automated system like Oz or disk-image-builder for image building, or a configuration management utility like Chef or Puppet for post boot image hardening gives you the ability to produce a consistent image as well as track compliance of your base image to its respective hardening guidelines over time.</para>
         <para>If subscribing to a public cloud service, you should check with the cloud provider for an outline of the process used to produce their default images. If the provider allows you to upload your own images, you will want to ensure that you are able to verify that your image was not modified before you spin it up. To do this, refer to the following section on Image Provenance.</para>
       </section>
@@ -198,9 +194,8 @@ 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>
+          <programlisting>"compute_extension:admin_actions:migrate": "!",
-"compute_extension:admin_actions:migrate": "!",
+"compute_extension:admin_actions:migrateLive": "!",</programlisting>
-"compute_extension:admin_actions:migrateLive": "!",</screen>
         </section>
         <section xml:id="ch055_security-services-for-instances-idp189488">
           <title>Migration Network</title>