<Group id="accounts-session">
<title>Secure Session Configuration Files for Login Accounts</title>
<description>When a user logs into a Unix account, the system
configures the user's session by reading a number of files. Many of
these files are located in the user's home directory, and may have
weak permissions as a result of user error or misconfiguration. If
an attacker can modify or even read certain types of account
configuration information, they can often gain full access to the
affected user's account. Therefore, it is important to test and
correct configuration file permissions for interactive accounts,
particularly those of privileged users such as root or system
administrators.</description>

<Value id="var_accounts_max_concurrent_login_sessions" type="number"
operator="equals" interactive="0">
<title>Maximum concurrent login sessions</title>
<description>Maximum number of concurrent sessions by a user</description>
<value selector="">1</value>
<value selector="1">1</value>
<value selector="3">3</value>
<value selector="5">5</value>
<value selector="10">10</value>
<value selector="15">15</value>
<value selector="20">20</value>
</Value>

<Rule id="accounts_max_concurrent_login_sessions">
<title>Limit the Number of Concurrent Login Sessions Allowed Per User</title>
<description>
Limiting the number of allowed users and sessions per user can limit risks related to Denial of
Service attacks. This addresses concurrent sessions for a single account and does not address
concurrent sessions by a single user via multiple accounts. The DoD requirement is 10. To set the number of concurrent
sessions per user add the following line in <tt>/etc/security/limits.conf</tt>:
<pre>* hard maxlogins <sub idref="var_accounts_max_concurrent_login_sessions" /></pre>
</description>
<rationale>Limiting simultaneous user logins can insulate the system from denial of service
problems caused by excessive logins. Automated login processes operating improperly or
maliciously may result in an exceptional number of simultaneous login sessions.
</rationale>
<ocil clause="it is not similar">
Run the following command to ensure the <tt>maxlogins</tt> value is configured for all users
on the system:
<pre>$ grep "maxlogins" /etc/security/limits.conf</pre>
You should receive output similar to the following:
<pre>*		hard	maxlogins	<sub idref="var_accounts_max_concurrent_login_sessions" /></pre>
</ocil>
<oval id="accounts_max_concurrent_login_sessions" value="var_accounts_max_concurrent_login_sessions" />
<ident cce="27457-1"  stig="RHEL-06-000319" />
<ref nist="AC-10" disa="54"/>
</Rule>

<Group id="root_paths">
<title>Ensure that No Dangerous Directories Exist in Root's Path</title>
<description>The active path of the root account can be obtained by
starting a new root shell and running:
<pre>$ sudo echo $PATH</pre>
This will produce a colon-separated list of
directories in the path.
<br /><br />
Certain path elements could be considered dangerous, as they could lead
to root executing unknown or
untrusted programs, which could contain malicious
code.
Since root may sometimes work inside
untrusted directories, the <tt>.</tt> character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
<br /><br />
It is a good practice for administrators to always execute
privileged commands by typing the full path to the
command.</description>

<Rule id="root_path_no_dot">
<title>Ensure that Root's Path Does Not Include Relative Paths or Null Directories</title>
<description>
Ensure that none of the directories in root's path is equal to a single
<tt>.</tt> character, or
that it contains any instances that lead to relative path traversal, such as
<tt>..</tt> or beginning a path without the slash (<tt>/</tt>) character.
Also ensure that there are no "empty" elements in the path, such as in these examples:
<pre>PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin</pre>
These empty elements have the same effect as a single <tt>.</tt> character.
</description>
<rationale>
Including these entries increases the risk that root could
execute code from an untrusted location.
</rationale>
<ident cce="26826-8" />
<oval id="root_path_no_dot" />
<ref nist="CM-6(b)" disa="366"/>
</Rule>

<Rule id="root_path_no_groupother_writable">
<title>Ensure that Root's Path Does Not Include World or Group-Writable Directories</title>
<description>
For each element in root's path, run:
<pre>$ sudo ls -ld <i>DIR</i></pre>
and ensure that write permissions are disabled for group and
other.
</description>
<ocil clause="group or other write permissions exist">
To ensure write permissions are disabled for group and other
 for each element in root's path, run the following command:
<pre>$ sudo ls -ld <i>DIR</i></pre>
</ocil>
<rationale>
Such entries increase the risk that root could
execute code provided by unprivileged users,
and potentially malicious code.
</rationale>
<ident cce="26768-2" />
<oval id="accounts_root_path_dirs_no_write" />
<ref nist="CM-6(b)" disa="366"/>
</Rule>
</Group>

<Rule id="homedir_perms_no_groupwrite_worldread">
<title>Ensure that User Home Directories are not Group-Writable or World-Readable</title>
<description>For each human user of the system, view the
permissions of the user's home directory:
<pre>$ sudo ls -ld /home/<i>USER</i></pre>
Ensure that the directory is not group-writable and that it
is not world-readable. If necessary, repair the permissions:
<pre>$ sudo chmod g-w /home/<i>USER</i>
$ sudo chmod o-rwx /home/<i>USER</i></pre>
</description>
<ocil clause="the user home directory is group-writable or world-readable">
To ensure the user home directory is not group-writable or world-readable, run the following:
<pre>$ sudo ls -ld /home/<i>USER</i></pre>
</ocil>
<warning category="general">This action may involve
modifying user home directories. Notify your user community, and
solicit input if appropriate, before making this type of
change.</warning>
<rationale>
User home directories contain many configuration files which
affect the behavior of a user's account. No user should ever have
write permission to another user's home directory. Group shared
directories can be configured in sub-directories or elsewhere in the
filesystem if they are needed. Typically, user home directories
should not be world-readable, as it would disclose file names
to other users. If a subset of users need read access
to one another's home directories, this can be provided using
groups or ACLs.
</rationale>
<ident cce="26981-1" />
<oval id="file_permissions_home_dirs" />
<ref nist="AC-6(7)"/>
</Rule>

<Group id="user_umask">
<title>Ensure that Users Have Sensible Umask Values</title>
<description>
The umask setting controls the default permissions
for the creation of new files.
With a default <tt>umask</tt> setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a <tt>umask</tt> of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a <tt>umask</tt> of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
<br /><br />
<!--In addition, it may be necessary to change root's <tt>umask</tt>
temporarily in order to install software or files which must be
readable by other users, or to change the default umasks of certain
service accounts such as the FTP user. However, setting a
restrictive default protects the files of users who have not taken
steps to make their files more available, and preventing files from
being inadvertently shared.-->
</description>

<!-- Define a new catch-all Rule?
<li>View the additional configuration files <tt>/etc/csh.login</tt> and
<tt>/etc/profile.d/*</tt>, and ensure that none of these files redefine the
umask to a more permissive value unless there is a good reason for
it.
</li>
<li>-->

<!-- Define a new Rule to check root's umask?
It seems unlikely to ever be misconfigured.
Edit the root shell configuration files <tt>/root/.bashrc</tt>,
<tt>/root/.bash profile</tt>, <tt>/root/.cshrc</tt>, and <tt>/root/.tcshrc</tt>. Add or
correct the line:
<pre>umask 077</pre>
</li>
-->
<Value id="var_accounts_user_umask" type="string"
operator="equals" interactive="0">
<title>Sensible umask</title>
<description>Enter default user umask</description>
<value selector="">027</value>
<value selector="007">007</value>
<value selector="022">022</value>
<value selector="027">027</value>
<value selector="077">077</value>
</Value>

<Rule id="accounts_umask_bashrc">
<title>Ensure the Default Bash Umask is Set Correctly</title>
<description>
To ensure the default umask for users of the Bash shell is set properly,
add or correct the <tt>umask</tt> setting in <tt>/etc/bashrc</tt> to read
as follows:
<pre>umask <sub idref="var_accounts_user_umask" /></pre>
</description>
<rationale>The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users.</rationale>
<ocil clause="the above command returns no output, or if the umask is configured incorrectly">
Verify the <tt>umask</tt> setting is configured correctly in the <tt>/etc/bashrc</tt> file by
running the following command:
<pre>$ grep "umask" /etc/bashrc</pre>
All output must show the value of <tt>umask</tt> set as shown below:
<pre>$ grep "umask" /etc/bashrc
umask <sub idref="var_accounts_user_umask" />
umask <sub idref="var_accounts_user_umask" /></pre>
</ocil>
<ident cce="26917-5"  stig="RHEL-06-000342" />
<oval id="accounts_umask_etc_bashrc" value="var_accounts_user_umask"/>
<ref nist="SA-8" disa="366"/>
<tested by="JL" on="20140912"/>
</Rule>

<Rule id="accounts_umask_cshrc">
<title>Ensure the Default C Shell Umask is Set Correctly</title>
<description>
To ensure the default umask for users of the C shell is set properly,
add or correct the <tt>umask</tt> setting in <tt>/etc/csh.cshrc</tt> to read as follows:
<pre>umask <sub idref="var_accounts_user_umask" /></pre>
</description>
<rationale>The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users.</rationale>
<ocil clause="the above command returns no output, or if the umask is configured incorrectly">
Verify the <tt>umask</tt> setting is configured correctly in the <tt>/etc/csh.cshrc</tt> file by
running the following command:
<pre>$ grep "umask" /etc/csh.cshrc</pre>
All output must show the value of <tt>umask</tt> set as shown in the below:
<pre>$ grep "umask" /etc/csh.cshrc
umask <sub idref="var_accounts_user_umask" /></pre>
</ocil>
<ident cce="27034-8"  stig="RHEL-06-000343" />
<oval id="accounts_umask_etc_csh_cshrc" value="var_accounts_user_umask"/>
<ref nist="SA-8" disa="366"/>
<tested by="JL" on="20140912"/>
</Rule>

<Rule id="accounts_umask_etc_profile">
<title>Ensure the Default Umask is Set Correctly in /etc/profile</title>
<description>
To ensure the default umask controlled by <tt>/etc/profile</tt> is set properly,
add or correct the <tt>umask</tt> setting in <tt>/etc/profile</tt> to read as follows:
<pre>umask <sub idref="var_accounts_user_umask" /></pre>
</description>
<rationale>The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users.</rationale>
<ident cce="26669-2"  stig="RHEL-06-000344" />
<ocil clause="the above command returns no output, or if the umask is configured incorrectly">
Verify the <tt>umask</tt> setting is configured correctly in the <tt>/etc/profile</tt> file by
running the following command:
<pre>$ grep "umask" /etc/profile</pre>
All output must show the value of <tt>umask</tt> set as shown in the below:
<pre>$ grep "umask" /etc/profile
umask <sub idref="var_accounts_user_umask" /></pre>
</ocil>
<oval id="accounts_umask_etc_profile" value="var_accounts_user_umask" />
<tested by="swells" on="20120929"/>
<ref nist="SA-8" disa="366"/>
</Rule>

<Rule id="accounts_umask_login_defs">
<title>Ensure the Default Umask is Set Correctly in login.defs</title>
<description>
To ensure the default umask controlled by <tt>/etc/login.defs</tt> is set properly,
add or correct the <tt>UMASK</tt> setting in <tt>/etc/login.defs</tt> to read as follows:
<pre>UMASK <sub idref="var_accounts_user_umask" /></pre>
</description>
<rationale>The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and
written to by unauthorized users.</rationale>
<ocil clause="the above command returns no output, or if the umask is configured incorrectly">
Verify the <tt>UMASK</tt> setting is configured correctly in the <tt>/etc/login.defs</tt> file by
running the following command:
<pre>$ grep -i "UMASK" /etc/login.defs</pre>
All output must show the value of <tt>umask</tt> set as shown in the below:
<pre>$ grep -i "UMASK" /etc/login.defs
umask <sub idref="var_accounts_user_umask" /></pre>
</ocil>
<ident cce="26371-5"  stig="RHEL-06-000345" />
<oval id="accounts_umask_etc_login_defs" value="var_accounts_user_umask" />
<ref nist="SA-8" disa="366"/>
<tested by="JL" on="20140912" />
</Rule>

</Group>
</Group>
