<Group id="restrictions">
<title>Restrict Programs from Dangerous Execution Patterns</title>
<description>The recommendations in this section are designed to
ensure that the system's features to protect against potentially
dangerous program execution are activated.
These protections are applied at the system initialization or
kernel level, and defend against certain types of badly-configured
or compromised programs.</description>

<Group id="daemon_umask">
<title>Daemon Umask</title>
<description>The umask is a per-process setting which limits
the default permissions for creation of new files and directories.
The system includes initialization scripts which set the default umask
for system daemons.
</description>

<Value id="var_umask_for_daemons" type="string" operator="equals" interactive="0">
<title>daemon umask</title>
<description>Enter umask for daemons</description>
<value selector="">022</value>
<value selector="022">022</value>
<value selector="027">027</value>
</Value>

<Rule id="umask_for_daemons">
<title>Set Daemon Umask</title>
<description>The file <tt>/etc/init.d/functions</tt> includes initialization
parameters for most or all daemons started at boot time.  The default umask of
022 prevents creation of group- or world-writable files.  To set the default
umask for daemons, edit the following line, inserting 022 or 027 for
<i>UMASK</i> appropriately:
<pre>umask <i><sub idref="var_umask_for_daemons" /></i></pre>
Setting the umask to too restrictive a setting can cause serious errors at
runtime.  Many daemons on the system already individually restrict themselves to
a umask of 077 in their own init scripts.
</description>
<ocil clause="it does not">
To check the value of the <tt>umask</tt>, run the following command:
<pre>$ grep umask /etc/init.d/functions</pre>
The output should show either <tt>022</tt> or <tt>027</tt>.
</ocil>
<rationale>The umask influences the permissions assigned to files created by a
process at run time.  An unnecessarily permissive umask could result in files
being created with insecure permissions.</rationale>
<ident cce="RHEL7-CCE-TBD" />
<oval id="umask_for_daemons" value="var_umask_for_daemons"/>
<ref nist="AC-6"/>
<tested by="JL" on="20140912"/>
</Rule>

</Group>

<Group id="coredumps">
<title>Disable Core Dumps</title>
<description>A core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
<br /><br />
Once a hard limit is set in <tt>/etc/security/limits.conf</tt>, a
user cannot increase that limit within his or her own session. If access
to core dumps is required, consider restricting them to only
certain users or groups. See the <tt>limits.conf</tt> man page for more
information.
<br /><br />
The core dumps of setuid programs are further protected. The
<tt>sysctl</tt> variable <tt>fs.suid_dumpable</tt> controls whether
the kernel allows core dumps from these programs at all. The default
value of 0 is recommended.</description>

<Rule id="disable_users_coredumps">
<title>Disable Core Dumps for All Users</title>
<description>To disable core dumps for all users, add the following line to
<tt>/etc/security/limits.conf</tt>:
<pre>*     hard   core    0</pre>
</description>
<ocil clause="it is not">
To verify that core dumps are disabled for all users, run the following command:
<pre>$ grep core /etc/security/limits.conf</pre>
The output should be:
<pre>*     hard   core    0</pre>
</ocil>
<rationale>A core dump includes a memory image taken at the time the operating system
terminates an application. The memory image could contain sensitive data and is generally useful
only for developers trying to debug problems.</rationale>
<ident cce="RHEL7-CCE-TBD" />
<oval id="disable_users_coredumps" />
<ref nist="SC-5" />
</Rule>


<Rule id="sysctl_fs_suid_dumpable">
<title>Disable Core Dumps for SUID programs</title>
<description><sysctl-desc-macro sysctl="fs.suid_dumpable" value="0" /></description>
<ocil><sysctl-check-macro sysctl="fs.suid_dumpable" value="0" /></ocil>
<rationale>The core dump of a setuid program is more likely to contain
sensitive data, as the program itself runs with greater privileges than the
user who initiated execution of the program.  Disabling the ability for any
setuid program to write a core file decreases the risk of unauthorized access
of such data.</rationale>
<ident cce="RHEL7-CCE-TBD" />
<oval id="sysctl_fs_suid_dumpable" />
<ref nist="SI-11" />
</Rule>
</Group>

<Group id="enable_execshield_settings">
<title>Enable ExecShield</title>
<description>ExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default
on 32-bit systems and controlled through <tt>sysctl</tt> variables 
<tt>kernel.exec-shield</tt> and <tt>kernel.randomize_va_space</tt>. On the latest
64-bit systems, <tt>kernel.exec-shield</tt> cannot be enabled or disabled with 
<tt>sysctl</tt>.
</description>

<Rule id="sysctl_kernel_exec_shield" severity="medium">
<title>Enable ExecShield</title>
<description>By default on Red Hat Enterprise Linux 7 64-bit systems, ExecShield
is enabled and can only be disabled if the hardware does not support ExecShield
or is disabled in <tt>/etc/default/grub</tt>. For Red Hat Enterprise Linux 7 
32-bit systems, <tt>sysctl</tt> can be used to enable ExecShield.</description>
<ocil clause="ExecShield is not supported by the hardware, is not enabled, or
has been disabled by the kernel configuration.">
To verify ExecShield is enabled on 64-bit Red Hat Enterprise Linux 7 systems,
run the following command:
<pre>$ dmesg | grep '[NX|DX]*protection'</pre>
The output should not contain <tt>'disabled by kernel command line option'</tt>.
To verify that ExecShield has not been disabled in the kernel configuration,
run the following command:
<pre>$ sudo grep noexec /boot/grub2/grub.cfg</pre>
The output should not return <tt>noexec=off</tt>.
For 32-bit Red Hat Enterprise Linux 7 systems, run the following command:
<pre>$ sysctl kernel.exec-shield</pre>
The output should be:
<pre><sysctl-desc-macro sysctl="kernel.exec-shield" value="1" /></pre>
</ocil>
<rationale>ExecShield uses the segmentation feature on all x86 systems
to prevent execution in memory higher than a certain address. It
writes an address as a limit in the code segment descriptor, to
control where code can be executed, on a per-process basis. When
the kernel places a process's memory regions such as the stack and
heap higher than this address, the hardware prevents execution in that
address range. This is enabled by default on the latest Red Hat and Fedora 
systems if supported by the hardware.</rationale>
<ident cce="RHEL7-CCE-TBD" />
<oval id="sysctl_kernel_exec_shield" />
<ref nist="SC-39" disa="2530" />
<tested by="DS" on="20121024"/>
</Rule>

<Rule id="sysctl_kernel_randomize_va_space" severity="medium">
<title>Enable Randomized Layout of Virtual Address Space</title>
<description><sysctl-desc-macro sysctl="kernel.randomize_va_space" value="2" /></description>
<ocil><sysctl-check-macro sysctl="kernel.randomize_va_space" value="2" /></ocil>
<rationale> Address space layout randomization (ASLR) makes it more difficult
for an attacker to predict the location of attack code they have introduced
into a process's address space during an attempt at exploitation.  Additionally, ASLR 
makes it more difficult for an attacker to know the location of existing code
in order to re-purpose it using return oriented programming (ROP) techniques.
</rationale>
<ident cce="RHEL7-CCE-TBD" />
<oval id="sysctl_kernel_randomize_va_space" />
<ref nist="SC-30(2)" />
<tested by="DS" on="20121024"/>
</Rule>
</Group>

<Group id="enable_nx">
<title>Enable Execute Disable (XD) or No Execute (NX) Support on
x86 Systems</title>
<description>Recent processors in the x86 family support the
ability to prevent code execution on a per memory page basis.
Generically and on AMD processors, this ability is called No
Execute (NX), while on Intel processors it is called Execute
Disable (XD). This ability can help prevent exploitation of buffer
overflow vulnerabilities and should be activated whenever possible.
Extra steps must be taken to ensure that this protection is
enabled, particularly on 32-bit x86 systems. Other processors, such
as Itanium and POWER, have included such support since inception
and the standard kernel for those platforms supports the
feature. This is enabled by default on the latest Red Hat and 
Fedora systems if supported by the hardware.</description>

<Rule id="install_PAE_kernel_on_x86-32">
<title>Install PAE Kernel on Supported 32-bit x86 Systems</title>
<description>Systems that are using the 64-bit x86 kernel package
do not need to install the kernel-PAE package because the 64-bit
x86 kernel already includes this support. However, if the system is
32-bit and also supports the PAE and NX features as
determined in the previous section, the kernel-PAE package should
be installed to enable XD or NX support:
<pre>$ sudo yum install kernel-PAE</pre>
The installation process should also have configured the
bootloader to load the new kernel at boot. Verify this at reboot
and modify <tt>/etc/default/grub</tt> if necessary.</description>
<warning category="hardware">The kernel-PAE package should not be
installed on older systems that do not support the XD or NX bit, as
this may prevent them from booting.</warning>
<rationale>On 32-bit systems that support the XD or NX bit, the vendor-supplied
PAE kernel is required to enable either Execute Disable (XD) or No Execute (NX) support.</rationale>
<ident cce="RHEL7-CCE-TBD" />
<ref nist="CM-6(b)" />
</Rule>

<Rule id="bios_enable_execution_restrictions">
<title>Enable NX or XD Support in the BIOS</title>
<description>Reboot the system and enter the BIOS or Setup configuration menu.
Navigate the BIOS configuration menu and make sure that the option is enabled. The setting may be located
under a Security section. Look for Execute Disable (XD) on Intel-based systems and No Execute (NX)
on AMD-based systems.</description>
<rationale>Computers with the ability to prevent this type of code execution frequently put an option in the BIOS that will
allow users to turn the feature on or off at will.</rationale>
<ref nist="CM-6(b)" />
<ident cce="RHEL7-CCE-TBD" />
</Rule>

</Group> <!--<Group id="enable_nx"> -->

<Rule id="enable_dmesg_restriction">
<title>Restrict Access to Kernel Message Buffer</title>
<description><sysctl-desc-macro sysctl="kernel.dmesg_restrict" value="1" /></description>
<ocil><sysctl-check-macro sysctl="kernel.dmesg_restrict" value="1" /></ocil>
<rationale>Unprivileged access to the kernel syslog can expose sensitive kernel 
address information.</rationale>
<ident cce="RHEL7-CCE-TBD" />
<ref nist="SI-11" disa="1314" />
<oval id="sysctl_kernel_dmesg_restrict" />
</Rule> 
  

</Group> <!--<Group id="restrictions"> -->
