svn commit: r52158 - head/en_US.ISO8859-1/books/handbook/security

Benedict Reuschling bcr at FreeBSD.org
Sun Aug 19 11:58:49 UTC 2018


Author: bcr
Date: Sun Aug 19 11:58:47 2018
New Revision: 52158
URL: https://svnweb.freebsd.org/changeset/doc/52158

Log:
  Properly wrap overlong lines reported by textproc/igor.

Modified:
  head/en_US.ISO8859-1/books/handbook/security/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Sun Aug 19 11:58:01 2018	(r52157)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Sun Aug 19 11:58:47 2018	(r52158)
@@ -419,8 +419,8 @@ Enter new password:</screen>
 	the most prudent security or systems engineer will miss
 	something an attacker left behind.</para>
 
-      <para>A rootkit does do one thing useful for administrators: once
-	detected, it is a sign that a compromise happened at some
+      <para>A rootkit does do one thing useful for administrators:
+	once detected, it is a sign that a compromise happened at some
 	point.  But, these types of applications tend to be very well
 	hidden.  This section demonstrates a tool that can be used to
 	detect rootkits, <package>security/rkhunter</package>.</para>
@@ -2127,9 +2127,10 @@ Connection closed by foreign host.</screen>
       information on the <acronym>IPsec</acronym> subsystem in
       &os;.</para>
 
-    <para><acronym>IPsec</acronym> support is enabled by default on &os; 11 and later.
-      For previous versions of &os;, add these options to a custom kernel 
-      configuration file and rebuild the kernel using the instructions in <xref
+    <para><acronym>IPsec</acronym> support is enabled by default on
+      &os; 11 and later.  For previous versions of &os;, add
+      these options to a custom kernel configuration file and rebuild
+      the kernel using the instructions in <xref
 	linkend="kernelconfig"/>:</para>
 
     <indexterm>
@@ -3986,16 +3987,16 @@ jail:httpd:memoryuse:deny=2G/jail</programlisting>
       is no reason to provide such access to end users because tools
       exist to manage this exact requirement.</para>
 
-    <para>Up to this point, the security chapter has covered permitting
-      access to authorized users and attempting to prevent unauthorized
-      access.  Another problem arises once authorized users have access
-      to the system resources.  In many cases, some users may need
-      access to application startup scripts, or a team of
-      administrators need to maintain the system.  Traditionally, the
-      standard users and groups, file permissions, and even the
-      &man.su.1; command would manage this access.  And as applications
-      required more access, as more users needed to use system
-      resources, a better solution was required.  The most used
+    <para>Up to this point, the security chapter has covered
+      permitting access to authorized users and attempting to prevent
+      unauthorized access.  Another problem arises once authorized
+      users have access to the system resources.  In many cases, some
+      users may need access to application startup scripts, or a team
+      of administrators need to maintain the system.  Traditionally,
+      the standard users and groups, file permissions, and even the
+      &man.su.1; command would manage this access.  And as
+      applications required more access, as more users needed to use
+      system resources, a better solution was required.  The most used
       application is currently <application>Sudo</application>.</para>
 
     <para><application>Sudo</application> allows administrators
@@ -4051,8 +4052,8 @@ jail:httpd:memoryuse:deny=2G/jail</programlisting>
 
     <programlisting>%webteam   ALL=(ALL)       /usr/sbin/service webservice *</programlisting>
 
-    <para>Unlike &man.su.1;, <application>Sudo</application>
-      only requires the end user password.  This adds an advantage where
+    <para>Unlike &man.su.1;, <application>Sudo</application> only
+      requires the end user password.  This adds an advantage where
       users will not need shared passwords, a finding in most security
       audits and just bad all the way around.</para>
 
@@ -4066,13 +4067,12 @@ jail:httpd:memoryuse:deny=2G/jail</programlisting>
 
     <tip>
       <para>Most organizations are moving or have moved toward a two
-	factor authentication model.  In these cases, the user may
-	not have a password to enter.  <application>Sudo</application>
+	factor authentication model.  In these cases, the user may not
+	have a password to enter.  <application>Sudo</application>
 	provides for these cases with the <literal>NOPASSWD</literal>
-	variable.  Adding it to the configuration above
-	will allow all members of the <replaceable>webteam</replaceable>
-	group to manage the service without the password
-	requirement:</para>
+	variable.  Adding it to the configuration above will allow all
+	members of the <replaceable>webteam</replaceable> group to
+	manage the service without the password requirement:</para>
 
       <programlisting>%webteam   ALL=(ALL)       NOPASSWD: /usr/sbin/service webservice *</programlisting>
     </tip>
@@ -4098,17 +4098,17 @@ jail:httpd:memoryuse:deny=2G/jail</programlisting>
 	<para>This directory will be created automatically after the
 	  logging is configured.  It is best to let the system create
 	  directory with default permissions just to be safe.  In
-	  addition, this entry will also log administrators who use the
-	  <application>sudoreplay</application> command.  To change
-	  this behavior, read and uncomment the logging options inside
-	  <filename>sudoers</filename>.</para>
+	  addition, this entry will also log administrators who use
+	  the <application>sudoreplay</application> command.  To
+	  change this behavior, read and uncomment the logging options
+	  inside <filename>sudoers</filename>.</para>
       </tip>
 
       <para>Once this directive has been added to the
-	<filename>sudoers</filename> file, any user configuration
-	can be updated with the request to log access.  In the
-	example shown, the updated <replaceable>webteam</replaceable>
-	entry would have the following additional changes:</para>
+	<filename>sudoers</filename> file, any user configuration can
+	be updated with the request to log access.  In the example
+	shown, the updated <replaceable>webteam</replaceable> entry
+	would have the following additional changes:</para>
 
       <programlisting>%webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice *</programlisting>
 
@@ -4120,20 +4120,20 @@ jail:httpd:memoryuse:deny=2G/jail</programlisting>
 
       <screen>&prompt.root; <userinput>sudoreplay -l</userinput></screen>
 
-      <para>In the output, to replay a specific session, search for the
-	<literal>TSID=</literal> entry, and pass that to
+      <para>In the output, to replay a specific session, search for
+	the <literal>TSID=</literal> entry, and pass that to
 	<application>sudoreplay</application> with no other options to
 	replay the session at normal speed.  For example:</para>
 
       <screen>&prompt.root; <userinput>sudoreplay user1/00/00/02</userinput></screen>
 
       <warning>
-	<para>While sessions are logged, any administrator is
-	  able to remove sessions and leave only a question of why they
-	  had done so.  It is worthwhile to add a daily check
-	  through an intrusion detection system (<acronym>IDS</acronym>)
-	  or similar software so that other administrators are alerted
-	  to manual alterations.</para>
+	<para>While sessions are logged, any administrator is able to
+	  remove sessions and leave only a question of why they had
+	  done so.  It is worthwhile to add a daily check through an
+	  intrusion detection system (<acronym>IDS</acronym>) or
+	  similar software so that other administrators are alerted to
+	  manual alterations.</para>
       </warning>
 
       <para>The <command>sudoreplay</command> is extremely extendable.


More information about the svn-doc-all mailing list