Sudo (su “do”) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell. Its features include:
The ability to restrict what commands a user may run on a per-host basis.
Sudo does copious logging of each command, providing a clear audit trail of who did what. When used in tandem with syslogd, the system log daemon, sudo can log all commands to a central host (as well as on the local host). At CU, all admins use sudo in lieu of a root shell to take advantage of this logging.
Sudo uses timestamp files to implement a “ticketing” system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes (this timeout is configurable at compile-time). Each subsequent sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a .logout file.
Sudo’s configuration file, the sudoers file, is setup in such a way that the same sudoers file may be used on many machines. This allows for central administration while keeping the flexibility to define a user’s privileges on a per-host basis. Please see the samples sudoers file below for a real-world example.
The sudo.conf file is used to configure the sudo front end. It specifies the security policy and I/O logging plugins, debug flags as well as plugin-agnostic path names and settings.
sudo supports a plugin architecture for security policies and input/output logging. Third parties can develop and distribute their own policy and I/O logging plugins to work seamlessly with the sudo front end. Plugins are dynamically loaded based on the contents of sudo.conf.
A Plugin line consists of the Plugin keyword, followed by the symbol_name and the path to the dynamic shared object that contains the plugin. The symbol_name is the name of the struct policy_plugin or struct io_plugin symbol contained in the plugin. The path may be fully qualified or relative. If not fully qualified, it is relative to the directory specified by the plugin_dir Path setting, which defaults to /usr/local/libexec/sudo. In other words:
Plugin sudoers_policy sudoers.so
is equivalent to:
Plugin sudoers_policy /usr/local/libexec/sudo/sudoers.so
The sudoers_file argument can be used to override the default path to the sudoers file.
The sudoers_uid argument can be used to override the default owner of the sudoers file. It should be specified as a numeric user ID.
If a user who is not listed in the policy tries to run a command via sudo, mail is sent to the proper authorities. The address used for such mail is configurable via the mailto Defaults entry (described later) and defaults to root.
Note that no mail will be sent if an unauthorized user tries to run sudo with the -l or -v option unless there is an authentication error and either the mail_always or mail_badpass flags are enabled. This allows users to determine for themselves whether or not they are allowed to use sudo. All attempts to run sudo (successful or not) will be logged, regardless of whether or not mail is sent.
sudoers uses per-user time stamp files for credential caching. Once a user has been authenticated, a record is written containing the user ID that was used to authenticate, the terminal session ID, the start time of the session leader (or parent process) and a time stamp (using a monotonic clock if one is available). The user may then use sudo without a password for a short period of time (5 minutes unless overridden by the timestamp_timeout option). By default, sudoers uses a separate record for each terminal, which means that a user’s login sessions are authenticated separately. The timestamp_type option can be used to select the type of time stamp record sudoers will use.
The sudoers file is composed of two types of entries: aliases (basically variables) and user specifications (which specify who may run what).
When multiple entries match for a user, they are applied in order. Where there are multiple matches, the last match is used (which is not necessarily the most specific match).
The sudoers file grammar will be described below in Extended Backus-Naur Form (EBNF). Don’t despair if you are unfamiliar with EBNF; it is fairly simple, and the definitions below are annotated.
By default, the env_reset option is enabled. This causes commands to be executed with a new, minimal environment.
Lists have two additional assignment operators, += and -=. These operators are used to add to and delete from a list respectively. It is not an error to use the -= operator to remove an element that does not exist in a list.
35 Defaults env_reset
36 Defaults env_keep += "BLOCKSIZE"
37 Defaults env_keep += "COLORFGBG COLORTERM"
38 Defaults env_keep += "__CF_USER_TEXT_ENCODING"
39 Defaults env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE"
40 Defaults env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
41 Defaults env_keep += "LINES COLUMNS"
42 Defaults env_keep += "LSCOLORS"
43 Defaults env_keep += "SSH_AUTH_SOCK"
44 Defaults env_keep += "TZ"
45 Defaults env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
46 Defaults env_keep += "EDITOR VISUAL"
47 Defaults env_keep += "HOME MAIL"
49 Defaults lecture_file = "/etc/sudo_lecture"
This option controls when a short lecture will be printed along with the password prompt. It has the following possible values:
Always lecture the user.
Never lecture the user.
Only lecture the user the first time they run sudo.
If no value is specified, a value of once is implied. Negating the option results in a value of never being used. The default value is once.
A fundamental and very powerful, consistent abstraction provided in UNIX and compatible operating systems is the file abstraction. Many OS services and device interfaces are implemented to provide a file or file system metaphor to applications.
# Alternatively, gpasswd may be used. Though the username can only be added (or removed) from one group at a time:
$ groups user
# usermod -s /bin/bash username