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>