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
grant this user permission to perform these tasks, add
this line to the end of
user1 ALL=(ALL) /usr/sbin/service webservice *
The user may now start
using this command:
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:
pw groupadd -g 6001 -n webteam
Using the same pw(8) command, the user is added to the webteam group:
pw groupmod -m user1 -n webteam
Finally, this line in
/usr/local/etc/sudoers allows any
member of the webteam group to manage
%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),
password is entered and the user acquires all
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
variable. Adding it to the configuration above
will allow all members of the
group to manage the service without the password
%webteam ALL=(ALL) NOPASSWD: /usr/sbin/service webservice *
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.
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
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
entry would have the following additional changes:
%webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice *
From this point on, all
members altering the status of the
will be logged. The list of previous and current sessions
can be displayed with:
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:
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.
sudoreplay is extremely extendable.
Consult the documentation for more information.