On 10/11/13 8:45 AM, Jan Lieskovsky wrote:
This proposal fixes couple of text typos in the 'Restrict Root
Logins'
document:
* replace <tt>/etc/secuetty</tt> with <tt>/etc/securetty</tt>,
* s/on thesyste,/on the system,/
* s/passowrd/password/
* s/as as user can login/as user can login/
* remove couple instances of whitespace noise at the end of rows,
* be consistent - globally use one space character to start new
sentence (in cca 3 cases there have been two spaces).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
0001-RHEL6-Fix-couple-of-typos-in-the-text-in-Restrict-Ro.patch
From caab207a8c8a587914d9a1b318d972bbd678896c Mon Sep 17 00:00:00 2001
From: Jan Lieskovsky<jlieskov(a)redhat.com>
Date: Fri, 11 Oct 2013 14:38:27 +0200
Subject: [PATCH] [RHEL6] Fix couple of typos in the text in 'Restrict Root
Logins' document
Signed-off-by: Jan Lieskovsky<jlieskov(a)redhat.com>
---
.../system/accounts/restrictions/root_logins.xml | 35 +++++++++++-----------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/RHEL6/input/system/accounts/restrictions/root_logins.xml
b/RHEL6/input/system/accounts/restrictions/root_logins.xml
index 2f21dd9..547c712 100644
--- a/RHEL6/input/system/accounts/restrictions/root_logins.xml
+++ b/RHEL6/input/system/accounts/restrictions/root_logins.xml
@@ -25,14 +25,15 @@ include guidance describing how to prevent root from logging in via
SSH.
<Rule id="no_direct_root_logins" severity="medium">
<title>Direct root Logins Not Allowed</title>
<description>To further limit access to the <tt>root</tt> account,
administrators
-can disable root logins at the console by editing the <tt>/etc/secuetty</tt>
file.
+can disable root logins at the console by editing the
<tt>/etc/securetty</tt> file.
This file lists all devices the root user is allowed to login to. If the file does
-not exist at all, the root user can login through any communication device on thesyste,
-whether via the console or a raw network interface. This is dangerous as as user can
login to
-his machine as root via Telnet, which sends the passowrd in plain text over the
network.
-By default, Red Hat Enteprise Linux's <tt>/etc/securetty</tt> file only
allows the root user
-to login at the console physically attached to the machine. To prevent root from logging
in,
-remove the contents of this file. To prevent direct root logins, remove the contents of
this
+not exist at all, the root user can login through any communication device on the
+system, whether via the console or via a raw network interface. This is dangerous
+as user can login to his machine as root via Telnet, which sends the password in
+plain text over the network. By default, Red Hat Enteprise Linux's
+<tt>/etc/securetty</tt> file only allows the root user to login at the
console
+physically attached to the machine. To prevent root from logging in, remove the
+contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
<pre>
echo > /etc/securetty
@@ -47,7 +48,7 @@ If any output is returned, this is a finding.
<rationale>
Disabling direct root logins ensures proper accountability and multifactor
authentication to privileged accounts. Users will first login, then escalate
-to privileged (root) access via su/sudo. This is required for FISMA Low
+to privileged (root) access via su / sudo. This is required for FISMA Low
and FISMA Moderate systems.
</rationale>
<ref nist="IA-2(1)" />
@@ -110,16 +111,16 @@ using the root account.
<Rule id="no_root_webbrowsing">
<title>Restrict Web Browser Use for Administrative Accounts</title>
<description>
-Enforce policy requiring administrative accounts use web browsers only for
+Enforce policy requiring administrative accounts use web browsers only for
local service administration.
</description>
<ocil clause="this is not the case">
-Check the <tt>root</tt> home directory for a <tt>.mozilla</tt>
directory. If
+Check the <tt>root</tt> home directory for a <tt>.mozilla</tt>
directory. If
one exists, ensure browsing is limited to local service administration.
</ocil>
<rationale>
-If a browser vulnerability is exploited while running with administrative privileges,
-the entire system could be compromised. Specific exceptions for local service
+If a browser vulnerability is exploited while running with administrative privileges,
+the entire system could be compromised. Specific exceptions for local service
administration should be documented in site-defined policy.
</rationale>
</Rule>
@@ -133,8 +134,8 @@ function. Should an attacker be able to log into these accounts,
they should not be granted access to a shell.
<br /><br />
The login shell for each local account is stored in the last field of each line
-in <tt>/etc/passwd</tt>. System accounts are those user accounts with a
user ID less than
-500. The user ID is stored in the third field.
+in <tt>/etc/passwd</tt>. System accounts are those user accounts with a user
ID less than
+500. The user ID is stored in the third field.
If any system account <i>SYSACCT</i> (other than root) has a login shell,
disable it with the command:
<pre># usermod -s /sbin/nologin <i>SYSACCT</i></pre>
@@ -195,18 +196,18 @@ access to root privileges in an accountable manner.
Assuming root shell is bash, edit the following files:
<pre>~/.profile</pre>
<pre>~/.bashrc</pre>
-Change any <tt>PATH</tt> variables to the vendor default for root and remove
any
+Change any <tt>PATH</tt> variables to the vendor default for root and remove
any
empty <tt>PATH</tt> entries or references to relative paths.
</description>
<ocil clause="any of these conditions are not met">
To view the root user's <tt>PATH</tt>, run the following command:
<pre># env | grep PATH</pre>
-If correctly configured, the <tt>PATH</tt> must: use vendor default
settings,
+If correctly configured, the <tt>PATH</tt> must: use vendor default
settings,
have no empty entries, and have no entries beginning with a character
other than a slash (/).
</ocil>
<rationale>
-The root account's executable search path must be the vendor default, and must
+The root account's executable search path must be the vendor default, and must
contain only absolute paths.
</rationale>
<tested by="DS" on="20121024"/>
I thought this was replied to, but in case not... ack