13.14.Â Shared Administration with Sudo

Contributed
by TomRhodes.

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 FreeBSD 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.

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
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 Sudo.

Sudo 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
security/sudo or by use of
the pkg(8) utility. To use the pkg(8) tool:

#pkg install sudo

After the installation is complete, the installed
visudo will open the configuration file with
a text editor. Using visudo is highly
recommended as it comes with a built in syntax checker to verify
there are no errors before the file is saved.

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
webservice. To
grant this user permission to perform these tasks, add
this line to the end of
/usr/local/etc/sudoers:

user1 ALL=(ALL) /usr/sbin/service webservice *

The user may now start webservice
using this command:

%sudo /usr/sbin/service webservice start

While this configuration allows a single user access to the
webservice 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:

Finally, this line in
/usr/local/etc/sudoers allows any
member of the webteam group to manage
webservice:

%webteam ALL=(ALL) /usr/sbin/service webservice *

Unlike su(1), Sudo
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.

Users permitted to run applications with
Sudo only enter their own passwords.
This is more secure and gives better control than su(1),
where the root
password is entered and the user acquires all
root
permissions.

Tip:

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. Sudo
provides for these cases with the NOPASSWD
variable. Adding it to the configuration above
will allow all members of the webteam
group to manage the service without the password
requirement:

%webteam ALL=(ALL) NOPASSWD: /usr/sbin/service webservice *

13.14.1.Â Logging Output

An advantage to implementing
Sudo is the ability to enable
session logging. Using the built in log mechanisms
and the included sudoreplay
command, all commands initiated through
Sudo 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 sudoreplay for
additional information.

Defaults iolog_dir=/var/log/sudo-io/%{user}

Tip:

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
sudoreplay command. To change
this behavior, read and uncomment the logging options inside
sudoers.

Once this directive has been added to the
sudoers file, any user configuration
can be updated with the request to log access. In the
example shown, the updated webteam
entry would have the following additional changes:

From this point on, all webteam
members altering the status of the
webservice application
will be logged. The list of previous and current sessions
can be displayed with:

#sudoreplay -l

In the output, to replay a specific session, search for the
TSID= entry, and pass that to
sudoreplay with no other options to
replay the session at normal speed. For example:

#sudoreplay user1/00/00/02

Warning:

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 (IDS)
or similar software so that other administrators are alerted
to manual alterations.

The sudoreplay is extremely extendable.
Consult the documentation for more information.