docs/52878: [PATCH] security(7): small clairification on securing staff accounts

[Brian Minard]

>Number:         52878
>Category:       docs
>Synopsis:       [PATCH] security(7): small clairification on securing staff accounts
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 02 18:40:07 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator:     Brian Minard
>Release:        FreeBSD 4.8-STABLE i386
>Organization:
>Environment:
System: FreeBSD spud.flatfoot.ca 4.8-STABLE FreeBSD 4.8-STABLE #0: Mon May 19 21:28:08 EDT 2003 root at spud.flatfoot.ca:/usr/obj/usr/src/sys/SPUD i386


>Description:
	This PR contains several patches for security(7).  

	  (1) corrects a typo

	  (2) replace hacker with cracker
	 
	  This patch moves the man page in line with the language used on
	  www.freebsd.org/security/security.html and the Security chapter of
	  the Handbook (which contains only one (incorrect) usage of hacker).

	  (3) provide clairification on an assumption about the safety of root,
	  given that an attacker has obtained the password file

	  This patch attempts to clairify earlier statements on the necessity
	  of securing root.  The unpatched paragraph says that you can secure
	  secure root idirectly by securing the staff accounts.  This still
	  requires that remote access to root be prohibited.  Misunderstanding
	  this point can be costly.

>How-To-Repeat:
>Fix:
--- security.7	Wed May 28 19:24:13 2003
+++ security.7	Sun Jun  1 18:14:29 2003
@@ -218,7 +218,7 @@
 .Pp
 Using something like kerberos also gives you the ability to disable or
 change the password for a staff account in one place and have it immediately
-effect all the machine the staff member may have an account on.  If a staff
+effect all the machines the staff member may have an account on.  If a staff
 member's account gets compromised, the ability to instantly change his
 password on all machines should not be underrated.  With discrete passwords,
 changing a password on N machines can be a mess.  You can also impose


--- security.7	Wed May 28 19:24:13 2003
+++ security.7	Wed May 28 19:38:18 2003
@@ -40,9 +40,9 @@
 (see
 .Xr chflags 1 )
 on every system binary because while this may temporarily protect the
-binaries, it prevents a hacker who has broken in from making an
+binaries, it prevents a cracker who has broken in from making an
 easily detectable change that may result in your security mechanisms not
-detecting the hacker at all.
+detecting the cracker at all.
 .Pp
 System security also pertains to dealing with various forms of attack,
 including attacks that attempt to crash or otherwise make a system unusable
@@ -103,10 +103,10 @@
 user's account.  If an attacker has found a way to break root on a machine,
 the attacker may not have a need to install a backdoor.
 Many of the root holes found and closed to date involve a considerable amount
-of work by the hacker to cleanup after himself, so most hackers do install
-backdoors.  This gives you a convenient way to detect the hacker.  Making
-it impossible for a hacker to install a backdoor may actually be detrimental
-to your security because it will not close off the hole the hacker found to
+of work by the cracker to cleanup after himself, so most crackers do install
+backdoors.  This gives you a convenient way to detect the cracker.  Making
+it impossible for a cracker to install a backdoor may actually be detrimental
+to your security because it will not close off the hole the cracker found to
 break in the first place.
 .Pp
 Security remedies should always be implemented with a multi-layered
@@ -378,7 +378,7 @@
 way to look for modified files is from another (often centralized)
 limited-access system.
 Writing your security scripts on the extra-secure limited-access system
-makes them mostly invisible to potential hackers, and this is important.
+makes them mostly invisible to potential crackers, and this is important.
 In order to take maximum advantage you generally have to give the
 limited-access box significant access to the other machines in the business,
 usually either by doing a read-only NFS export of the other machines to the
@@ -466,7 +466,7 @@
 thought.  Even more importantly, a security administrator should mix it up
 a bit - if you use recommendations such as those given by this manual
 page verbatim, you give away your methodologies to the prospective
-hacker who also has access to this manual page.
+cracker who also has access to this manual page.
 .Sh SPECIAL SECTION ON D.O.S. ATTACKS
 This section covers Denial of Service attacks.  A DOS attack is typically
 a packet attack.  While there isn't much you can do about modern spoofed
@@ -633,7 +633,7 @@
 keys that give you access to the rest of the system, and you ssh to an
 unsecure machine, your keys becomes exposed.  The actual keys themselves are
 not exposed, but ssh installs a forwarding port for the duration of your
-login and if a hacker has broken root on the unsecure machine he can utilize
+login and if a cracker has broken root on the unsecure machine he can utilize
 that port to use your keys to gain access to any other machine that your
 keys unlock.
 .Pp


--- security.7	Sun Jun  1 18:16:10 2003
+++ security.7	Sun Jun  1 18:16:42 2003
@@ -180,8 +180,9 @@
 An indirect way to secure the root account is to secure your staff accounts
 by using an alternative login access method and *'ing out the crypted password
 for the staff accounts.  This way an intruder may be able to steal the password
-file but will not be able to break into any staff accounts (or, indirectly,
-root, even if root has a crypted password associated with it).  Staff members
+file but will not be able to break into any staff accounts or root, even if
+root has a crypted password associated with it (assuming, of course, that
+you've limited root access to the console).  Staff members
 get into their staff accounts through a secure login mechanism such as
 .Xr kerberos 1
 or
>Release-Note:
>Audit-Trail:
>Unformatted: