Signed-off-by: Jeffrey Blank <blank(a)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(a)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><console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0
<xconsole>=: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><console>=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