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 <[email protected]> --- 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 _______________________________________________ scap-security-guide mailing list [email protected] https://fedorahosted.org/mailman/listinfo/scap-security-guide
