[PATCH 2/8] out unicode, out!!! somebody needs to use a real text editor or stop copying/pasting * fancy characters are nice, but are causing trouble for some transforms

Jeffrey Blank blank at eclipse.ncsc.mil
Tue Oct 9 15:09:31 UTC 2012


Signed-off-by: Jeffrey Blank <blank at eclipse.ncsc.mil>
---
 RHEL6/input/services/avahi.xml                    |    2 +-
 RHEL6/input/services/dhcp.xml                     |    8 ++--
 RHEL6/input/services/dns.xml                      |    6 +-
 RHEL6/input/services/ftp.xml                      |    8 ++-
 RHEL6/input/services/http.xml                     |    6 +-
 RHEL6/input/services/ldap.xml                     |   20 +++++-----
 RHEL6/input/services/mail.xml                     |   14 +++---
 RHEL6/input/services/nfs.xml                      |    4 +-
 RHEL6/input/services/snmp.xml                     |    2 +-
 RHEL6/input/services/ssh.xml                      |    4 +-
 RHEL6/input/system/accounts/pam.xml               |    2 +-
 RHEL6/input/system/accounts/physical.xml          |    2 +-
 RHEL6/input/system/auditing.xml                   |    8 ++--
 RHEL6/input/system/network/iptables.xml           |    8 ++--
 RHEL6/input/system/network/network.xml            |    2 +-
 RHEL6/input/system/network/ssl.xml                |   12 +++---
 RHEL6/input/system/network/uncommon.xml           |    2 +-
 RHEL6/input/system/permissions/mounting.xml       |   42 +++++++++++++++------
 RHEL6/input/system/permissions/permissions.xml    |    2 +-
 RHEL6/input/system/selinux.xml                    |    4 +-
 RHEL6/input/system/software/disk_partitioning.xml |    2 +-
 RHEL6/input/system/software/integrity.xml         |    2 +-
 RHEL6/input/system/software/updating.xml          |    2 +-
 23 files changed, 92 insertions(+), 72 deletions(-)

diff --git a/RHEL6/input/services/avahi.xml b/RHEL6/input/services/avahi.xml
index 1733519..c4112b7 100644
--- a/RHEL6/input/services/avahi.xml
+++ b/RHEL6/input/services/avahi.xml
@@ -12,7 +12,7 @@ of Zeroconf networking. </description>
 <title>Disable Avahi Server if Possible</title>
 <description>Because the Avahi daemon service keeps an open network
 port, it is subject to network attacks.
-Disabling it can reduce the system’s vulnerability to such attacks.
+Disabling it can reduce the system's vulnerability to such attacks.
 </description>
 
 <Rule id="disable_avahi">
diff --git a/RHEL6/input/services/dhcp.xml b/RHEL6/input/services/dhcp.xml
index 0013786..f432092 100644
--- a/RHEL6/input/services/dhcp.xml
+++ b/RHEL6/input/services/dhcp.xml
@@ -20,8 +20,8 @@ recommends configuring networking on clients by manually editing
 the appropriate files under <tt>/etc/sysconfig</tt>. It is also possible to
 use the graphical front-end programs system-config-network and
 system-config-network-tui, but these programs rewrite configuration
-files from scratch based on their defaults – destroying any manual
-changes – and should therefore be used with caution.</description>
+files from scratch based on their defaults - destroying any manual
+changes - and should therefore be used with caution.</description>
 
 
 <Group id="disabling_dhcp_server">
@@ -111,7 +111,7 @@ messages, if possible: <pre>deny declines;</pre> </description>
 <rationale>The DHCPDECLINE message can be sent by a DHCP client to indicate
 that it does not consider the lease offered by the server to be valid. By
 issuing many DHCPDECLINE messages, a malicious client can exhaust the DHCP
-server’s pool of IP addresses, causing the DHCP server to forget old address
+server's pool of IP addresses, causing the DHCP server to forget old address
 allocations.</rationale>
 <ident cce="4403-2" />
 <!--<oval id="dhcp_server_deny_decline" /> -->
@@ -205,7 +205,7 @@ following changes:
 <pre>BOOTPROTO=static</pre>
 </li>
 <li> Add or correct the following lines, substituting the appropriate
-values based on your site’s addressing scheme:
+values based on your site's addressing scheme:
 <pre>NETMASK=255.255.255.0
 IPADDR=192.168.1.2
 GATEWAY=192.168.1.1</pre>
diff --git a/RHEL6/input/services/dns.xml b/RHEL6/input/services/dns.xml
index a467115..6f3e28c 100644
--- a/RHEL6/input/services/dns.xml
+++ b/RHEL6/input/services/dns.xml
@@ -87,7 +87,7 @@ Edit the file <tt>/etc/sysconfig/named</tt>. Add or correct the line:
 </description>
 <rationale>Chroot jails are not foolproof. However, they serve to make it more
 difficult for a compromised program to be used to attack the entire host. They
-do this by restricting a program’s ability to traverse the directory upward, so
+do this by restricting a program's ability to traverse the directory upward, so
 that files outside the jail are not visible to the chrooted process. Since RHEL
 supports a standard mechanism for placing BIND in a chroot jail, you should
 take advantage of this feature.</rationale>
@@ -161,7 +161,7 @@ zone "internal.example.com " IN {
 <rationale>Enterprise nameservers generally serve two functions. One is to
 provide public information about the machines in a domain for the benefit of
 outside users who wish to contact those machines, for instance in order to send
-mail to users in the enterprise, or to visit the enterprise’s external web
+mail to users in the enterprise, or to visit the enterprise's external web
 page. The other is to provide nameservice to client machines within the
 enterprise. Client machines require both private information about enterprise
 machines (which may be different from the public information served to the rest
@@ -169,7 +169,7 @@ of the world) and public information about machines outside the enterprise,
 which is used to send mail or visit websites outside of the organization.
 <br />
 In order to provide the public nameservice function, it is necessary to share
-data with untrusted machines which request it — otherwise, the enterprise
+data with untrusted machines which request it - otherwise, the enterprise
 cannot be conveniently contacted by outside users. However, internal data
 should be protected from disclosure, and serving irrelevant public name queries
 for outside domains leaves the DNS server open to cache poisoning and other
diff --git a/RHEL6/input/services/ftp.xml b/RHEL6/input/services/ftp.xml
index ade5c18..92bd0fe 100644
--- a/RHEL6/input/services/ftp.xml
+++ b/RHEL6/input/services/ftp.xml
@@ -71,8 +71,10 @@ and for consistency with future Red Hat releases, the use of vsftpd is recommend
 
 <Group id="ftp_configure_vsftpd">
 <title>Use vsftpd to Provide FTP Service if Necessary</title>
-<description>The primary vsftpd configuration file is <tt>/etc/vsftpd.conf</tt>, if that file exists, or <tt>/etc/vsftpd/vsftpd.conf</tt> if it does not. For the remainder of this section, the phrase “the configuration file” will refer to whichever of those files is appropriate for your environment.</description>
-
+<description>The primary vsftpd configuration file is
+<tt>/etc/vsftpd.conf</tt>, if that file exists, or
+<tt>/etc/vsftpd/vsftpd.conf</tt> if it does not. 
+</description>
 <Rule id="ftp_log_transactions">
 <title>Enable Logging of All FTP Transactions</title>
 <description>Edit the vsftpd configuration file. Add or correct the following configuration options:
@@ -134,7 +136,7 @@ these logins as much as possible.</description>
 <pre>userlist_enable=YES
 userlist_file=/etc/vsftp.ftpusers
 userlist_deny=NO</pre>
-Edit the file <tt>/etc/vsftp.ftpusers</tt>. For each user USERNAME who should be allowed to access the system via ftp, add a line containing that user’s name.
+Edit the file <tt>/etc/vsftp.ftpusers</tt>. For each user USERNAME who should be allowed to access the system via ftp, add a line containing that user's name.
 <pre>USERNAME</pre>
 If anonymous access is also required, add the anonymous usernames to <tt>/etc/vsftp.ftpusers</tt> as well:
 <pre>anonymous
diff --git a/RHEL6/input/services/http.xml b/RHEL6/input/services/http.xml
index 2e29a70..51bae93 100644
--- a/RHEL6/input/services/http.xml
+++ b/RHEL6/input/services/http.xml
@@ -161,7 +161,7 @@ Following each DSO removal, the configuration can be tested with the following c
 to check if everything still works:
 <pre># service httpd configtest</pre>
 The purpose of each of the modules loaded by default will now be addressed one at a time.
-If none of a module’s directives are being used, remove it.
+If none of a module's directives are being used, remove it.
 </description>
 
 <Group id="httpd_core_modules">
@@ -195,7 +195,7 @@ be restricted by a password.
 <br /><br />
 Authentication can be performed using local plain text password files (<tt>authn_file</tt>),
 local DBM password files (<tt>authn_dbm</tt>) or an LDAP directory. The only module required by
-the web server depends on your choice of authentication. Comment out the modules you don’t
+the web server depends on your choice of authentication. Comment out the modules you don't
 need from the following:
 <pre>LoadModule authn_file_module modules/mod_authn_file.so
 LoadModule authn_dbm_module modules/mod_authn_dbm.so</pre>
@@ -446,7 +446,7 @@ If the web server requires the use of CGI, enable <tt>mod_cgi</tt>.
 CGI functionality is required, include the appropriate modules. <tt>env</tt> allows for
 control of the environment passed to CGI scripts. <tt>actions</tt> allows CGI events
 to be triggered when files of a certain type are requested. <tt>su exec</tt> allows
-CGI scripts to run as a specified user/group instead of as the server’s user/group. -->
+CGI scripts to run as a specified user/group instead of as the server's user/group. -->
 </description>
 <rationale>
 Minimizing the number of loadable modules available to the web server reduces risk
diff --git a/RHEL6/input/services/ldap.xml b/RHEL6/input/services/ldap.xml
index 575190b..e292b24 100644
--- a/RHEL6/input/services/ldap.xml
+++ b/RHEL6/input/services/ldap.xml
@@ -112,7 +112,7 @@ to include suffix information relevant to your domain.
 olcRootDN: "cn=Manager,dc=example,dc=com "</pre>
 where dc=example,dc=com is the same root you will use on the LDAP clients.
 <br />
-These are basic LDAP configuration directives. The suffix parameter gives the root name of all information served by this LDAP server, and should be some name related to your domain. The rootdn parameter names LDAP’s privileged user, who is allowed to read or write all data managed by this LDAP server.
+These are basic LDAP configuration directives. The suffix parameter gives the root name of all information served by this LDAP server, and should be some name related to your domain. The rootdn parameter names LDAP's privileged user, who is allowed to read or write all data managed by this LDAP server.
 </description>
 <ident cce="3501-4" />
 <oval id="ldap_server_config_olcsuffix" />
@@ -177,7 +177,7 @@ Verify the ownership and permissions of these files:
 # chown root:ldap /etc/pki/tls/ldap/servercert.pem
 # chmod 640 /etc/pki/tls/ldap/serverkey.pem
 # chmod 640 /etc/pki/tls/ldap/servercert.pem</pre>
-Verify that the CA’s public certificate file has been installed as <tt>/etc/pki/tls/CA/cacert.pem</tt>, and has the
+Verify that the CA's public certificate file has been installed as <tt>/etc/pki/tls/CA/cacert.pem</tt>, and has the
 correct permissions:
 <pre># mkdir /etc/pki/tls/CA
 # chown root:root /etc/pki/tls/CA/cacert.pem
@@ -211,7 +211,7 @@ objectClass: dcObject
 objectClass: organization
 dc: example
 o: Organization Description</pre>
-This is a placeholder for the root of the domain’s LDAP tree. Without this entry, LDAP will not be able to find
+This is a placeholder for the root of the domain's LDAP tree. Without this entry, LDAP will not be able to find
 any other entries for the domain.
 </description>
 <!--<ident cce="TODO:CCE" />-->
@@ -280,7 +280,7 @@ memberUid: username1
 memberUid: username2
 ...
 memberUid: usernameN</pre>
-Note that each user has a primary group, identified by the gidNumber field in the user’s account entry. That
+Note that each user has a primary group, identified by the gidNumber field in the user's account entry. That
 group must be created, but it is not necessary to list the user as a memberUid of the group. This behavior should
 be familiar to administrators, since it is identical to the handling of the /etc/passwd and /etc/group files.
 Do not create entries for the root group or for system groups, but only for groups which contain human users
@@ -304,8 +304,8 @@ uniqueMember: uid=admin1-username ,ou=people,dc=example,dc=com
 uniqueMember: uid=admin2-username ,ou=people,dc=example,dc=com
 ...
 uniqueMember: uid=adminN-username ,ou=people,dc=example,dc=com</pre>
-LDAP cannot use Posix groups for its own internal authentication — it needs to compare the username specified
-in an authenticated bind to some internal groupOfUniqueNames. If you do not specify an LDAP administrators’
+LDAP cannot use Posix groups for its own internal authentication - it needs to compare the username specified
+in an authenticated bind to some internal groupOfUniqueNames. If you do not specify an LDAP administrators'
 group, then all LDAP management will need to be done using the LDAP root user (Manager). For reasons of
 auditing and error detection, it is recommended that LDAP administrators have unique identities.
 </description>
@@ -317,7 +317,7 @@ auditing and error detection, it is recommended that LDAP administrators have un
 <Rule id="ldap_server_config_olcaccess">
 <title>Configure slapd to Protect Authentication Information</title>
 <description>Use ldapmodify to add these entries to the database. Add or correct the following access specifications:
-1. Protect the user’s password by allowing the user himself or the LDAP administrators to change it,
+1. Protect the user's password by allowing the user himself or the LDAP administrators to change it,
 allowing the anonymous user to authenticate against it, and allowing no other access:
 <pre>olcAccess: to attrs=userPassword
     by self write
@@ -345,7 +345,7 @@ be able to change data without an explicit access statement.
 
 <Rule id="ldap_server_config_directory_file_security">
 <title>Correct Permissions on LDAP Server Files</title>
-<description>Correct the permissions on the ldap server’s files:
+<description>Correct the permissions on the ldap server's files:
 <pre># chown ldap:root /var/lib/ldap/*</pre>
 Some manual methods of inserting information into the LDAP database may leave these files with incorrect
 permissions. This will prevent slapd from starting correctly.
@@ -400,9 +400,9 @@ parameters, such as:
 OpenLDAP sends its log data to the syslog facility local4 at priority debug. By default, RHEL5 does not store
 this facility at all. The syslog configuration suggested here will store any output logged by slapd in the file
 <tt>/var/log/ldap.log</tt>, and will include that file in the standard log rotation for syslog files.
-By default, LDAP’s logging is quite verbose. The loglevel parameter is a space-separated list of items to be
+By default, LDAP's logging is quite verbose. The loglevel parameter is a space-separated list of items to be
 logged. Specifying <tt>stats2</tt> will reduce the log output somewhat, but this level will still produce some logging
-every time an LDAP query is made. (This may be appropriate, depending on your site’s auditing requirements.)
+every time an LDAP query is made. (This may be appropriate, depending on your site's auditing requirements.)
 In order to capture only <tt>slapd</tt> startup messages, specify <tt>loglevel none</tt>.
 See <tt>slapd.conf(5)</tt> for detailed information about the loglevel parameter.
 </description>
diff --git a/RHEL6/input/services/mail.xml b/RHEL6/input/services/mail.xml
index 2e68796..8e98851 100644
--- a/RHEL6/input/services/mail.xml
+++ b/RHEL6/input/services/mail.xml
@@ -170,7 +170,7 @@ Change into the CA certificate directory:
 Generate a key pair for the mail server:
 <pre># openssl genrsa -out mailserverkey.pem 2048</pre>
 Next, generate a certificate signing request (CSR) for the CA to sign, making sure to supply your mail
-server’s fully qualified domain name as the Common Name:
+server's fully qualified domain name as the Common Name:
 <pre># openssl req -new -key mailserverkey.pem -out mailserver.csr</pre>
 Next, the mail server CSR must be signed to create the mail server certificate. You can either send the CSR
 to an established CA or sign it with your CA.
@@ -203,7 +203,7 @@ Verify the ownership and permissions of these files:
 # chown root:root /etc/pki/tls/mail/servercert.pem
 # chmod 600 /etc/pki/tls/mail/serverkey.pem
 # chmod 644 /etc/pki/tls/mail/servercert.pem</pre>
-Verify that the CA’s public certificate file has been installed as <tt>/etc/pki/tls/CA/cacert.pem</tt>, and has the
+Verify that the CA's public certificate file has been installed as <tt>/etc/pki/tls/CA/cacert.pem</tt>, and has the
 correct permissions:
 <pre># chown root:root /etc/pki/tls/CA/cacert.pem
 # chmod 644 /etc/pki/tls/CA/cacert.pem</pre>
@@ -272,7 +272,7 @@ supported.
 
 <Group id="postfix_server_mail_relay">
 <title>Control Mail Relaying</title>
-<description>Postfix’s mail relay controls are implemented with the help of the smtpd recipient restrictions option, which
+<description>Postfix's mail relay controls are implemented with the help of the smtpd recipient restrictions option, which
 controls the restrictions placed on the SMTP dialogue once the sender and recipient envelope addresses are known.
 The guidance in the following sections should be applied to all machines. If there are machines which
 must be allowed to relay mail, but which cannot be trusted to relay unconditionally, configure SMTP AUTH
@@ -294,7 +294,7 @@ or IP address which is trusted to relay by setting the mynetworks variable direc
 </ul>
 </description>
 <rationale>The <tt>mynetworks</tt> variable must contain only the set of machines for which this MTA should unconditionally
-relay mail. This is a trust relationship — if spammers gain access to these machines, your site will effectively
+relay mail. This is a trust relationship - if spammers gain access to these machines, your site will effectively
 become an open relay. It is recommended that only machines which are managed by you or by another trusted
 organization be placed in mynetworks, and users of all other machines be required to use SMTP AUTH to send
 mail.
@@ -328,7 +328,7 @@ this order, and should usually follow one another immediately unless SMTP AUTH i
 <Rule id="postfix_server_mail_relay_smtp_auth_for_untrusted_networks">
 <title>Require SMTP AUTH Before Relaying from Untrusted Clients</title>
 <description>SMTP authentication allows remote clients to relay mail safely by requiring them to authenticate before submit-
-ting mail. Postfix’s SMTP AUTH uses an authentication library called SASL, which is not part of Postfix itself.
+ting mail. Postfix's SMTP AUTH uses an authentication library called SASL, which is not part of Postfix itself.
 This section describes how to configure authentication using the Cyrus-SASL implementation. See below for a
 discussion of other options.
 <br /><br />
@@ -347,11 +347,11 @@ mechanism for SASL to use:
 <service-enable-macro service="saslauthd" />
 </description>
 <rationale>Postfix can use either the Cyrus library or Dovecot as a source for SASL authentication. If this host is running
-Dovecot for some other reason, it is recommended that Dovecot’s SASL support be used instead of running the
+Dovecot for some other reason, it is recommended that Dovecot's SASL support be used instead of running the
 Cyrus code as well. See http://www.postfix.org/SASL_README.html for instructions on implementing that
 configuration, which is not described in this guide.
 <br /><br />
-In Postfix’s configuration, the directive <tt>smtpd_sasl_auth_enable</tt> tells <tt>smtpd</tt> to allow the use of the SMTP AUTH
+In Postfix's configuration, the directive <tt>smtpd_sasl_auth_enable</tt> tells <tt>smtpd</tt> to allow the use of the SMTP AUTH
 command during the SMTP dialogue, and to support that command by getting authentication information from
 SASL. The <tt>smtpd_recipient_restrictions</tt> directive is changed so that, if the client is not connecting from a
 trusted address, it is allowed to attempt authentication (<tt>permit_sasl_authenticated</tt>) in order to relay mail.
diff --git a/RHEL6/input/services/nfs.xml b/RHEL6/input/services/nfs.xml
index 2675fa2..592e80f 100644
--- a/RHEL6/input/services/nfs.xml
+++ b/RHEL6/input/services/nfs.xml
@@ -277,7 +277,7 @@ should be installed to their default location on the local filesystem.</rational
 
 <Group id="configure_exports_restrictively">
 <title>Configure the Exports File Restrictively</title>
-<description>Linux’s NFS implementation uses the file <tt>/etc/exports</tt> to control what filesystems
+<description>Linux's NFS implementation uses the file <tt>/etc/exports</tt> to control what filesystems
 and directories may be accessed via NFS. (See the <tt>exports(5)</tt> manpage for more information about the
 format of this file.)
 <br /><br />
@@ -350,7 +350,7 @@ access could be used to compromise the system.</rationale>
 
 <Rule id="restrict_nfs_clients_to_privileged_ports">
 <title>Restrict NFS Clients to Privileged Ports</title>
-<description>By default, Linux’s NFS implementation requires that all client requests be made
+<description>By default, Linux's NFS implementation requires that all client requests be made
 from ports less than 1024. If your organization has control over machines connected to its
 network, and if NFS requests are prohibited at the border firewall, this offers some protection
 against malicious requests from unprivileged users. Therefore, the default should not be changed.
diff --git a/RHEL6/input/services/snmp.xml b/RHEL6/input/services/snmp.xml
index e224054..c63993f 100644
--- a/RHEL6/input/services/snmp.xml
+++ b/RHEL6/input/services/snmp.xml
@@ -64,7 +64,7 @@ addresses both in the configuration files and in the system firewall rules</li>
 <li>ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management
 stations</li>
 <li>ensure that permissions on the <tt>snmpd.conf</tt> configuration file (by default, in <tt>/etc/snmp</tt>) are 640 or more restrictive</li>
-<li>ensure that any MIB files’ permissions are also 640 or more restrictive</li></ul>
+<li>ensure that any MIB files' permissions are also 640 or more restrictive</li></ul>
 </description>
 <!--<ident cce="14081-4" /> -->
 <!--<oval id="snmp_configure_server" /> -->
diff --git a/RHEL6/input/services/ssh.xml b/RHEL6/input/services/ssh.xml
index f77effe..5d57317 100644
--- a/RHEL6/input/services/ssh.xml
+++ b/RHEL6/input/services/ssh.xml
@@ -33,7 +33,7 @@ remote access.
 
 <Rule id="ssh_server_iptables_exception">
 <title>Remove SSH Server <tt>iptables</tt> Firewall exception (Unusual)</title>
-<description>By default, inbound connections to SSH’s port are allowed. If 
+<description>By default, inbound connections to SSH's port are allowed. If 
 the SSH server is not being used, this exception should be removed from the
 firewall configuration.
 <br /><br />
@@ -257,7 +257,7 @@ To disable root login via SSH, add or correct the following line:
 <rationale>
 Permitting direct root login reduces auditable information about who ran
 privileged commands on the system
-and also allows direct attack attempts on root’s password.
+and also allows direct attack attempts on root's password.
 </rationale>
 <ident cce="4387-7" />
 <oval id="sshd_permitrootlogin_no" />
diff --git a/RHEL6/input/system/accounts/pam.xml b/RHEL6/input/system/accounts/pam.xml
index 737fc4d..8b6d7e0 100644
--- a/RHEL6/input/system/accounts/pam.xml
+++ b/RHEL6/input/system/accounts/pam.xml
@@ -86,7 +86,7 @@ character, locate the following line in <tt>/etc/pam.d/system-auth</tt>:
 and then alter it to read:
 <pre>password required pam_cracklib.so try_first_pass retry=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0</pre>
 The arguments can be modified to ensure compliance with
-your organization’s security policy. Discussion of each parameter follows.
+your organization's security policy. Discussion of each parameter follows.
 </description>
 <warning category="general">Note that the password quality
 requirements are not enforced for the root account for some
diff --git a/RHEL6/input/system/accounts/physical.xml b/RHEL6/input/system/accounts/physical.xml
index b418393..0868d30 100644
--- a/RHEL6/input/system/accounts/physical.xml
+++ b/RHEL6/input/system/accounts/physical.xml
@@ -12,7 +12,7 @@ console.</description>
 <description>During the boot process, the boot loader is
 responsible for starting the execution of the kernel and passing
 options to it. The boot loader allows for the selection of
-different kernels – possibly on different partitions or media.
+different kernels - possibly on different partitions or media.
 The default RHEL boot loader for x86 systems is called GRUB.
 Options it can pass to the kernel include <i>single-user mode</i>, which
 provides root access without any authentication, and the ability to
diff --git a/RHEL6/input/system/auditing.xml b/RHEL6/input/system/auditing.xml
index 163624d..8adcc8c 100644
--- a/RHEL6/input/system/auditing.xml
+++ b/RHEL6/input/system/auditing.xml
@@ -109,7 +109,7 @@ Inspect the kernel boot arguments (which follow the word <tt>kernel</tt>) in
 <tt>/etc/grub.conf</tt> to ensure that they include <tt>audit=1</tt>.
 </ocil>
 <rationale>
-Each process on the system carries an "auditable" flag which
+Each process on the system carries an "auditable" flag which
 indicates whether its activities can be audited. Although <tt>auditd</tt>
 takes care of enabling this for all processes which launch after it
 does, adding the kernel argument ensures that it is set for every
@@ -415,7 +415,7 @@ administrators of the system, who can take appropriate action.</rationale>
 <description>The <tt>auditd</tt> program can perform comprehensive
 monitoring of system activity. This section describes recommended
 configuration settings for comprehensive auditing, but a full
-description of the auditing system’s capabilities is beyond the
+description of the auditing system's capabilities is beyond the
 scope of this guide. The mailing list <i>linux-audit at redhat.com</i> exists
 to facilitate community discussion of the auditing system.
 <br /><br />
@@ -426,7 +426,7 @@ The audit subsystem supports extensive collection of events, including:
 on entry or exit.</li>
 <li>Filtering by PID, UID, call success, system call argument (with
 some limitations), etc.</li>
-<li>Monitoring of specific files for modifications to the file’s
+<li>Monitoring of specific files for modifications to the file's
 contents or metadata.</li>
 </ul>
 <br />
@@ -439,7 +439,7 @@ in the related man pages for more details.
 <br /><br />
 If copying any example audit rulesets from <tt>/usr/share/doc/audit-VERSION</tt>,
 be sure to comment out the
-lines containing <tt>arch=</tt> which are not appropriate for your system’s
+lines containing <tt>arch=</tt> which are not appropriate for your system's
 architecture. Then review and understand the following rules,
 ensuring rules are activated as needed for the appropriate
 architecture.
diff --git a/RHEL6/input/system/network/iptables.xml b/RHEL6/input/system/network/iptables.xml
index 0f2aa45..45fd6de 100644
--- a/RHEL6/input/system/network/iptables.xml
+++ b/RHEL6/input/system/network/iptables.xml
@@ -103,7 +103,7 @@ scripts that activate the firewall rules expect them to be defined
 in the configuration files iptables and ip6tables in the directory
 <tt>/etc/sysconfig</tt>. Many of the lines in these files are similar
 to the command line arguments that would be provided to the programs
-<tt>/sbin/iptables</tt> or <tt>/sbin/ip6tables</tt> – but some are quite
+<tt>/sbin/iptables</tt> or <tt>/sbin/ip6tables</tt> - but some are quite
 different.
 <br /><br />
 The following recommendations describe how to strengthen the
@@ -183,9 +183,9 @@ To allow the system to respond to pings, also insert the following line:
 <pre>-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT</pre>
 Ping responses can also be limited to certain networks or hosts by using the -s option in the previous rule.
 Because IPv6 depends so heavily on ICMPv6, it is preferable to deny the ICMPv6 packets you know you
-don’t need (e.g. ping requests) in <tt>/etc/sysconfig/ip6tables</tt>, while letting everything else through:
+don't need (e.g. ping requests) in <tt>/etc/sysconfig/ip6tables</tt>, while letting everything else through:
 <pre>-A RH-Firewall-1-INPUT -p icmpv6 --icmpv6-type echo-request -j DROP</pre>
-If you are going to statically configure the machine’s address, it should ignore Router Advertisements which
+If you are going to statically configure the machine's address, it should ignore Router Advertisements which
 could add another IPv6 address to the interface or alter important network settings:
 <pre>-A RH-Firewall-1-INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP</pre>
 </description>
@@ -227,7 +227,7 @@ If you wish to block multicasts to all link-local nodes (e.g. if you are not usi
 do not plan to have any services that multicast to the entire local network), you can block the link-local
 all-nodes multicast address (before accepting incoming ICMPv6):
 <pre>-A INPUT -d FF02::1 -j LOG --log-prefix "Link-local All-Nodes Multicast: "</pre>
-However, if you’re going to allow IPv4 compatible IPv6 addresses (of the form ::0.0.0.0/96), you should
+However, if you're going to allow IPv4 compatible IPv6 addresses (of the form ::0.0.0.0/96), you should
 then consider logging the non-routable IPv4-compatible addresses:
 <pre>-A INPUT -s ::0.0.0.0/104 -j LOG --log-prefix "IP NON-ROUTABLE ADDR: "
 -A INPUT -s ::127.0.0.0/104 -j LOG --log-prefix "IP DROP LOOPBACK: "
diff --git a/RHEL6/input/system/network/network.xml b/RHEL6/input/system/network/network.xml
index a280b1b..dce16c1 100644
--- a/RHEL6/input/system/network/network.xml
+++ b/RHEL6/input/system/network/network.xml
@@ -43,7 +43,7 @@ subnet, add or correct the following line in <tt>/etc/sysconfig/network</tt>:
 <pre>NOZEROCONF=yes</pre>
 </description>
 <rationale>Zeroconf addresses are in the network 169.254.0.0. The networking
-scripts add entries to the system’s routing table for these addresses. Zeroconf
+scripts add entries to the system's routing table for these addresses. Zeroconf
 address assignment commonly occurs when the system is configured to use DHCP
 but fails to receive an address assignment from the DHCP server.
 </rationale>
diff --git a/RHEL6/input/system/network/ssl.xml b/RHEL6/input/system/network/ssl.xml
index cf8b9da..77f3ecb 100644
--- a/RHEL6/input/system/network/ssl.xml
+++ b/RHEL6/input/system/network/ssl.xml
@@ -19,12 +19,12 @@ public key. In SSL authentication, a server presents a client with its
 certificate as a means of demonstrating that it is who it claims it is.
 
 <br /><br />
-If everything goes correctly, the client can verify the server’s certificate by
+If everything goes correctly, the client can verify the server's certificate by
 determining that the signature inside the certificate could only have been
 generated by a third party whom the client trusts.  This third party is called
 a Certificate Authority (CA). Each client system should also have certificates
 from trusted CAs, and the client uses these CA certificates to verify the
-authenticity of the server’s certificate. After authenticating a server using
+authenticity of the server's certificate. After authenticating a server using
 its certificate and a CA certificate, SSL provides encryption by using the
 server certificate to securely negotiate a shared secret key.
 
@@ -45,7 +45,7 @@ process are:
 <ol>
 <li>Create a CA to sign certificates</li>
 <li>Create SSL certificates for servers using that CA</li>
-<li>Enable client support by distributing the CA’s certificate</li>
+<li>Enable client support by distributing the CA's certificate</li>
 </ol>
 </description>
 
@@ -89,7 +89,7 @@ certificate authority. These are:
 <li><tt>serial</tt>, which contains the current serial number for certificates signed by the CA</li>
 <li><tt>index.txt</tt>, which is a text database file that contains information about certificates signed</li>
 <li><tt>crl</tt>, which is a directory for holding revoked certificates</li>
-<li><tt>private</tt>, a directory which stores the CA’s private key</li>
+<li><tt>private</tt>, a directory which stores the CA's private key</li>
 </ul></li>
 <li>creates a public-private key pair for the CA in the file <tt>/etc/pki/CA/private/cakey.pem</tt>. The private key
 must be kept private in order to ensure the security of the certificates the CA will later sign.</li>
@@ -97,7 +97,7 @@ must be kept private in order to ensure the security of the certificates the CA
 certificate, which is then stored in <tt>/etc/pki/CA/cacert.pem</tt>.</li>
 </ul>
 When the CA later signs a server certificate using its private key, it means that it is vouching for the authenticity
-of that server. A client can then use the CA’s certificate (which contains its public key) to verify the authenticity
+of that server. A client can then use the CA's certificate (which contains its public key) to verify the authenticity
 of the server certificate.
 </description>
 <!--<ident cce="TODO" />-->
@@ -130,7 +130,7 @@ Instructions on how to generate and sign SSL certificates are provided for the f
 <Group id="network_ssl_enable_client_support">
 <title>Enable Client Support</title>
 <description>The system ships with certificates from well-known commercial CAs. If your server certificates were signed by one of these established CAs, then this step is not necessary since the clients should include the CA certificate already.
-If your servers use certificates signed by your own CA, some user applications will warn that the server’s certificate
+If your servers use certificates signed by your own CA, some user applications will warn that the server's certificate
 cannot be verified because the CA is not recognized. Other applications may simply fail to accept the certificate
 and refuse to operate, or continue operating without ever having properly verified the server certificate.
 To avoid this warning, and properly authenticate the servers, your CA certificate must be exported to every
diff --git a/RHEL6/input/system/network/uncommon.xml b/RHEL6/input/system/network/uncommon.xml
index bd6eeee..902ddce 100644
--- a/RHEL6/input/system/network/uncommon.xml
+++ b/RHEL6/input/system/network/uncommon.xml
@@ -4,7 +4,7 @@
 protocols which are not commonly used. Although security vul-
 nerabilities in kernel networking code are not frequently
 discovered, the consequences can be dramatic. Ensuring uncommon
-network protocols are disabled reduces the system’s risk to attacks
+network protocols are disabled reduces the system's risk to attacks
 targeted at its implementation of those protocols.</description>
 <warning>
 Although these protocols are not commonly used, avoid disruption
diff --git a/RHEL6/input/system/permissions/mounting.xml b/RHEL6/input/system/permissions/mounting.xml
index a46f735..f62cc70 100644
--- a/RHEL6/input/system/permissions/mounting.xml
+++ b/RHEL6/input/system/permissions/mounting.xml
@@ -21,10 +21,19 @@ solve the same problem with less risk.</description>
 
 <Rule id="console_device_restrict_access_desktop">
 <title>Restrict Console Device Access to Desktop Workstations</title>
-<description>If the display manager has been altered to allow remote users to log in and the host is configured to run at runlevel 5, change console as well as the xconsole directive in the <tt>/etc/security/console.perms</tt> to the following:
+<description>If the display manager has been altered to allow remote users to
+log in and the host is configured to run at runlevel 5, change console as well
+as the xconsole directive in the <tt>/etc/security/console.perms</tt> to the
+following:
 <pre>&lt;console&gt;=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0
 &lt;xconsole&gt;=:0\.[0-9] :0</pre></description>
-<rationale>When a user logs in, the module pam_console.so called via the command login, or by some of the graphics program of logging, such as gdm, kdm, ​​and xdm. If this user is the first to log into the physical console - called the console user - the user module assures the mastery of a wide variety of devices normally belong to root. Administrative privileges should be limited for non-root users. Review the man page for <tt>pam_console</tt> for more information</rationale>
+<rationale>When a user logs in, the module pam_console.so called via the
+command login, or by some of the graphics program of logging, such as gdm, kdm,
+and xdm. If this user is the first to log into the physical console
+- called the console user - the user module assures the mastery of a wide
+variety of devices normally belong to root. Administrative privileges should be
+limited for non-root users. Review the man page for <tt>pam_console</tt> for
+more information</rationale>
 <ident cce="3685-5" />
 <oval id="console_device_restrict_access_desktop" />
 <ref nist="AC-6, CM-6, CM-7" />
@@ -32,9 +41,18 @@ solve the same problem with less risk.</description>
 
 <Rule id="console_device_restrict_access_server">
 <title>Restrict Console Device Access to Servers</title>
-<description>If the display manager has been altered to allow remote users to log in and the host is configured to run at runlevel 5, change console as well as the xconsole directive in the <tt>/etc/security/console.perms</tt> to the following:
+<description>If the display manager has been altered to allow remote users to
+log in and the host is configured to run at runlevel 5, change console as well
+as the xconsole directive in the <tt>/etc/security/console.perms</tt> to the
+following:
 <pre>&lt;console&gt;=tty[0-9][0-9]* vc/[0-9][0-9]*</pre></description>
-<rationale>When a user logs in, the module pam_console.so called via the command login, or by some of the graphics program of logging, such as gdm, kdm, ​​and xdm. If this user is the first to log into the physical console - called the console user - the user module assures the mastery of a wide variety of devices normally belong to root. Administrative privileges should be limited for non-root users. Review the man page for <tt>pam_console</tt> for more information</rationale>
+<rationale>When a user logs in, the module pam_console.so called via the
+command login, or by some of the graphics program of logging, such as gdm, kdm,
+and xdm. If this user is the first to log into the physical console
+- called the console user - the user module assures the mastery of a wide
+variety of devices normally belong to root. Administrative privileges should be
+limited for non-root users. Review the man page for <tt>pam_console</tt> for
+more information</rationale>
 <ident cce="3685-5" />
 <oval id="console_device_restrict_access_server" />
 <ref nist="AC-6, CM-6, CM-7" />
@@ -91,8 +109,8 @@ the devices themselves should be tightly controlled.</rationale>
 <description>
 Another means of disabling USB storage is to disable all USB support provided
 by the operating system. This can be accomplished by adding the <tt>nousb</tt>
-argument to the kernel’s boot loader configuration. To disable kernel support
-for USB, append “nousb” to the kernel line in /etc/grub.conf as follows:
+argument to the kernel's boot loader configuration. To disable kernel support
+for USB, append "nousb" to the kernel line in /etc/grub.conf as follows:
 <pre>kernel /vmlinuz-<i>VERSION</i> ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb</pre>
 <i><b>WARNING:</b> Disabling all kernel support for USB will cause problems for systems with USB-based keyboards,
 mice, or printers. This guidance is inappropriate for systems which require USB connectivity.</i></description>
@@ -107,8 +125,8 @@ should be disabled and the devices themselves should be tightly controlled.</rat
 <Rule id="bios_disable_usb_boot">
 <title>Disable Booting from USB Devices</title>
 <description>An attacker with physical access could try to boot the system from a USB
-flash drive and then access any data on the system’s hard drive, circumventing the normal
-operating system’s access controls. To prevent this, configure the BIOS to disallow
+flash drive and then access any data on the system's hard drive, circumventing the normal
+operating system's access controls. To prevent this, configure the BIOS to disallow
 booting from USB drives. Also configure the BIOS or firmware password as described in
 the section titled "Set BIOS Password" to prevent unauthorized configuration changes.</description>
 <rationale>Booting a system from a USB device would allow an attacker to circumvent
@@ -149,7 +167,7 @@ not be arbitrarily introduced via the automounter.</rationale>
 
 <Rule id="gconf_gnome_disable_automount">
 <title>Disable GNOME Automounting</title>
-<description>The system’s default desktop environment, GNOME, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. Disable automount and autorun within GNOME by running the following:
+<description>The system's default desktop environment, GNOME, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. Disable automount and autorun within GNOME by running the following:
 <pre># gconftool-2 --direct \
 	--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
 	--type bool \
@@ -166,7 +184,7 @@ $ gconftool-2 --direct \
 	--config-source xml:read:/etc/gconf/gconf.xml.mandatory \
 	--get /apps/nautilus/preferences/media_autorun_never</pre>
 </description>
-<rationale>The system’s capabilities for automatic mounting should be configured to match whatever is defined by security
+<rationale>The system's capabilities for automatic mounting should be configured to match whatever is defined by security
 policy. Disabling USB storage as described in the USB section will prevent the use of USB storage devices, but
 this step should also be taken as an additional layer of protection to prevent automatic mounting of CDs and
 DVDs.
@@ -276,7 +294,7 @@ local system should be disabled.</rationale>
 
 <Rule id="disable_gnome_thumbnailers">
 <title>Disable All GNOME Thumbnailers</title>
-<description>The system’s default desktop environment, GNOME, uses
+<description>The system's default desktop environment, GNOME, uses
 a number of different thumbnailer programs to generate thumbnails
 for any new or modified content in an opened folder. The following
 command can disable the execution of these thumbnail applications:
@@ -285,7 +303,7 @@ command can disable the execution of these thumbnail applications:
   --type bool \
   --set /desktop/gnome/thumbnailers/disable_all true</pre>
 This effectively prevents an attacker from gaining access to a
-system through a flaw in GNOME’s Nautilus thumbnail creators.
+system through a flaw in GNOME's Nautilus thumbnail creators.
 </description>
 <rationale>An attacker with knowledge of a flaw in a GNOME thumbnailer application could craft a malicious
 file to exploit this flaw. Assuming the attacker could place the malicious file on the local filesystem
diff --git a/RHEL6/input/system/permissions/permissions.xml b/RHEL6/input/system/permissions/permissions.xml
index 5966065..74af260 100644
--- a/RHEL6/input/system/permissions/permissions.xml
+++ b/RHEL6/input/system/permissions/permissions.xml
@@ -3,7 +3,7 @@
 <description>Traditional Unix security relies heavily on file and
 directory permissions to prevent unauthorized users from reading or
 modifying files to which they should not have access. Adhere to the
-principle of least privilege — configure each file, directory, and
+principle of least privilege - configure each file, directory, and
 filesystem to allow only the access needed in order for that file
 to serve its purpose.
 <br /><br />
diff --git a/RHEL6/input/system/selinux.xml b/RHEL6/input/system/selinux.xml
index b44a145..b677ff6 100644
--- a/RHEL6/input/system/selinux.xml
+++ b/RHEL6/input/system/selinux.xml
@@ -9,8 +9,8 @@ The default SELinux policy, as configured on RHEL6, has been
 sufficiently developed and debugged that it should be usable on
 almost any Red Hat machine with minimal configuration and a small
 amount of system administrator training. This policy prevents
-system services — including most of the common network-visible
-services such as mail servers, ftp servers, and DNS servers — from
+system services - including most of the common network-visible
+services such as mail servers, ftp servers, and DNS servers - from
 accessing files which those services have no valid reason to
 access. This action alone prevents a huge amount of possible damage
 from network attacks against services, from trojaned software, and
diff --git a/RHEL6/input/system/software/disk_partitioning.xml b/RHEL6/input/system/software/disk_partitioning.xml
index 71a3b10..0877e8b 100644
--- a/RHEL6/input/system/software/disk_partitioning.xml
+++ b/RHEL6/input/system/software/disk_partitioning.xml
@@ -2,7 +2,7 @@
 <title>Disk Partitioning</title>
 <description>To ensure separation and protection of data there
 are top-level system directories which should be placed on their
-own physical partition or logical volume. The installer’s default
+own physical partition or logical volume. The installer's default
 partitioning scheme creates separate logical volumes for 
 <tt>/</tt>, <tt>/boot</tt>, and <tt>swap</tt>.
 <ul>
diff --git a/RHEL6/input/system/software/integrity.xml b/RHEL6/input/system/software/integrity.xml
index 0794be6..3a2e4cf 100644
--- a/RHEL6/input/system/software/integrity.xml
+++ b/RHEL6/input/system/software/integrity.xml
@@ -170,7 +170,7 @@ installed software packages, including many that are important to system
 security. Run the following command to list which files on the system
 have hashes that differ from what is expected by the RPM database:
 <pre># rpm -Va | grep '^..5'</pre>
-A “c” in the second column indicates that a file is a configuration file,
+A "c" in the second column indicates that a file is a configuration file,
 which may appropriately be expected to change.
 </description>
 <rationale>
diff --git a/RHEL6/input/system/software/updating.xml b/RHEL6/input/system/software/updating.xml
index 9e3bd6d..a89cab4 100644
--- a/RHEL6/input/system/software/updating.xml
+++ b/RHEL6/input/system/software/updating.xml
@@ -48,7 +48,7 @@ are from Red Hat.
 <Rule id="ensure_gpgcheck_globally_activated">
 <title>Ensure gpgcheck Enabled In Main Yum Configuration</title>
 <description>The <tt>gpgcheck</tt> option should be used to ensure that
-checking of an RPM package’s signature always occurs prior to its
+checking of an RPM package's signature always occurs prior to its
 installation. To configure yum to check package signatures before installing
 them, ensure that the following line appears in <tt>/etc/yum.conf</tt> in
 the <tt>[main]</tt> section:
-- 
1.7.1



More information about the scap-security-guide mailing list