[PATCH] Added more NFS prose.

Willy Santos wsantos at redhat.com
Mon Jul 16 13:06:44 UTC 2012


That's correct.

On 07/14/2012 03:58 PM, Jeffrey Blank wrote:
> ACK.  I believe this will pretty much round out the NFS guidance from
> previous sources such as the NSA RHEL 5 Guide and also the DISA RHEL 5
> STIG, right?
>
> (There might be more that should be said, but this should ensure we've
> included some relevant previous work.)
>
>
>
> On 07/13/2012 04:48 PM, Willy Santos wrote:
>> Signed-off-by: Willy Santos <wsantos at redhat.com>
>> ---
>>   RHEL6/input/services/nfs.xml |   50 +++++++++++++++++++++++++++++++++++++----
>>   1 files changed, 45 insertions(+), 5 deletions(-)
>>
>> diff --git a/RHEL6/input/services/nfs.xml b/RHEL6/input/services/nfs.xml
>> index 1d20041..7f5e049 100644
>> --- a/RHEL6/input/services/nfs.xml
>> +++ b/RHEL6/input/services/nfs.xml
>> @@ -256,8 +256,8 @@ can leave your NFS configuration more open than intended. Therefore, exercise ca
>>   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,
>> +<pre>/DIR	host1(opt1,opt2) host2(opt3)</pre>
>> +where <tt>/DIR</tt> is a directory or filesystem to export, <tt>hostN</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 -->
>> @@ -280,20 +280,60 @@ Authorized hosts can be specified in several different formats:
>>   </description>
>>   </Group> <!-- use_acl_enforce_auth_restrictions -->
>>   
>> +<Group id="export_filesystems_read_only">
>> +<title>Export Filesystems Read-Only if Possible</title>
>> +<description>If a filesystem is being exported so that users can view the files in a convenient
>> +fashion, but there is no need for users to edit those files, exporting the filesystem read-only
>> +removes an attack vector against the server. The default filesystem export mode is <tt>ro</tt>,
>> +so do not specify <tt>rw</tt> without a good reason.
>> +</description>
>> +</Group> <!-- export_filesystems_read_only -->
>> +
>> +<Group id="specify_anonymous_uid_gid">
>> +<title>Specify UID and GID for Anonymous Connections</title>
>> +<description>When an NFS server is configured to deny remote <tt>root</tt> access, a selected UID and GID
>> +are used to handle requests from the remote <tt>root</tt> user. The UID and GID should be chosen from the
>> +system to provide the appropriate level of non-privileged access. By default, the NFS server will
>> +map remote <tt>root</tt> users to the <tt>nobody</tt> local account. Specifying the anonymous UID and GID
>> +as -1 ensures that the remote <tt>root</tt> user is mapped to a local account which has no permissions on the
>> +system.
>> +<br /><br />
>> +To specify the UID and GID for remote <tt>root</tt> users, edit the <tt>/etc/exports</tt> file and add
>> +<tt>anonuid=-1</tt> and <tt>anongid=-1</tt> to the options list for each export.
>> +</description>
>> +</Group> <!-- specify_anonymous_uid_gid -->
>> +
>>   <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
>>   should not be disabled.
>> -
>> -Ensure that no line in <tt>/etc/exports</tt> contains the option <tt>no_root_squash</tt>
>> +<br /><br />
>> +Ensure that no line in <tt>/etc/exports</tt> contains the option <tt>no_root_squash</tt>.
>>   </description>
>> -<rationale>If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system.</rationale>
>> +<rationale>If the NFS server allows root access to local file systems from remote hosts, this
>> +access could be used to compromise the system.</rationale>
>>   <ident cce="4544-3" />
>>   <oval id="TO:DO" />
>>   </Rule>
>>   
>> +<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
>> +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.
>> +<br /><br />
>> +Ensure that no line in <tt>/etc/exports</tt> contains the option <tt>insecure</tt>.
>> +</description>
>> +<rationale>Allowing client requests to be made from ports higher than 1024 could allow a unprivileged
>> +user to initiate an NFS connection. If the unprivileged user account has been compromised, an
>> +attacker could gain access to data on the NFS server.</rationale>
>> +<ident cce="4465-1" />
>> +<oval id="TO:DO" />
>> +</Rule>
>> +
>>   </Group> <!-- nfs_configuring_servers -->
>>   
>>   </Group>




More information about the scap-security-guide mailing list