Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Apr 2016 18:10:51 +0000 (UTC)
From:      Tom Rhodes <trhodes@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r48670 - head/en_US.ISO8859-1/books/handbook/security
Message-ID:  <201604181810.u3IIAp2I058415@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: trhodes
Date: Mon Apr 18 18:10:51 2016
New Revision: 48670
URL: https://svnweb.freebsd.org/changeset/doc/48670

Log:
  Add a section on installing sudo and some basic instruction on the use
  
  Differential Revision:	D5235
  Reviewed by:	wblock, mat

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	Mon Apr 18 17:42:15 2016	(r48669)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Mon Apr 18 18:10:51 2016	(r48670)
@@ -201,7 +201,7 @@
 	attempt to login.</para>
     </sect2>
 
-    <sect2 xml:id="security-sudo">
+    <sect2 xml:id="security-accountmgmt">
       <title>Permitted Account Escalation</title>
 
       <para>In some cases, system administration needs to be shared
@@ -3935,4 +3935,185 @@ jail:httpd:memoryuse:deny=2G/jail</progr
 	See &man.rctl.8; to learn about them.</para>
     </sect2>
   </sect1>
+
+  <sect1 xml:id="security-sudo">
+    <info>
+      <title>Shared Administration with Sudo</title>
+
+      <authorgroup>
+	<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Contributed
+	  by </contrib></author>
+      </authorgroup>
+    </info>
+
+    <indexterm>
+      <primary>Security</primary>
+      <secondary>Sudo</secondary>
+    </indexterm>
+
+    <para>System administrators often need the ability to grant
+      enhanced permissions to users so they may perform privileged
+      tasks.  The idea that team members are provided access
+      to a &os; system to perform their specific tasks opens up unique
+      challenges to every administrator.  These team members only
+      need a subset of access beyond normal end user levels; however,
+      they almost always tell management they are unable to
+      perform their tasks without superuser access.  Thankfully, there
+      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
+      application is currently <application>Sudo</application>.</para>
+
+    <para><application>Sudo</application> allows administrators
+      to configure more rigid access to system commands
+      and provide for some advanced logging features.
+      As a tool, it is available from the Ports Collection as
+      <package role="port">security/sudo</package> or by use of
+      the &man.pkg.8; utility.  To use the &man.pkg.8; tool:</para>
+
+    <screen>&prompt.root; <userinput>pkg install sudo</userinput></screen>
+
+    <para>After the installation is complete, the installed
+      <command>visudo</command> will open the configuration file with
+      a text editor.  Using <command>visudo</command> is highly
+      recommended as it comes with a built in syntax checker to verify
+      there are no errors before the file is saved.</para>
+
+    <para>The configuration file is made up of several small sections
+      which allow for extensive configuration.  In the following
+      example, web application maintainer, user1, needs to start,
+      stop, and restart the web application known as
+      <replaceable>webservice</replaceable>.  To
+      grant this user permission to perform these tasks, add
+      this line to the end of
+      <filename>/usr/local/etc/sudoers</filename>:</para>
+
+    <programlisting>user1   ALL=(ALL)       /usr/sbin/service webservice *</programlisting>
+
+    <para>The user may now start <replaceable>webservice</replaceable>
+      using this command:</para>
+
+    <screen>&prompt.user; <userinput>sudo /usr/sbin/service <replaceable>webservice</replaceable> start</userinput></screen>
+
+    <para>While this configuration allows a single user access to the
+      <application>webservice</application> service; however, in most
+      organizations, there is an entire web team in charge of managing
+      the service.  A single line can also give access to an entire
+      group.  These steps will create a web group, add a user to this
+      group, and allow all members of the group to manage the
+      service:</para>
+
+    <screen>&prompt.root; <userinput>pw groupadd -g 6001 -n webteam</userinput></screen>
+
+    <para>Using the same &man.pw.8; command, the user is added to
+      the webteam group:</para>
+
+    <screen>&prompt.root; <userinput>pw groupmod -m user1 -n webteam</userinput></screen>
+
+    <para>Finally, this line in
+      <filename>/usr/local/etc/sudoers</filename> allows any
+      member of the webteam group to manage
+      <replaceable>webservice</replaceable>:</para>
+
+    <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
+      users will not need shared passwords, a finding in most security
+      audits and just bad all the way around.</para>
+
+    <para>Users permitted to run applications with
+      <application>Sudo</application> only enter their own passwords.
+      This is more secure and gives better control than &man.su.1;,
+      where the <systemitem class="username">root</systemitem>
+      password is entered and the user acquires all
+      <systemitem class="username">root</systemitem>
+      permissions.</para>
+
+    <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>
+	provides for these cases with the <literal>NOPASSWORD</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>
+
+      <programlisting>%webteam   ALL=(ALL)       NOPASSWORD: /usr/sbin/service webservice *</programlisting>
+    </tip>
+
+    <sect2 xml:id="security-sudo-loggin">
+      <title>Logging Output</title>
+
+      <para>An advantage to implementing
+	<application>Sudo</application> is the ability to enable
+	session logging.  Using the built in log mechanisms
+	and the included <application>sudoreplay</application>
+	command, all commands initiated through
+	<application>Sudo</application> are logged for later
+	verification.  To enable this feature, add a default log
+	directory entry, this example uses a user variable.
+	Several other log filename conventions exist, consult the
+	manual page for <application>sudoreplay</application> for
+	additional information.</para>
+
+      <programlisting>Defaults iolog_dir=/var/log/sudo-io/%{user}</programlisting>
+
+      <tip>
+	<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>
+      </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>
+
+      <programlisting>%webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice *</programlisting>
+
+      <para>From this point on, all <replaceable>webteam</replaceable>
+	members altering the status of the
+	<replaceable>webservice</replaceable> application
+	will be logged.  The list of previous and current sessions
+	can be displayed with:</para>
+
+      <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
+	<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>
+      </warning>
+
+      <para>The <command>sudoreplay</command> is extremely extendable.
+	Consult the documentation for more information.</para>
+    </sect2>
+  </sect1>
 </chapter>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201604181810.u3IIAp2I058415>