Add a section on installing sudo and some basic instruction on the use
Differential Revision: D5235 Reviewed by: wblock, mat
This commit is contained in:
Tom Rhodes
parent
fff8324f5e
commit
6d8c5d7bbd
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=48670
1 changed files with 182 additions and 1 deletions
|
|
@ -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</programlisting>
|
|||
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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue