Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Unix Sudo (superuser do)

Sudo (superuser do) allows a system administrator to work using his own account and switch to root or other user identity available on the system only for commands that need it. It also provide a better logging and "ticketing" system. Sudo is useful on all version and flavors of Unix, with possible exception of  Solaris 10 and later because native OS mechanisms (RBAC) are superior. 

Sudo is integrated in OpenBSD. Sudo is pre-installed on all enterprise linux distributions. So on linux it is unwise not to use it. It is portable and in enterprise environment can be easily deployed on all Unix systems. Ubuntu goes one step further here. By default, the root account password is locked in Ubuntu. This means that you cannot login as root directly or use the su command to become the root user, however, since the root account physically exists it is still possible to run programs with root-level privileges.

The advantage is simplification of delegation of root which in enterprise environment usually is accomplished by changing root password to some king of temp password and communication it to the particular person. This change can cause some grief as you need to remember which system are converted and which are not.

If sudo is installed sysadmin can just enroll person into wheel group to provide access to root and delete it from the group without communicating anything. Deletion can be done automatically when the period expires using at command. In out current environment that requires human action of resetting password back.

There is also an audit trail in sudo log. That can help in troubleshooting if there are multiple cooks in the kitchen.

Communication of temp root password means that theoretically an intelligent person can access root account on any of the systems that currently are converted for temp root. In case of sudo this is just one system.

Another positive side effect is that members of wheel group do not need additional authentication to became root. That saves time and troubles if you need to administer multiple systems.

Again I would like to stress that one of the most productive way of using Sudo or non-BSD Unixes is to imitate BSD wheel group, the group membership in which gives the user possibility to execute su root. 

Sudo is distributed under a BSD-style license and currently maintained by Todd Miller. The current homepage is http://www.courtesan.com/sudo/ 

Conceptually sudo is really  simple package and it consist of  just two utilities (sudo and visudo) and a single configuration file (usually /etc/sudoers):

1. sudo(8) command: setuid root wrapper that users invoke to execute commands as root (or other privileged account).
2. /etc/sudoers. This file which is usually located in /etc/sudo or /usr/local/etc directory, is sudo's permissions table, saying who may run what commands as which user, and is fully documented in sudoers(5).
3. visudo(8) command allows administrators to edit the sudoers file without risking locking themselves out of the system.

Sudo is mainly useful for sysadmins and can prevent some really horrible things that often happen when you work as root and do something in a hurry. And that's probably the best part of its usefulness. It also saves time as it permit to execute single command as root without authentication (if configured this way). This is security vulnerability from one point of view but big productivity feature in the other. If passwords for regular accounts are one time (like in case of SecurID) this is a very attractive solution. 

Like in any complex security program the security record of sudo itself is questionable and there were several vulnerabilities in different versions; also like with many other open source programs, it looks like there is not much development discipline: capability of the program grows non-stop without much architectural vision, evaluation of the return on the investment and general security of code. As a result the current version is far from being a simple elegant tool it used to be.  It has just to many mostly useless options, keys etc. Some recent enhancements probably were not necessary and just increased the complexity of the codebase.

Contrary to common perception sudo does not really provide for a role structuring facility similar to RBAC: any assignment of a capability to execute a complex command with variable arguments (for example find) with root privileges essentially means conversion of the account into synonym of root account.

From this point of view this capability of granting command access is most useful for providing a "read-only" and "re-write"  assess to some root owned files by granting usage of explicit cat (or cp in case of re-write access) commands for selected files, or commands with explicit arguments. But even this is dangerous and this privilege can be abused. to modify the file the user needs first to save it in his own directory and then execute move to target destination command.  

One needs clearly understand that granting a user the right to run any command  like "vi"  or "find" as root is equivalent to granting root access.  Actually granting the right to execute any command with root privileges without strict control of arguments is dangerous.

Restricting execution capabilities of regular user account is mostly useless: the problem is not excessive capabilities of regular account, but the lack of thereof.  But it does make sense for applications. Applications are a different beast and here sudo can and should be useful if you cannot use restricted shell, chroot or similar things:

Defaults syslog_goodpri=alert

# Cmnd alias specification
Cmnd_Alias DNS = /var/dss/vinamed.boot, /var/dss/vidb.root, /usr/bin/kill - HUP *
Cmnd_Alias MAILCMDS = /usr/local/bin/aliases, /usr/local/bin/qlist, /usr/local/bin/qlist2, /usr/local/bin/qreport, /usr/local/bin/qreport2, /usr/local/bin/qdelete, /usr/local/bin/qdelete2, /etc/rc3.d/S88sendmail
Cmnd_Alias MONITORCMDS = /etc/rc3.d/S88sendmail, /usr/bin/su - pmx4 *

MAIL ALL= MAILCMDS
monitor ALL=(ALL) NOPASSWD: MONITORCMDS

As I mentioned before the first really elegant sudoer configuration is as simple as:

 %wheel         ALL = (ALL) ALL

where the wheel group consist of all administrators. In this case anytime sysadmins need to execute command as root he/she just prefix it with sudo. This is actually an imitation of the BSD wheel group functionality and what is really nice that it can be accomplished on any flavor of Unix although a  PAM-based implementation is better on those systems were it is available (Solaris, Linux). In Solaris this is useful only for compatibility in multi-Unix enterprise environment and the group used probably should be not the wheel group but sysadmin group. The latter  has additional capabilities not dissimilar to BSD wheel group (in Solaris this is the ability to change attributes of files via Admintool). 

    %sysadmin      ALL = (ALL) ALL

 %operator      ALL = NOPASSWD: /usr/bin/su operator

Actually this part of sudo functionality can be easily implemented without sudo using additional copy of  /bin/sh (sudo can used as the name of the copy) with permissions 4550  and owned by root:wheel or in Solaris root:sysadmin.  It provides probably 80% of sudo usefulness in preventing root role "overstaying" for administrators with access to the root role (assuming that all of them are members of the group wheel or sysadmin). This solution lacks logging and other nice features provided by sudo, but it does avoid sudo overcomplexity.  In certain cases when adding software to the server is prohibited, it can serve as a "poor man sudo"  and it might help to avoid risks connected with root role "overstaying" as well as potential security holes inherent in the current version of sudo with all its complexity.

Here are some additional examples from the sudo manual:

Since the sudoers file is parsed in a single pass, order is important. In general, you should structure sudoers such that the Host_Alias, User_Alias, and Cmnd_Alias specifications come first, followed by any Default_Entry lines, and finally the Runas_Alias and user specifications. The basic rule of thumb is you cannot reference an Alias that has not already been defined.

Below are example sudoers entries. Admittedly, some of these are a bit contrived. First, we define our aliases:

 User_Alias     FULLTIMERS = millert, mikef, dowdy
 User_Alias     PARTTIMERS = bostley, jwfox, crawl
 User_Alias     WEBMASTERS = will, wendy, wim

 Runas_Alias    OP = root, operator
 Runas_Alias    DB = oracle, sybase

 Host_Alias     SPARC = bigtime, eclipse, moet, anchor :\
                SGI = grolsch, dandelion, black :\
                ALPHA = widget, thalamus, foobar :\
                HPPA = boa, nag, python
 Host_Alias     CUNETS = 128.138.0.0/255.255.0.0
 Host_Alias     CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0
 Host_Alias     SERVERS = master, mail, www, ns
 Host_Alias     CDROM = orion, perseus, hercules

 Cmnd_Alias     DUMPS = /usr/bin/mt, /usr/sbin/dump, /usr/sbin/rdump,\
                        /usr/sbin/restore, /usr/sbin/rrestore
 Cmnd_Alias     KILL = /usr/bin/kill
 Cmnd_Alias     PRINTING = /usr/sbin/lpc, /usr/bin/lprm
 Cmnd_Alias     SHUTDOWN = /usr/sbin/shutdown
 Cmnd_Alias     HALT = /usr/sbin/halt
 Cmnd_Alias     REBOOT = /usr/sbin/reboot
 Cmnd_Alias     SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \
                         /usr/local/bin/tcsh, /usr/bin/rsh, \
                         /usr/local/bin/zsh
 Cmnd_Alias     SU = /usr/bin/su
 Cmnd_Alias     PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less

Here we override some of the compiled in default values. We want sudo to log via syslog(3) using the auth facility in all cases. We don't want to subject the full time staff to the sudo lecture, user millert need not give a password, and we don't want to reset the LOGNAME, USER or USERNAME environment variables when running commands as root. Additionally, on the machines in the SERVERS Host_Alias, we keep an additional local log file and make sure we log the year in each log line since the log entries will be kept around for several years. Lastly, we disable shell escapes for the commands in the PAGERS Cmnd_Alias (/usr/bin/more, /usr/bin/pg and /usr/bin/less).

 Defaults               syslog=auth
 Defaults>root          !set_logname
 Defaults:FULLTIMERS    !lecture
 Defaults:millert       !authenticate
 Defaults@SERVERS       log_year, logfile=/var/log/sudo.log
 Defaults!PAGERS        noexec

The User specification is the part that actually determines who may run what.

 root           ALL = (ALL) ALL
 %wheel         ALL = (ALL) ALL

We let root and any user in group wheel run any command on any host as any user.

 FULLTIMERS     ALL = NOPASSWD: ALL

Full time sysadmins (millert, mikef, and dowdy) may run any command on any host without authenticating themselves.

 PARTTIMERS     ALL = ALL

Part time sysadmins (bostley, jwfox, and crawl) may run any command on any host but they must authenticate themselves first (since the entry lacks the NOPASSWD tag).

 jack           CSNETS = ALL

The user jack may run any command on the machines in the CSNETS alias (the networks 128.138.243.0, 128.138.204.0, and 128.138.242.0). Of those networks, only 128.138.204.0 has an explicit netmask (in CIDR notation) indicating it is a class C network. For the other networks in CSNETS, the local machine's netmask will be used during matching.

 lisa           CUNETS = ALL

The user lisa may run any command on any host in the CUNETS alias (the class B network 128.138.0.0).

 operator       ALL = DUMPS, KILL, SHUTDOWN, HALT, REBOOT, PRINTING,\
                sudoedit /etc/printcap, /usr/oper/bin/

The operator user may run commands limited to simple maintenance. Here, those are commands related to backups, killing processes, the printing system, shutting down the system, and any commands in the directory /usr/oper/bin.

 joe            ALL = /usr/bin/su operator

The user joe may only su(1) to operator.

 pete           HPPA = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root

The user pete is allowed to change anyone's password except for root on the HPPA machines. Note that this assumes passwd(1) does not take multiple usernames on the command line.

 bob            SPARC = (OP) ALL : SGI = (OP) ALL

The user bob may run anything on the SPARC and SGI machines as any user listed in the OP Runas_Alias (root and operator).

 jim            +biglab = ALL

The user jim may run any command on machines in the biglab netgroup. sudo knows that ``biglab'' is a netgroup due to the '+' prefix.

 +secretaries   ALL = PRINTING, /usr/bin/adduser, /usr/bin/rmuser

Users in the secretaries netgroup need to help manage the printers as well as add and remove users, so they are allowed to run those commands on all machines.

 fred           ALL = (DB) NOPASSWD: ALL

The user fred can run commands as any user in the DB Runas_Alias (oracle or sybase) without giving a password.

 john           ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*

On the ALPHA machines, user john may su to anyone except root but he is not allowed to give su(1) any flags.

 jen            ALL, !SERVERS = ALL

The user jen may run any command on any machine except for those in the SERVERS Host_Alias (master, mail, www and ns).

 jill           SERVERS = /usr/bin/, !SU, !SHELLS

For any machine in the SERVERS Host_Alias, jill may run any commands in the directory /usr/bin except for those commands belonging to the SU and SHELLS Cmnd_Aliases.

 steve          CSNETS = (operator) /usr/local/op_commands/

The user steve may run any command in the directory /usr/local/op_commands/ but only as user operator.

 matt           valkyrie = KILL

On his personal workstation, valkyrie, matt needs to be able to kill hung processes.

 WEBMASTERS     www = (www) ALL, (root) /usr/bin/su www

On the host www, any user in the WEBMASTERS User_Alias (will, wendy, and wim), may run any command as user www (which owns the web pages) or simply su(1) to www.

 ALL            CDROM = NOPASSWD: /sbin/umount /CDROM,\
                /sbin/mount -o nosuid\,nodev /dev/cd0a /CDROM

Any user may mount or unmount a CD-ROM on the machines in the CDROM Host_Alias (orion, perseus, hercules) without entering a password. This is a bit tedious for users to type, so it is a prime candidate for encapsulating in a shell script.

Another useful feature of sudo that it does logging of each command, providing a clear audit trail of "who did what."  When used in tandem with remote syslogd, sudo can log all commands to a central loghost (as well as on the local host).

The third potentially useful feature of sudo is its "time 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 gives some level of protection in situation where there is a danger of  accidentally leaving a root shell where others can physically get to your keyboard.

Some points for the large enterprise environment the advantages of deploying SUDO (based on article: Sudo at a VERY LARGE site) are as following:

• Unlike RBAC, sudo is portable and supports just about every UNIX flavor out there. Compiles pretty much out of the box (but read the docs!)
• rdist can be used used to push executables /etc/sudoers across all servers
• SCCS can used to track changes to sudoers
• Here is the sudoers file we currently use
• Access to root account without need to know root password
• NOPASSWD option is useful for batch processes and applications.  
• Better logging is  real help. Logs on each machine ... and then send to central log. Modify your syslog.conf as appropriate. Sudo audit logs quite handy (who/what happened/changed?).
• Several audit/analysis tools available from sudo community
• Some stats:
  • 18,916 sudo (root type) actions in DOMAIN for the month of March/1997
  • 2,813 on HOST1, 1,226 on HOST2, 594 on HOST3, etc.
  • 1,250 for SA1, 1080 for SA2, 892 for Alek, etc.
  • 261 "su root`s" ... necessary at times, but still too many IMHO (What did they do?)
• To get a good idea of what sudo can do, you really need to take a look at a sample sudoers file.

Here is a brief history of Sudo

A Brief history of sudo(8):

Sudo was first conceived and implemented by Bob Coggeshall and Cliff
Spencer around 1980 at the Department of Computer Science at
SUNY/Buffalo.  It ran on a VAX-11/750 running 4.1BSD.  An updated
version, credited to Phil Betchel, Cliff Spencer, Gretchen Phillips,
John LoVerso and Don Gworek, was posted to the net.sources newsgroup
in December of 1985.

In the Summer of 1986, Garth Snyder released and enhanced version
of sudo. For the next 5 years, sudo was fed and watered by a handful
of folks at CU-Boulder, including Bob Coggeshall, Bob Manchek, and
Trent Hein.

In 1991, Dave Hieb and Jeff Nieusma wrote a new version of sudo
with an enhanced sudoers format under contract to a consulting firm
called "The Root Group".  This version was later released under the
GNU public license.

In 1994, after maintaining sudo informally within CU-Boulder for
some time, Todd Miller made a public release of "CU sudo" (version
1.3) with bug fixes and support for more operating systems.  The
"CU" was added to differentiate it from the "official" version from
"The Root Group".

In 1996, Todd, who had been maintaining sudo for several years in
his spare time, brought sudo development under the umbrella of his
consulting firm, Courtesan Consulting.  Courtesan remains committed
to a free sudo and is sponsoring another sudo rewrite as well as
continued development of the sudo 1.x code base.

In 1999, the "CU" prefix was dropped from the name since there has
been no formal release of sudo from "The Root Group" since 1991
(the original authors now work elsewhere).  As of version 1.6, Sudo
no longer contains any of the original "Root Group" code and is
available with a BSD-style license.

In 2004, Todd incorporated as GratiSoft, Inc. to provide commercial
support and enhancements to the sudo community.  Please visit
http://www.sudo.ws/sudo/support.html for information on commerical
support.

sudo, in its current form, is maintained by:

	Todd Miller <Todd.Miller@courtesan.com>

Todd continues to enhance sudo and fix bugs.

Notes: Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected. This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books. The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link. Search Amazon by keywords:     Open directory Research Index

Old News ;-)

[Feb 19, 2008] Linux.com sudo, or not sudo that is the question

The format of the sudoers file is simple: it starts with four optional sections, and it ends with the specific rights assignments. It can include empty lines, or comment lines that start with the # sign. The optional sections are:

• User Alias: Specifies an alias for a single user (not very useful) or a set of users. A user can appear in several aliases.
• "Run as" Alias: Specifies which other user(s) the sudo user will be able to work as. By default, sudo implies root, but you might want to run as another user.
• Host Alias: Specifies the hosts that the rights apply to. You won't be using this unless you're doing sysadmin jobs for a group of several Linux boxes. You would have to rsync the file to the other hosts, or use something like Network Information Service (NIS) to provide access to the file.
• Command Alias: Specifies a synonym for a specific command. For instance, it's easier to type APT than a fully qualified absolute path such as /usr/sbin/apt-get.

You don't need to use aliases, but they do make future editing easier. For example, if you have to assign donald_duck the same rights that mickey_mouse has, just add the former to the latter's group, and you won't have to spend lots of time duplicating lines everywhere. A special alias called ALL exists, and you can use it anywhere; it can mean ALL users, ALL hosts, and so on.

After these sections, you must have a section for specific rights, which looks like "who where = (whoelse) what," meaning who (a user, a group, or a user alias) on the host where can run a command what as a user whoelse. (If this is too cryptic, look at the following example.) You can also include several specific options, such as NOPASSWD to allow a user to sudo without entering his password; check the manual for the other options.

This sample doesn't show every configuration possible (for that, you should do man sudoers), but here's what a sample file with some of these options might look like:

#
# Sample /etc/sudoers file, with apologies to the Disney company!
#

# User aliases
# The first line creates an alias for three specific users.
# The second one includes everybody in the "ducks" user group, but excludes "donald"
# The third one creates an alias for just one user; it can be useful in the future!
#
User_Alias	NEPHEWS = huey, dewey, louie
User_Alias	ALL_DUCKS_BUT_DONALD = %ducks, !donald
User_Alias	MICKEY = mickey_mouse

# Command aliases

Cmnd_Alias      HALT_OR_REBOOT = /sbin/halt
Cmnd_Alias      KILL = /usr/bin/killall
Cmnd_Alias      SHUTDOWN = /sbin/shutdown
Cmnd_Alias      SU = /bin/su

# The rights: who gets to run what

# A standard rule: root, and users in group "wheel", have full rights
root            ALL = (ALL) ALL
%wheel          ALL = (ALL) ALL

# Suppose mickey is an sysadmin; let him run anything without a password
MICKEY		ALL = NOPASSWD: ALL

# NEPHEWS can stop the box if they want
NEPHEWS		HALT_OR_REBOOT, SHUTDOWN
																					

You can also add some extra configuration lines at the end of the configuration file. You can specify, for example:

• Whether emails should be sent for wrong passwords or unallowed attempts to use sudo
• How many login attempts to allow before exiting
• Whether the user should get a short lecture about the risks involved in using sudo
• A log file specific to sudo, where all commands will be logged

[Jan 30, 2008] polishlinux.org » Sudo FAQ

The syntax of /etc/sudoers.
The basic syntax of /etc/sudoers file looks like this:

user computer = command

In short, it means that the user logged into computer can run the command with administrative privileges. Here is an example:

johnny localhost = /usr/bin/du

This means that johnny will be able to use du (disk usage) command on localhost (the current computer).
Warning: if the computer name has been change, a real name (not localhost) needs to be entered..

2.b. Granting users of group XXX the right to execute the command YYY:
% XXX localhost = /the/path/to/command/YYY

2.c. Allow to execute many command in one rule:
johnny localhost = /usr/bin/du, /usr/bin/nail, /usr/bin/sane

[Jan 30, 2008] sudo-tools sudolog-usage and sudoers-lint

• sudolog-usage: Slices/dices the sudolog (syslog output from sudo) better than a Ron-ko-Matic from K-tel and summarizes who used sudo on what hosts.
• sudoers-lint: Slices/dices the sudoers files in various ways so you can see if any "cruff" has accumulated in there and/or "orphaned" entries.

Here's the tarball for sudo-tools-1.2 (2003_12_15) ... basically just two Perl scripts ... VERY simple to install/configure/run ...

See also UNIX Sysadmin Tools and Alek's free personal home pages

[Jan 30, 2008] Sudo at a VERY LARGE site

• Some notes about the UNIX Environment
• Why do you need something like sudo?
• Getting/Configuring sudo
• Misc. "Tricks" for Large Heterogeneous Networks
• Controlling Access
• Using Sudo
• Logging/Audit Trail
• How well does Sudo actually work?
• Other sudo-like Utilities
• Misc. issues/concerns
• Future needs/work with Sudo
• Summary

[Jan 30, 2008] ONLamp.com Eliminating Root with Sudo

While proper implementation of groups can help reduce the need for the root password, at times, users must absolutely run commands as another user (usually root). As the system administrator, you're stuck between deciding to hand out the root password or doing everything for your users. sudo provides a third way, one that can help solve this dilemma. It's a tricky program, however, and needs some care in implementation. sudo is integrated into OpenBSD, and is an add-on package for just about every other Unix-like operating system out there.

sudo is a setuid root wrapper that implements fine-grained access control for commands that need to be run as root. It takes the command you want to run and compares it to its internal list of permissions. If sudo's permissions allow that particular user to run that command, sudo runs that command for you, with its privileges. As root can run commands as any user, sudo can execute commands as any arbitrary system user.

With proper setup, the system administrator can allow any user to run any command as any other user. sudo is a very powerful tool, and can be configured to allow or deny almost any set of commands. As a result of this flexibility, the documentation tends to scare off new users. We're going to do a basic sudo setup that will cover almost all uses, but you should be aware that many more combinations are possible, and are documented in sudo(8) and sudoers(5).

Other than the obvious fine-grained access control sudo provides, there are a few other benefits to using sudo. One of the biggest advantages is the command logging. Every sudo command is logged, making it very easy to track who made what changes. And once you have sudo configured correctly, you can change the root password and not give it to anyone. Nobody should need the root password if they have the correct sudo permissions, after all! Reducing the number of people who have the root password can help improve security. Finally, a single sudo configuration file can be used on all of these systems, vastly easing administrator overhead.

The most overwhelmingly common disadvantage to sudo is that users and junior administrators don't like it. If people have traditionally had root access on a system, they will perceive that they're losing something when you implement sudo. They key to overcoming this is to make sure that people have the ability to do their jobs. If users think that they need the root password to perform other tasks, then your need to settle just who is responsible for what. These users may have been taking extra duties upon themselves, rather than troubling you with jobs that you should do.

A faulty sudo setup can create security holes. A thoughtless configuration will create holes in the system that a clever user can use to actually become root. This problem is best dealt with by a combination of careful configuration and administrative policy.

[Jan 30, 2008] Linux Tips Password usage in sudo (PASSWD - NOPASSWD) MDLog-sysadmin

NOPASSWD option is useful for temporary granting a specific user access to root: you enroll him to the wheel group and submit at command that deletes him from this group at the end of the specified period. This way you do not need to communicate the password to the user at all and thus do not need change it back after the period for which the user was granted tem root access expire...

[Oct 27, 2007]  sudo-tools sudolog-usage and sudoers-lint

• sudolog-usage: Slices/dices the sudolog (syslog output from sudo) better than a Ron-ko-Matic from K-tel and summarizes who used sudo on what hosts.
• sudoers-lint: Slices/dices the sudoers files in various ways so you can see if any "cruff" has accumulated in there and/or "orphaned" entries.

Here's the tarball for sudo-tools-1.2 (2003_12_15) ... basically just two Perl scripts ... VERY simple to install/configure/run ...

[Oct 27, 2007]  RootSudo - Community Ubuntu Documentation

[Oct 27, 2007] polishlinux.org » Sudo FAQ

Sudo is a simple program which allows the administrator to give regular users extra permissions to execute the commands they would normally not be allowed to use. Thanks to sudo, we can execute commands that are usually restricted to the root account. In practice, it looks like that: instead of typing su ->password -> command you type sudo command. In order to use sudo you need to configure it properly. This FAQ is supposed to help you with this task.

[Oct 27, 2007] Sudoers Manual

[Oct 27, 2007] Sudo Main Page

The current stable version is sudo 1.6.9p7, released on October 25, 2007.

RBAC on Solaris: emulation of SUDO

Role-based access control allows system administrators to delegate the administrative control of parts of the system to users. Users can be given the ability to run commands with additional privilege in two ways. Either by assigning a profile directly to the user, in which case no additional authentication is required. Or by creating a role. It can also be used to build restrictive environments for users by removing their ability to run commands they would normally be allowed to.

OpenSolaris UserGroup RBAC presenation

Why use RBAC vs sudo (for Solaris)

(Note this may not apply to all OpenSolaris distributions)

• RBAC is built into Solaris (since S8) and supported by Sun.
• RBAC is documented, patched, updated and integrated throughout Solaris
• RBAC is supported by the Solaris Management Console and WebMin GUI's
• RBAC is integrated with SMF in Solaris 10.
• RBAC is evaluated along with the rest of the OS during Common Criteria evaluations. Sudo is not included in the evaluation.
• RBAC actions are audited by the same CC evaluated audit facility used through Solaris
• RBAC offers roles as well as the pfexec command which provides a similar capability to sudo.

Why use sudo rather than RBAC

• Cross platform
• Support for control of CLI arguments (see TODO list below)
• Support for setting per command environment (see TODO list below)

What about sudo & privileges ?

Having sudo be privilege aware would be great for OpenSolaris as well. This would probably be done by adding new keywords to the sudoers grammar so that you can specify the privileges that the command should run with. It would be very cool if someone could implement this and contribute it back to the main sudo branch.

RBAC Best Practices for OpenSolaris developers

The following best practice documents for using RBAC in developing other parts of OpenSolaris can be found in the ARC community:

• When to use setuid vs RBAC roles

• Adding New authorisations to OpenSolaris

• Bulding RBAC Rights Profiles

RBAC TODO List

The following is a list of mini projects or RFEs that we know we need to implement in the OpenSolaris RBAC framework to get parity with sudo or to fill a customer need.

Please help us out by implementing one of these:

• Control of environment variables: 6227888

Ability to set and clear any environment variable for a specific entry in exec_attr(4).

• Control of command line args: 5097247

Restrict which arguments to a command get the additional privilege, For example run passwd(1) but only with a user name not with any of the password aging options.

• Netgroups integration 4986798

For all of the RBAC databases that make up a profile definition and assignment of it to a user (execattr, profattr, userattr) control which hosts it is valid on using netgroups. The currently unused "qualifier" field in userattr(4) is intended for this as is one of the reserved fields in prof_attr(4).

History of RBAC in Solaris

The main stream Solaris first got RBAC in Solaris 8. In Solaris 9 new profiles were added but no new core functionality from the framework. In Solaris 10 RBAC was integrated with least privilege, SMF and SMC.

Trusted Solaris (now replaced by Trusted Extensions) had an RBAC system in all of its releases going back to the SunOS 4.1.3 based versions. The implementation was slightly different but the basic concepts are the same.

Sys Admin Magazine RBAC instead of sudo

SUMMARY sudo vs RBAC

Ximo Domenech ximo_d at yahoo.com
Thu Nov 6 06:43:17 EST 2003

• Previous message: summary : I can't connect my e250
• Next message: SUMMARY: whats the best place to share a script : network config
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

Hi,

Original question was a comparation between sudo and RBAC. See the summary below:

Thanks to,

Kanellopoulos Angelos
Mike Salehi 
ed at the7thbeer.com
Jeremy S. Loukinas 
Colin Bigam
Alan Pae

-----

RBAC Advantages:

-Built in to Solaris 9
-Possibility to configure with gui (Sun Management
Console)
-Very flexible
-Integrated into the Solaris authentication mechanism
-Supported by Sun

RBAC Cons:

-More complex to configure 
-Roles and rights not clearly defined
-Not as granular as sudo

Sudo Advantages:

- Easier to configure
- Small, lightweight
- No massive GUI needed to configure
- Very very granular
- Superior logging

Sudo Disadvantages:

- No ability to 'become' a role as with RBAC
- Have to define each and every command so setup takes
longer
- Need to compile and install
- Not integrated into the Solaris authentication
mechanism, acts like a 'shell' on top of the services.
- Not supported by Sun

In a few words, RBAC looks a good choice for a broad environment and one central privilege granting
system, and sudo is better to set up pseudo root access in smaller environments.

The size of your environment and your requirements will determine which is the better tool.

[Mar14, 2001] There is a security flaw in older versions that was recently fixed. CERT is recommending to upgrade to 1.6.3p7. See  Sudo News

• Sudo version 1.6.3p7 was released on Mar 2, 2001. This fixes the negating of path-type Defaults entries in a boolean context.
• Sudo version 1.6.3p6 was released on Feb 19, 2001. This fixes a potential security problem. So far, the bug does not appear to be exploitable.
• Sudo version 1.6.3p5 was released on Aug 13, 2000. This fixes the listpw and verifypw sudoers options.

Recommended Links

Sys Admin Magazine RBAC instead of sudo

ONLamp.com -- Eliminating Root with Sudo by Michael W. Lucas

freshmeat.net Project details for sudo

Sudo Main Page  Sudo (superuser 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. Here is A Brief History of Sudo

• Getting Sudo
   Via FTP
   Via the Web
   Via AnonCVS
   Mirroring Sudo
  
• Documentation
   README for Sudo
   Installation Notes
   Troubleshooting FAQ
   Sudo(8) Manual Page
   Sudoers(5) Manual Page
   Visudo(8) Manual Page
   Other Documentation
  
• Sudo Resources
   Mirror Sites
   Mailing Lists
   Bug Tracking System
   Web CVS Tree
   Supported Platforms
   Sudo License
   Sudo Changelog
   Sudo Tools
   Other Sudo-like Utilities
  

[Lansystems.com] Sudo installation and configuration guide By: Vincent Hillier <vince@lansystems.com>

Sudo, is a neat little tool. Very handy at times, what sudo does is, allows certain specified users to run some
or all commands as root, and allows the system admin to log all of the commands that the users enter, so you can peer over their actions performed.

Ok, first things first (as always) we need to get the source. This is available from the following locations...
ftp://ftp.courtesan.com/pub/sudo/
ftp://ftp.cs.colorado.edu/pub/sudo/
Grab the latest version, at the time of this writing version 1.6.3p4 is the latest.

Now we extract the tarball and make it our cwd.

tar xzvf sudo-1.6.3p4.tar.gz
cd sudo-1.6.3p4/

sudo-tools - some handy utilities for sudo

Sudo at a VERY LARGE site

• Some notes about the UNIX Environment
• Why do you need something like sudo?
• Getting/Configuring sudo
• Misc. "Tricks" for Large Heterogeneous Networks
• Controlling Access
• Using Sudo
• Logging/Audit Trail
• How well does Sudo actually work?
• Other sudo-like Utilities
• Misc. issues/concerns
• Future needs/work with Sudo
• Summary

Using Sudo -- article by A.P. Lawrence

Managing Root Access with Sudo.  About.com

Installing sudo on Solaris

ONLamp.com Eliminating Root with Sudo

While proper implementation of groups can help reduce the need for the root password, at times, users must absolutely run commands as another user (usually root). As the system administrator, you're stuck between deciding to hand out the root password or doing everything for your users. sudo provides a third way, one that can help solve this dilemma. It's a tricky program, however, and needs some care in implementation. sudo is integrated into OpenBSD, and is an add-on package for just about every other Unix-like operating system out there.

sudo is a setuid root wrapper that implements fine-grained access control for commands that need to be run as root. It takes the command you want to run and compares it to its internal list of permissions. If sudo's permissions allow that particular user to run that command, sudo runs that command for you, with its privileges. As root can run commands as any user, sudo can execute commands as any arbitrary system user.

With proper setup, the system administrator can allow any user to run any command as any other user. sudo is a very powerful tool, and can be configured to allow or deny almost any set of commands. As a result of this flexibility, the documentation tends to scare off new users. We're going to do a basic sudo setup that will cover almost all uses, but you should be aware that many more combinations are possible, and are documented in sudo(8) and sudoers(5).

Other than the obvious fine-grained access control sudo provides, there are a few other benefits to using sudo. One of the biggest advantages is the command logging. Every sudo command is logged, making it very easy to track who made what changes. And once you have sudo configured correctly, you can change the root password and not give it to anyone. Nobody should need the root password if they have the correct sudo permissions, after all! Reducing the number of people who have the root password can help improve security. Finally, a single sudo configuration file can be used on all of these systems, vastly easing administrator overhead.

The most overwhelmingly common disadvantage to sudo is that users and junior administrators don't like it. If people have traditionally had root access on a system, they will perceive that they're losing something when you implement sudo. They key to overcoming this is to make sure that people have the ability to do their jobs. If users think that they need the root password to perform other tasks, then your need to settle just who is responsible for what. These users may have been taking extra duties upon themselves, rather than troubling you with jobs that you should do.

A faulty sudo setup can create security holes. A thoughtless configuration will create holes in the system that a clever user can use to actually become root. This problem is best dealt with by a combination of careful configuration and administrative policy.

Linux Help - Sudo Setup Guide

Sudo and other ways to avoid root!

Last modified: June 05, 2008