svn commit: r48670 - head/en_US.ISO8859-1/books/handbook/security
Tom Rhodes <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
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>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"