Page Menu
Home
FreeBSD
Search
Configure Global Search
Log In
Files
F153210278
D5235.id13684.diff
No One
Temporary
Actions
View File
Edit File
Delete File
View Transforms
Subscribe
Mute Notifications
Flag For Later
Award Token
Size
8 KB
Referenced Files
None
Subscribers
None
D5235.id13684.diff
View Options
Index: en_US.ISO8859-1/books/handbook/security/chapter.xml
===================================================================
--- en_US.ISO8859-1/books/handbook/security/chapter.xml
+++ en_US.ISO8859-1/books/handbook/security/chapter.xml
@@ -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,183 @@
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>The <application>Sudo</application> 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
+ or by use of the &man.pkg.8; tool. 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>/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>/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>/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>
File Metadata
Details
Attached
Mime Type
text/plain
Expires
Mon, Apr 20, 8:10 PM (11 h, 41 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
31861796
Default Alt Text
D5235.id13684.diff (8 KB)
Attached To
Mode
D5235: Add a section on sudo.
Attached
Detach File
Event Timeline
Log In to Comment