Softpanorama
(slightly skeptical) Open Source Software Educational Society

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

Softpanorama Search

Unix Sudo (superuser do)

News

See also

Recommended Links Man page Reference
Sudo on AIX Root Security History Humor Etc

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.   For a brief history of Sudo see history section

Sudo is integrated in OpenBSD and pre-installed on all enterprise linux distributions (both RHEL and Suse). But it probably should be used on all other Unix flavors.  It is portable and in enterprise environment can be easily deployed on all Unix systems via ssh, rdist, rsync or TCM.

Main advantages

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 :

  1. sudo(8) command: setuid root wrapper that users invoke to execute commands as root (or other privileged account).
     
  2. /etc/sudoers. This is a configuration file which can also be located in /etc/sudo or /usr/local/etc directory. It is sudo's roles definition file specifying who may run what commands as which user. It is fully documented in sudoers(5). See also  a good into in Gentoo Sudo(ers) Guide — Gentoo Linux Documentation
     
  3. visudo(8) command allows administrators to edit the sudoers file without risking locking themselves out of the system.

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 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 other simple commands with explicit arguments (not vi or other commands with the possibility espaing to command shell). But even this is dangerous and this privilege can be abused. Id cp command granted the wrapper can be provided which 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.

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.

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.

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


Notes:
  • This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • The site contain some broken links as it develops like a living tree... 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.
Google Search
Open directory

Research Index


Old News ;-)

[Oct 17, 2009] Make sudo work harder

06 Oct 2009 | developerWorks
 

To view what commands a user can run and what other constraints are assigned under sudo, as the user, run:
sudo -l 

Using groups

Users belonging to a valid AIX group can be included in sudoers, making the sudoers file more manageable with fewer entries per user. When reorganizing the sudoers entries to include groups, you may have to create a new groups under AIX to include users that are only allowed to use sudo for certain commands. To use groups, simply prefix the entries with a '%'. Assume you have groups called devops and devuat, and with those groups you have the following users:

# lsgroup -f -a users devops

devops:
        users=joex,delta,charlie,tstgn

 # lsgroup -f -a users devuat
devuat:
        users=zebra,spsys,charlie

For the group devops to be allowed to run the /usr/local/bin/data_ext.sh command as dbdftst.

For the group devuat to be allowed to run the commands :/usr/local/bin/data_mvup.sh, /usr/local/bin/data_rep.sh as dbukuat.

We could have the following sudoers entries:

%devops rs6000 =  (dbdftst) NOPASSWD: /usr/local/bin/data_ext.sh
%devuat rs6000 =  (dbukuat) /usr/local/bin/data_mvup.sh
%devuat rs6000 =  (dbukuat) /usr/local/bin/data_rep.sh

Notice in the previous entries, the group devops users will not be prompted for their password when executing /usr/local/bin/data_ext.sh; however, the group devuat users will be prompted for their password. User "charlie" is a member of both groups (devops and devuat), so he can execute all the above commands.

 

[Sep 4, 2009] Linux Layer 8 Security LG #166

It's better to have sudo file standard and periodically overwritable from baseline. Enrollment of users should be done via groups such as wheel.

It's often too late when we realize that our sudoers file was not configured to be limited to only a select list of users, or was not logging (e.g., if we have inherited 200 machines installed with stock sudo -- see my August 2009 Linux Gazette "Layer 8 Linux Security" column on maintaining sudo via Puppet). So, perhaps it went unnoticed that a past disgruntled developer was accessing the system from his desktop via RDP to SSH and accessing root regularly via 'sudo su'.

In startup ISPs and Web development shops in the mid-1990s, a "Nazi" Linux security administrator would often tire of being on-call 24x7 in an uncontrollable server farm, and come down with the avant-garde edict of "no shared root access", whereupon all developers just took escalated access via escaping system calls from emacs or vi, or via buffer overflows, and happily changed the access passwords for users: games, haldaemon, adm, lp, or sync. Similar shops and Linux un-professionals still exist, unfortunately.

Since any access to root via sudo can result in changes (and potential errors), a good keylogger makes a lot of sense as an easily setup secondary tracking mechanism.

PCI compliance and SOX both require controls in place for the root or administrative user. However, when mixed with corporate profit, these controls are loosely interpreted to the point of complete insecurity. If we cannot track change, we control nothing. Implementing a keylogger will take no more than fifteen to thirty minutes (and can easily be automated through Puppet), so if you suspect your systems of being accessed and the logs being wiped, or if you don't have the time to fully evaluate all binary checksums for rootkits, keyloggers can be a good immediate additional security tool.

By default, 'rootsh' logs to /var/log/rootsh/ (which can be changed during setup). Of course, 'rootsh' logs can be edited, like any logs, unless you use 'syslog-ng', or stunnel loghost or cron-based e-mail log burst, so hide them well. You will generally find that no one even notices that 'rootsh' is logging, and happily carry on as normal.

[Apr 20, 2009] sudo 1.7.1

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

Running Complex Commands with sudo Linux Journal

If you use sudo to run commands as root, you've probably run into “permission denied” problems when only part of a pipeline or part of a command is running with root permissions.

This fails with “permission denied” because the file is writable only by root:

$ echo 12000 > /proc/sys/vm/dirty_writeback_centisecs

But, this fails too:

$ sudo echo 12000 > /proc/sys/vm/dirty_writeback_centisecs

Why? The /bin/echo program is running as root, because of sudo, but the shell that's redirecting echo's output to the root-only file is still running as you. Your current shell does the redirection before sudo starts.

The solution is to run the whole pipeline under sudo. There are a couple ways to do it, but I prefer:

echo "echo 12000 > /proc/sys/vm/dirty_writeback_centisecs" | sudo sh

That way, I can type everything before the pipe character, and see what I'm about to run as root, then press the up arrow and add the | sudo sh to do it for real. This is not a big deal for short, obvious pipelines, but when you're building up a more complicated command as root, it's safer to look at it first before you run it.

 

Secure Cooking with Linux, Part 2 O'Reilly Media

Recipe 5.11. Permitting Read-Only Access to a Shared File via sudo

Author's note: Sharing a file with multiple users is easy with Linux groups. But what if you want to restrict some people to have read-only access to a file, while giving others read/write access? This recipe, from Chapter 5, "Authorization Controls," explains how sudo can come to the rescue.

Problem

Two or more users want to share a file, some read/write and the others read-only.

Solution

Create two Linux groups, one for read/write and one for read-only users:

/etc/group:
readers:x:300:r1,r2,r3,r4
writers:x:301:w1,w2,w3

Permit the writers group to write the file via group permissions:

$ chmod 660 shared_file
$ chgrp writers shared_file

Permit the readers group to read the file via sudo:

/etc/sudoers:
%readers  ALL = (w1) /bin/cat /path/to/shared_file

Discussion

This situation could arise in a university setting, for example, if a file must be writable by a group of teaching assistants but read-only to a group of students.

If there were only two users -- one reader and one writer -- you could dispense with groups and simply let the reader access the file via sudo. If smith is the reader and jones the writer, and we give smith the following capability:

/etc/sudoers:
smith  ALL = (jones) NOPASSWD: /bin/cat /home/jones/private.stuff

then jones can protect her file:

jones$ chmod 600 $HOME/private.stuff

and smith can view it:

smith$ sudo -u jones cat /home/jones/private.stuff

See Also

sudo(8), sudoers(5), group(5), chmod(1), chgrp(1).

Check back here next week for recipes from Linux Security Cookbook on how to use PAM to restrict authentication on Linux systems, and how to use SMTP to securely accept connections from arbitrary clients.

[Nov 14 2008 ] sudo 1.6.9p18 by Todd Miller

About: 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.

Changes: A crash which occurred when the -i flag was used with a uid not in the password database has been fixed. Sudo now operates in the C locale again when doing a match against sudoers. A potential crash when a glob matches a large number of files has been fixed. A compilation problem with certain versions of Heimdal KerberosV has been fixed. When setting the umask, sudo will now use the union of the user's umask and the value set in sudoers. Sudo now stats fewer files when doing a wildcard match.

[Oct 10, 2008] Install and configure sudo in AIX - Toolbox for IT Knowledge Sharing Communities

sudo is controlled by its configuration file /etc/sudoers. The program has a rich selection of configuration options and you may like to read the man page for sudoers and examine the sample configuration file which you'll find in sample.sudoers in the source code directory.

The instructions below describe how to create an sudoers file which allows any user to run the /dialup and /hangup scripts defined in Configuring PPP on Solaris to connect to an ISP and allows a particular user to run any command as root.

One potential difficulty is that the /etc/sudoers file must be edited using the visudo program and not directly in your editor of choice. visudo uses the "vi" editor and this means that you need at least a basic understanding of how to use this editor. If you aren't already familiar with vi, you'll have to learn it sooner or later so now's a good time to start! But don't worry if you've never used it before - I'll include enough instruction here to enable you to edit the short file created by the installation process and append a couple of lines to it.

To edit /etc/sudoers, make sure you're logged in as root and type:

  1. /usr/local/sbin/visudo

This starts the vi editor and displays the initial /etc/sudoers file. vi uses what appear at first sight to be commands that aren't exactly intuitive. If you're not familiar with vi, type the following exactly as it appears and note that commands in vi are case sensitive. So don't type a lower-case "g" when the instructions show an upper-case "G".

Move the cursor to the end of the file by typing an upper-case G:

G

and open a new line just beyond the last line in the file by typing a lower-case o:

o

vi is now in "edit" mode and anything you type is inserted into the file. If you want everyone (all users) to be able to run the /hangup and /dialup scripts, type the following:

ALL ALL=/dialup,/hangup

with a TAB character after the first "ALL". That line tells sudo that all users are allowed to execute the scripts /hangup and /dialup as if they were root.

If you want to give just one user, say jim, the ability to run the scripts, type the following instead:

jim ALL=/dialup,/hangup

You may like to add another line telling sudo that your own personal user is allowed to do anything as root. Press the ENTER key and, if your own personal user is mike, you'd type:

mike ALL=(root) ALL

again with a TAB character after "mike".


 

Finally, switch vi back into command mode by pressing the ESCAPE key and exit vi by typing:

wq

followed by ENTER. If you make a mistake at any time, just press the ESCAPE key followed by:

q!

followed by ENTER and vi will return you to the shell command prompt without making any changes to the file.

6. Using sudo:

sudo is simple to use. To execute a command with root privilege, type:

$ sudo name-of-command

If this is the first time you've used sudo since logging in, sudo will ask for your password. The password required at this point is the user's own password, not the root password. So, if you've logged in as user jane and she wants to start a dialup connection to her ISP, she would type:

  1. sudo /dialup

and sudo responds:

We trust you have received the usual lecture from the local System

Administrator. It usually boils down to these two things:

  1. 1) Respect the privacy of others.
  2. 2) Think before you type.

Password:

Jane would then type her password and sudo will run the /dialup script for her with root privilege. If further commands are executed using sudo within 5 minutes, it will not ask for a password again.

But if Jane were to try and execute a command without having the necessary permission (as defined in the /etc/sudoers file), sudo will refuse to run it:

$ sudo vi /etc/passwd

Sorry, user jane is not allowed to execute "/usr/bin/vi /etc/passwd" as root on sunbeam.

In this example, sunbeam is the name of the machine.
 

If you'd prefer not to have to type a password at all, replace the two lines in /etc/sudoers with:

ALL NOPASSWD: ALL=/dialup,/hangup mike ALL=(root) NOPASSWD: ALL

[Sep 19, 2008] trouble with syslog and sudo logs

Please note the for AIX you need to enable syslog first.
John Hines bigjohn_101 at hotmail.com
Wed Jan 23 11:58:35 MST 2002
Hi Todd,

  I made the suggested changes and my sudo logs are no longer going to
/var/log/messages, but they are also not going to /var/log/sudo.log.  This
is the current state of my syslog.conf:

# $FreeBSD: src/etc/syslog.conf,v 1.13.2.2 2001/02/26 09:26:11 phk Exp $
#
#       Spaces are NOT valid field separators in this file.
#       Consult the syslog.conf(5) manpage.
*.err;kern.debug;auth.notice;mail.crit          /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err;local2.none
/var/log/messages
security.*                                      /var/log/security
mail.info                                       /var/log/maillog
lpr.info                                        /var/log/lpd-errs
cron.*                                          /var/log/cron
*.err                                           root
*.notice;news.err                               root
*.alert                                         root
*.emerg                                         *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info                                   /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
#*.*                                            /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.*                                            @loghost
# uncomment these if you're running inn
# news.crit                                     /var/log/news/news.crit
# news.err                                      /var/log/news/news.err
# news.notice                                   /var/log/news/news.notice
!startslip
*.*                                             /var/log/slip.log
!ppp
*.*                                             /var/log/ppp.log
# This logs successful and failed sudo attempts to the file
/var/log/sudo.log
local2.debug                                    /var/log/sudo.log

Thanks for the help,

John Hines

----- Original Message -----
From: Todd C. Miller <Todd.Miller at courtesan.com>
To: John Hines <bigjohn_101 at hotmail.com>
Cc: <sudo-users at sudo.ws>
Sent: Tuesday, January 22, 2002 9:49 PM
Subject: Re: trouble with syslog and sudo logs


> In message <OE16SN2uhoSQD5Y54Qt00012596 at hotmail.com>
> so spake "John Hines" (bigjohn_101):
>
> > # $FreeBSD: src/etc/syslog.conf,v 1.13.2.2 2001/02/26 09:26:11 phk Exp $
> > #
> > #       Spaces are NOT valid field separators in this file.
> > #       Consult the syslog.conf(5) manpage.
> > *.err;kern.debug;auth.notice;mail.crit          /dev/console
> > *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
> > security.*                                      /var/log/security
> > mail.info                                       /var/log/maillog
> > lpr.info                                        /var/log/lpd-errs
> > cron.*                                          /var/log/cron
> > *.err                                           root
> > *.notice;news.err                               root
> > *.alert                                         root
> > *.emerg                                         *
> > # uncomment this to log all writes to /dev/console to =
> > /var/log/console.log
> > #console.info                                   /var/log/console.log
> > # uncomment this to enable logging of all log messages to =
> > /var/log/all.log
> > #*.*                                            /var/log/all.log
> > # uncomment this to enable logging to a remote loghost named loghost
> > #*.*                                            @loghost
> > # uncomment these if you're running inn
> > # news.crit                                     /var/log/news/news.crit
> > # news.err                                      /var/log/news/news.err
> > # news.notice                                   =
> > /var/log/news/news.notice
> > !startslip
> > *.*                                             /var/log/slip.log
> > !ppp
> > *.*                                             /var/log/ppp.log
> > # This logs successful and failed sudo attempts to the file =
> > /var/log/sudo.log
> > local2.debug                                    /var/log/sudo.log
>
> You need to add "local2.none" after the "news.err" in /var/log/messages
> line.  That will keep sudo messages going to /var/log/messages.
>
>  - todd
>

[Sep 18, 2008] Gentoo Sudo(ers) Guide — Gentoo Linux Documentation

Sudoers Syntax

Basic Syntax

The most difficult part of sudo is the /etc/sudoers syntax. The basic syntax is like so:

Code Listing 2.1: Basic /etc/sudoers syntax

user  host = commands

This syntax tells sudo that the user, identified by user and logged on through the system host can execute any of the commands listed in commands as the root user. A more real-life example might make this more clear: allow the user swift to execute emerge if he is logged on from the system (not through SSH):

Code Listing 2.2: Live /etc/sudoers examples

swift  localhost = /usr/bin/emerge

A big warning is in place though: do not allow a user to run an application that can allow people to elevate privileges. For instance, allowing users to execute emerge as root can indeed grant them full root access to the system because emerge can be manipulated to change the live file system to the user's advantage. If you do not trust your sudo users, don't grant them any rights.

The user name can also be substituted with a group name - in this case you should start the group name with a % sign. For instance, to allow any one in the wheel group to execute emerge:

Code Listing 2.3: Allowing the wheel group members to execute emerge

%wheel  localhost = /usr/bin/emerge

You can extend the line to allow for several commands (instead of making a single entry for each command). For instance, to allow the same user to not only run emerge but also ebuild and emerge-webrsync as root:

Code Listing 2.4: Multiple commands

swift  localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync

You can also specify a precise command and not only the tool itself. This is useful to restrict the use of a certain tool to a specified set of command options. The sudo tool allows shell-style wildcards (AKA meta or glob characters) to be used in pathnames as well as command line arguments in the sudoers file. Note that these are not regular expressions.

Let us put this to the test:

Code Listing 2.5: Attempt to update the system using sudo

$ sudo emerge -uDN world

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Password: (Enter the user password, not root!)

The password that sudo requires is the user's own password. This is to make sure that no terminal that you accidentally left open to others is abused for malicious purposes.

You should know that sudo does not alter the ${PATH} variable: any command you place after sudo is treated from your environment. If you want the user to run a tool in for instance /sbin he should provide the full path to sudo, like so:

Code Listing 2.6: Using the full path to a tool

$ sudo /usr/sbin/emerge-webrsync

Using Aliases

In larger environments having to enter all users over and over again (or hosts, or commands) can be a daunting task. To ease the administration of /etc/sudoers you can define aliases. The format to declare aliases is quite simple:

Code Listing 2.7: Declaring aliases in /etc/sudoers

Host_Alias hostalias = hostname1, hostname2, ...
User_Alias useralias = user1, user2, ...
Cmnd_Alias cmndalias = command1, command2, ...

One alias that always works, for any position, is the ALL alias (to make a good distinction between aliases and non-aliases it is recommended to use capital letters for aliases). As you might undoubtedly have guessed, the ALL alias is an alias to all possible settings.

A sample use of the ALL alias to allow any user to execute the shutdown command if he is logged on locally is:

Code Listing 2.8: Allowing any user to execute shutdown

ALL  localhost = /sbin/shutdown

Another example is to allow the user swift to execute the emerge command as root, regardless of where he is logged in from:

Code Listing 2.9: Allowing a user to run an application regardless of his location

swift   ALL = /usr/bin/emerge

More interesting is to define a set of users who can run software administrative applications (such as emerge and ebuild) on the system and a group of administrators who can change the password of any user, except root!

Code Listing 2.10: Using aliases for users and commands

User_Alias  SOFTWAREMAINTAINERS = swift, john, danny
User_Alias  PASSWORDMAINTAINERS = swift, sysop
Cmnd_Alias  SOFTWARECOMMANDS    = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias  PASSWORDCOMMANDS    = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root

SOFTWAREMAINTAINERS  localhost = SOFTWARECOMMANDS
PASSWORDMAINTAINERS  localhost = PASSWORDCOMMANDS

Non-Root Execution

It is also possible to have a user run an application as a different, non-root user. This can be very interesting if you run applications as a different user (for instance apache for the web server) and want to allow certain users to perform administrative steps as that user (like killing zombie processes).

Inside /etc/sudoers you list the user(s) in between ( and ) before the command listing:

Code Listing 2.11: Non-root execution syntax

users  hosts = (run-as) commands

For instance, to allow swift to run the kill tool as the apache or gorg user:

Code Listing 2.12: Non-root execution example

Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill

swift   ALL = (apache, gorg) KILL

With this set, the user can run sudo -u to select the user he wants to run the application as:

Code Listing 2.13: Running pkill as the apache user

$ sudo -u apache pkill apache

You can set an alias for the user to run an application as using the Runas_Alias directive. Its use is identical to the other _Alias directives we have seen before.

Passwords and Default Settings

By default, sudo asks the user to identify himself using his own password. Once a password is entered, sudo remembers it for 5 minutes, allowing the user to focus on his tasks and not repeatedly re-entering his password.

Of course, this behavior can be changed: you can set the Defaults: directive in /etc/sudoers to change the default behavior for a user.

For instance, to change the default 5 minutes to 0 (never remember):

Code Listing 2.14: Changing the timeout value

Defaults:swift  timestamp_timeout=0

A setting of -1 would remember the password indefinitely (until the system reboots).

A different setting would be to require the password of the user that the command should be run as and not the users' personal password. This is accomplished using runaspw. In the following example we also set the number of retries (how many times the user can re-enter a password before sudo fails) to 2 instead of the default 3:

Code Listing 2.15: Requiring the root password instead of the user's password

Defaults:john   runaspw, passwd_tries=2

Another interesting feature is to keep the DISPLAY variable set so that you can execute graphical tools:

Code Listing 2.16: Keeping the DISPLAY variable alive

Defaults:john env_keep=DISPLAY

You can change dozens of default settings using the Defaults: directive. Fire up the sudo manual page and search for Defaults.

If you however want to allow a user to run a certain set of commands without providing any password whatsoever, you need to start the commands with NOPASSWD:, like so:

Code Listing 2.17: Allowing emerge to be ran as root without asking for a password

swift     localhost = NOPASSWD: /usr/bin/emerge

3.  Using Sudo

Listing Privileges

To inform yourself what your capabilities are, run sudo -l:

Code Listing 3.1: Listing capabilities

$ sudo -l
User swift may run the following commands on this host:
    (root)   /usr/libexec/xfsm-shutdown-helper
    (root)   /usr/bin/emerge
    (root)   /usr/bin/passwd [a-zA-Z0-9_-]*
    (root)   !/usr/bin/passwd root
    (apache) /usr/bin/pkill
    (apache) /bin/kill

If you have any command in /etc/sudoers that does not require you to enter a password, it will not require a password to list the entries either. Otherwise you might be asked for your password if it isn't remembered.

Prolonging the Password Timeout

By default, if a user has entered his password to authenticate himself to sudo, it is remembered for 5 minutes. If the user wants to prolong this period, he can run sudo -v to reset the time stamp so that it will take another 5 minutes before sudo asks for the password again.

Code Listing 3.2: Prolonging the password timeout

$ sudo -v

The inverse is to kill the time stamp using sudo -k.

[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:

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:

[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

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

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

You have an entry in your sudoers file that contains something like this:

admin    ALL=(ALL) ALL

then sudo will require you to enter a password when running a command with sudo. This is the user password (and not the root password), in this case the password of the user “admin”.

targetpw

If for some reason you want to change this behavior, then you can use the sudo global flag targetpw. This is by default OFF, and if you set it like show bellow then the password you will be asked while running sudo will be the password of the target user (in our case the root password).

Defaults    targetpw

Personally, I don’t see the use of this parameter and never used it myself… But maybe someone else will find it useful.

NOPASSWD

If you don’t want to be prompted for any password while running sudo then we can use the NOPASSWD parameter on a particular entry:

admin    ALL = NOPASSWD: ALL

this parameter is the opposite of the default PASSWD and will no longer require any password for the user “admin” while running sudo. This can be of useful while running scripts that will launch sudo (in this case I would recommend to enable NOPASSWD only for the needed commands), or just if you don’t want to keep typing the password. Obviously with this commodity, you will reduce the security of sudo: if someone hacks the “admin” account then this can be easily used to gain root privileges.

authenticate

Another sudo option that can be used to control the prompt for a password is the global flag: authenticate. This is by default ON and this means that it will ask the user to authenticate with a password. This can be overwritten as seen above with the NOPASSWD on a particular entry. If we want to disable it globally, this can be done with:

Defaults    !authenticate

Once set, this will disable authentication for all users that use the defaults like our “admin” sample from above. It can be overwritten on particular definition by setting the PASSWD parameter:

admin    ALL=(ALL) PASSWD: ALL

Note: this post doesn’t recommend you to disable the passwords usage in sudo (this is not a good idea, by the way), but just to show you what options are available and how you can use them. Knowing the security implications of disabling password usage in sudo, use them wisely based on your particular needs.

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

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

The password is stored by default for 15 minutes. After that time, you will need to enter your password again.
  • Your password will not be shown on the screen as you type it, not even as a row of stars (******). It is being entered with each keystroke!
  • sudo !! will repeat the last command entered, except with sudo prepended to it.
  • You should never use sudo to start graphical applications as root. You should use gksudo to run such programs (eg. ALT+F2 gksudo gedit).
  • To run the graphical configuration utilities, simply launch the application via the menu.
  • [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

    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

           

    [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)

    Why use sudo rather than RBAC

    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:

    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:

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

    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.

    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


    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

    Recommended Links


    In case of broken links please try to use Google search. If you find the page please notify us about new location
    Google     

    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

    [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

    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!

    History

    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.


    Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

    Disclaimer:

    Last modified: October 19, 2009