4:54 p.m.
Removed some unnecessary white space.
Fixed reference to a NSA RHEL 5 Security Guide section number to correct section on the
SSG.
Signed-off-by: Willy Santos <wsantos(a)redhat.com>
---
RHEL6/input/services/nfs.xml | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/RHEL6/input/services/nfs.xml b/RHEL6/input/services/nfs.xml
index 90b6035..1d20041 100644
--- a/RHEL6/input/services/nfs.xml
+++ b/RHEL6/input/services/nfs.xml
@@ -221,7 +221,7 @@ There is no need to run the NFS server daemons
<tt>nfs</tt> and <tt>rpcsvcgssd</
<title>Mount Remote Filesystems with Restrictive Options</title>
<description>Edit the file <tt>/etc/fstab</tt>. For each filesystem
whose type (column 3) is <tt>nfs</tt> or <tt>nfs4</tt>, add the
text <tt>,nodev,nosuid</tt> to the list of mount options in column 4. If
appropriate, also add <tt>,noexec</tt>.
<br /><br />
-See Section 2.2.1.2 for a description of the effects of these options. In general,
execution of files mounted via NFS should be considered risky because of the possibility
that an adversary could intercept the request and substitute a malicious file. Allowing
setuid files to be executed from remote servers is particularly risky, both for this
reason and because it requires the clients to extend root-level trust to the NFS
server.</description>
+See the section titled "Restrict Partition Mount Options" for a description of
the effects of these options. In general, execution of files mounted via NFS should be
considered risky because of the possibility that an adversary could intercept the request
and substitute a malicious file. Allowing setuid files to be executed from remote servers
is particularly risky, both for this reason and because it requires the clients to extend
root-level trust to the NFS server.</description>
<Rule id="use_nodev_option_on_nfs_mounts">
<title>Mount Remote Filesystems with nodev</title>
@@ -248,26 +248,26 @@ 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
-and directories may be accessed via NFS. (See the <tt>exports(5)</tt> manpage
for more information about the
+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 />
-The syntax of the <tt>exports</tt> file is not necessarily checked fully on
reload, and syntax errors
-can leave your NFS configuration more open than intended. Therefore, exercise caution
when modifying
+The syntax of the <tt>exports</tt> file is not necessarily checked fully on
reload, and syntax errors
+can leave your NFS configuration more open than intended. Therefore, exercise caution
when modifying
the file.
<br /><br />
The syntax of each line in <tt>/etc/exports</tt> is
<pre>/DIR ipaddr1(opt1,opt2) ipaddr2(opt3)</pre>
-where <tt>/DIR</tt> is a directory or filesystem to export,
<tt>ipaddrN</tt> is an IP address, netblock,
+where <tt>/DIR</tt> is a directory or filesystem to export,
<tt>ipaddrN</tt> is an IP address, netblock,
hostname, domain, or netgroup to which to export, and <tt>optN</tt> is an
option.
</description>
</Group> <!-- configure_exports_restrictively -->
<Group id="use_acl_enforce_auth_restrictions">
<title>Use Access Lists to Enforce Authorization Restrictions</title>
-<description>When configuring NFS exports, ensure that each export line in
<tt>/etc/exports</tt> contains
-a list of hosts which are allowed to access that export. If no hosts are specified on an
export line,
-then that export is available to any remote host which requests it. All lines of the
exports file should
-specify the hosts (or subnets, if needed) which are allowed to access the exported
directory, so that
+<description>When configuring NFS exports, ensure that each export line in
<tt>/etc/exports</tt> contains
+a list of hosts which are allowed to access that export. If no hosts are specified on an
export line,
+then that export is available to any remote host which requests it. All lines of the
exports file should
+specify the hosts (or subnets, if needed) which are allowed to access the exported
directory, so that
unknown or remote hosts will be denied.
<br /><br />
Authorized hosts can be specified in several different formats:
@@ -282,9 +282,9 @@ Authorized hosts can be specified in several different formats:
<Rule id="use_root_squashing_all_exports">
<title>Use Root-Squashing on All Exports</title>
-<description>If a filesystem is exported using root squashing, requests from root
on the client
-are considered to be unprivileged (mapped to a user such as nobody). This provides some
mild
-protection against remote abuse of an NFS server. Root squashing is enabled by default,
and
+<description>If a filesystem is exported using root squashing, requests from root
on the client
+are considered to be unprivileged (mapped to a user such as nobody). This provides some
mild
+protection against remote abuse of an NFS server. Root squashing is enabled by default,
and
should not be disabled.
Ensure that no line in <tt>/etc/exports</tt> contains the option
<tt>no_root_squash</tt>
@@ -299,4 +299,3 @@ Ensure that no line in <tt>/etc/exports</tt> contains the
option <tt>no_root_squ
</Group>
</Group>
</Group>
-
--
1.7.7.6