Signed-off-by: Willy Santos <wsantos(a)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
@@ -256,8 +256,8 @@ can leave your NFS configuration more open than intended. Therefore, exercise ca
<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.
</Group> <!-- configure_exports_restrictively -->
@@ -280,20 +280,60 @@ Authorized hosts can be specified in several different formats:
</Group> <!-- use_acl_enforce_auth_restrictions -->
+<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.
+</Group> <!-- export_filesystems_read_only -->
+<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
+<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.
+</Group> <!-- specify_anonymous_uid_gid -->
<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>.
-<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" />
+<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>.
+<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" />
</Group> <!-- nfs_configuring_servers -->
The python-lxml module is needed to make scap-security-guide.
Michael Palmiotto (1):
Make SSG require python and python-lxml
scap-security-guide.spec | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
These patches include some CCI mappings that were documented as Trac tickets, documented V-IDs that can be satisfied by rpmverify, and added some more prose to the NFS section.
Willy Santos (5):
Mapped CCIs 196 and 197 to disable_telnet_service as reference in
trac ticket #45.
Added some NFSv4 guidance to the rpcbind section.
Added V-IDs to rules we can check using rpmverify so they will appear
in the notes column of the table.
Continued work on NFS service prose.
Continued work on NFS section of the guide.
RHEL6/input/auxiliary/transition_notes.xml | 8 +++-
RHEL6/input/services/nfs.xml | 66 +++++++++++++++++++++++++---
RHEL6/input/services/obsolete.xml | 2 +-
3 files changed, 67 insertions(+), 9 deletions(-)
This patch includes a new file, transition_notes.xml, and also a new transform
that can output notes (with attribution) as part of a table of settings. This
supports open, transparent migration of the RHEL 5 STIG to consensus for RHEL
Jeffrey Blank (1):
support for adding notes to RHEL 5 STIG content, for transparent
migration to consensus
RHEL6/Makefile | 1 +
RHEL6/input/auxiliary/transition_notes.xml | 31 ++++
RHEL6/transforms/xccdf2table-stig-addnotes.xslt | 172 +++++++++++++++++++++++
3 files changed, 204 insertions(+), 0 deletions(-)
create mode 100644 RHEL6/input/auxiliary/transition_notes.xml
create mode 100644 RHEL6/transforms/xccdf2table-stig-addnotes.xslt
In the process of mapping CCI IDs from the OS SRG to Rules/Groups in the SSG, we found a number of rules/requirements in the RHEL 5 STIG that are mapping to CCI IDs not in the OS SRG.
In the SSG should we be mapping to CCI IDs not on the OS SRG, or is it preferred to map to items only in the OS SRG? Either one could be appropriate.
This is designed to allow for easy viewing of the CCIs which are
(or aren't) mapped to Rules in the scap-security-guide content and the RHEL 5 STIG.
This is intended to ensure that the scap-security-guide leverages all previous
CCI mapping work from the RHEL 5 STIG for its RHEL 6 content.
Jeffrey Blank (1):
augmented transforms to display CCIs with STIG tables, generate STIG
table sorted by CCI * interestingly, some CCIs referenced in
the RHEL 5 STIG are not in the OS SRG * and CCIs in the OS SRG
are not fully mapped to items in the STIG
rhel6/src/Makefile | 1 +
rhel6/src/transforms/xccdf2table-stig.xslt | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)