|
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. 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
- The simplification of delegation of root. In large enterprises
one of the services Unix group provides is to set a temp root password on one
or several boxes so that application administrator can perform some operations
which require root access. Communication of temp root password creates a vulnerability
due to which an intelligent person can access root account on some other systems
that currently are converted for temp root. This is true if temp password
is created using some formula that contains as a part server name (for example
prefix) and a random string (as a suffix). In case of sudo you can use automatic
remote enrollment of user into particular group (wheel or sysadmin, depending
on flavor of Unix used) and do not even need manually to login into the system.
Ssh or TCM permit doing this as one operation for all requested servers. In
this case you need to execute just one command to enroll the person who need
temporary root access into
wheel
group (sysadmin group on Solaris to provide temp access to root and schedule
at command that remove the person from the group automatically at the end of
agreed period.
This way there is no possibility of forgetting to remove the privileges of the
user for whom the specified term of root access is expired: Deletion is
done automatically when the period expires by the
at command scheduled beforehand. Otherwise
this operation requires human action of resetting password back, the operation
that more often then not is performed later then in due time.
- Audit trail for all attempts to switch to root both successful and unsuccessful.
That tremendously help in troubleshooting, especially as is typical for
large enterprise environment when there are multiple cooks (aka sysadmins ;-)
in the kitchen and the left hand does not know what right hand is doing.
- Simplification of switching to root for administrators. Sudo
can be configured in such a way that members of wheel group do not need additional
authentication to became the root. That saves time and troubles of remembering
multiple root passwords if you need to administer multiple systems (or a creation
of a security vulnerability if such password are constructed using a pre-defined
formula; intelligent users can soon get this "secret" and use it to their own
advantage to cut red tape).
Ubuntu goes one step further here in the default sudo configuration.
By default, the root account password is locked in Ubuntu. This means
that you cannot login as root directly. However, since the root account physically
exists it is still possible to sudo to root and to run programs with root-level
privileges.
- Prevention of costly mistakes. The main value of sudo for sysadmins
is that it helps to 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 permits to execute single command as root without
authentication (if configured this way) by prefixing with sudo.
If passwords for regular accounts are one time (e.g. reasonably secure as is
the case if SecurID or similar one-time password system is used) this
is a very attractive solution.
- Possibility to grant "read-only" access to certain files. 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.
- Possibility to grant only selected commands executed with extended privileges
to certain users. Suse is definitely not RBAC, but some functionality similar
to RBAC can be imitated by granting access to several command (for example the
ability to start and stop particular application server). The command
should be unable to escape to shell preferable to be simple enough to exclude
this possibility (not find, view, etc ). Compete specification of arguments
usually is required to prevent attempts to use it as a "universal root opener".
while definitely useful for restarting daemons and some similar actions this
is not a RBAC and you should keep such assignments simple. Excessive zeal here
really hurts.
-
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). Please note the for
AIX you need to enable
syslog first.
- "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. This is a useful facilty for critical boxes.
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 :
sudo(8) command: setuid root wrapper that users invoke to execute
commands as root (or other privileged account).
/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
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:
- Unlike RBAC, sudo is portable (RBAC now is implemented in solaris and AIX
6.1) 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
and /etc/sudoers configuration file across
all servers
- SCCS or CVS can used to track changes to sudoers
- 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.
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.
|
|
|
|
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.
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.
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
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.
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.
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.
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:
- /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:
- 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) Respect the privacy of others.
- 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
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
>
|
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:
|
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.
|
|
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
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
- 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
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.
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.
- 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 ...
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).
- For users of Kubuntu, use kdesu instead of gksudo.
To run the graphical configuration utilities, simply launch the application
via the menu.
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.
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 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:
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.
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.
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
- 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.
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
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
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
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!
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:
- The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with.
- We do not warrant the correctness of the information provided or its
fitness for any purpose
- In no way this site is associated with or endorse cybersquatters
using
the term "softpanorama" with other main or country domains (e.g. softpanorama.com) with
bad faith intent to profit from the goodwill belonging to
someone else.
Last modified:
October 19, 2009
