|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
|Recommended Links||The su Command||Reference||Wheel Group|
|Sudo on AIX||Sudo for HPUX||Solaris RBAC||Group administration||SUID/SGID attributes||The umask|
|Root Account||Root Security||Admin Horror Stories||History||Humor||Etc|
One problem with Unix security is not that root is all-powerful, but that regular accounts are not powerful enough to be useful for many common tasks. One way to solve this Unix problem was sudo, the utility that can grant to non-root account root access on "per-command" basis. Essentially sudo is a rudimentarily implementation of RBAC (see, for example Solaris RBAC) in a completely portable Unix-flavor independent way. All problem related to proper structuring of roles are present in sudo, as soon as it is used for anything else then access of root account by non-root but privileged (typically members of Wheel Group) users.
Sudo (superuser do) is an extension of the classic Unix command su (introduced in BSD). It 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. In most cases it is used to as "one command switch to root". It also protect system administrators from horrible mistakes that can happen when you work as root all the time. In case you are tired you can do a lot of damage with just one "subconscious" mistake. For example, if you accidentally type rm /etc* instead of rm etc*. See Admin Horror Stories for a overview of typical "horrors" of this time. In other words working in your own account all the time and using sudo prefix when you need to execute commands as root is much safer way of working for sysadmins. Here the value of sudo is undisputable.
In addition sudo provides logging of commands which you submitted. That also has value when, say, two people administer the same server. Otherwise to understand what was done by your partner is not easy, as sysadmin typically are in a hurry and seldom completely document their actions. Sometimes people lie and try to hide their mistakes. Here you have some chances to recreate the set of actions of your partner.
Sudo is useful on all version and flavors of Unix, with possible exception of Solaris 10 were native OS mechanisms (RBAC) are superior. For a brief history of Sudo see history section
Sudo is integrated in OpenBSD and Ubuntu and pre-installed on enterprise linux distributions (RHEL and Suse). It is not installed on AIX and HP-UX but it is available in "vendor-precompiled", "vendor-unsupported" form. See
The great advantage of sudo is that it can (and should) be deployed on all Unix systems under administration (it's pretty simple to deploy if via SSH). This universal availability is a huge advantage over other similar packages.Suse has a turbulent history with many vulnerabilities fixed at different periods of time. While sudo provide an elegant way to provide to users temporary root capabilities without communicating to the user root password, there is no easy way to prevent a user from gaining a root shell if that user is allowed to run commands with shell escape via sudo. Many programs (such as editors) allow the user to run commands via shell escapes, thus avoiding sudo's checks. Some Unix utilities such as find and xarg, allow execution or arbitrary commands. However, on most systems it is possible to prevent shell escapes with sudo's noexec functionality.
The current version as of April 2013 is 1.8.6p8, but most linux distros provide only much older (but adequate) version 1.7.6p2 (called Maintenance release on sudo site). It's now pretty complex product which is the major deficiency. Security vulnerabilities are periodically discovered and for open source program of such complexity its presence in the system is essentially a free backdoor to root as it is reasonable to assume that for any version there is at lease one unknown zero-day exploit. There is a great need for simpler and more secure "sudo-light"...
In some organizations and flavors on Linux (such as Ubuntu) root account has password disabled and the only way to access root is via sudo. This concept is called Rootsudo in Ubuntu
Minimal usage of sudo involves execution of a command as root by prefixing it with the name of program (sudo). For example:
sudo passwd root
The simplest alternative to this functionality is a copy of shell renamed as sudo, set the SUID attribute and make it owned by wheel group with the execute permission for group enabled. For example:
cp /usr/bin/bash /root/bin/sudo chown root:wheel /root/bin /root/bin/sudo chmod 750 /root/bin chmod 4710 /root/bin/sudo
In this case you get basic passwordless sudo functionality for wheel group members using standard Unix facilities which is important for "strange" flavors of Unix such as HP-UX where sudo port behaves somewhat strange (AIX, another "strange" Unix has a usable sudo port).
Another rarely used but viable alternative to sudo is ssh. You can try to use ssh with a public key, which provides passwordless login like:
alias sdo='ssh root@localhost ' sdo your_command
To do this, you must create a public/private key pair for the user who should be allowed to ssh into the root account and then put the public key into root's authorized_keys file. You may restrict this key to execute only by writing
command="yourcommand"in front of the public key in root's authorized_keys file. You also have to allow root login in the sshd_config file:
Disadvantage (which you may consider to be an advantage as well) is that this passwordless connection to the local host will reinitializes your environment each time you use the command .
Sudo popularity emerged not accidentally. It has several advantages, representing, in essence, a minimal implementation of RBAC for Unix. Among them:
SSH, OpenView or Tivoli TCM permit changing of group membership for the wheel
group on selected servers with a single command. That means that instead of
time consuming operation you enroll the person who need temporary root access
to a group of servers in no time. What is very important
you can automatically provide deenrollement after
the requested period is over: just schedule
at command that remove the person
from the group at the end of agreed period. This eliminates another important
vulnerability when temporary passwords became new permanent as administrator
does not keep track of the servers with temp password and expiration periods.
Deletion is done automatically when the period expires by the command scheduled
beforehand. Otherwise this operation requires human action of resetting password
back, and this the operation that more often then is performed later then in
Ubuntu goes one step further. 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.
sudo is a really simple package that unfortunately
grow too complex with time. It consist of just three utilities (sudo,
visudo and sudoreplay) and a single configuration file
I would recommend to pay a special attention to sudoreplay as it
provides the functionality of automatic logging of your commands and then converting
them into a script the can be replayed on other servers.
sudo(8)command: setuid root wrapper that users invoke to execute commands as root (or other privileged account).
/etc/sudoers. This is a key 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
visudo(8)command allows administrators to edit the
sudoersfile without risking locking themselves out of the system.
List sessions run by user millert:sudoreplay -l user millert
List sessions run by user bob with a command containing the string vi:sudoreplay -l user bob command vi
List sessions run by user jeff that match a regular expression:sudoreplay -l user jeff command '/bin/[a-z]*sh'
List sessions run by jeff or bob on the console:sudoreplay -l ( user jeff or user bob ) tty console
Sudo is distributed under a BSD-style license and currently maintained by Todd Miller. The current homepage is http://www.courtesan.com/sudo/
Like in any complex security program the security record of sudo itself is questionable and there were several exploitable 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 too many options, keys etc. Some recent enhancements probably were not necessary and mainly 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 capable of executing other commands (or invoke shell) without envelope that checks and fixes arguments (for example find or ex) essentially means conversion of this "restricted" account into backdoor for the root, if this command is executed as root. Some of those escapes to shell can be blocked via Sudo noexec option.
Sometimes sudo is used to accomplish tasks related to access to specific command and files which also can be accomplished via ACLs. For example ACLs is preferable for granting read or write access to specific set of files for particular user. But sudo can restrict command to specific arguments, which ACLs can't do.
In both case you essentially create additional hidden infrastructure on top of regular Unix permissions. With sudo this infrastructure is even less visible then in case of ACLs. As such those capabilities should be deployed only as "the last option" when Unix groups facilities can't help.
Still, if we are talking about fixed, static commands such an approach is permissible. But granting 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 is a bad solution. This problem should be solved using either standard Unix groups or, if standard Unix groups are insufficient with ACLs.
Also you need to remember that even static commands can represent a security hole if they can escape to shell and usage of noexec option is a much in all such cases. But even this is dangerous and this protection can be broken and the privilege can be abused.
Sudo is great when cases of usage are simple and limited to few users. As soon as sudoer file become complex this complexity sooner or later can byte you unless it is structures as a repetition of the same relatively simple grants for different users.
One needs clearly understand that granting a user the right to run any command with shell escapes like "vi" or "find" as root is equivalent to granting root access. Actually granting to users, who are not system administroars the ability to execute any command with root privileges without strict control of arguments is dangerous and prome to abuse.
One needs clearly understand that granting a user the right to run commands with shell escapes 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:
# 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) ALLSimilar trick is possible for operator group
%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
Cmnd_Aliasspecifications come first, followed by any
Default_Entrylines, and finally the
Runas_Aliasand 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, wimRunas_Alias OP = root, operator Runas_Alias DB = oracle, sybaseHost_Alias SPARC = bigtime, eclipse, moet, anchor :\ SGI = grolsch, dandelion, black :\ ALPHA = widget, thalamus, foobar :\ HPPA = boa, nag, python Host_Alias CUNETS = 220.127.116.11/255.255.0.0 Host_Alias CSNETS = 18.104.22.168, 22.214.171.124/24, 126.96.36.199 Host_Alias SERVERS = master, mail, www, ns Host_Alias CDROM = orion, perseus, herculesCmnd_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
USERNAMEenvironment 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
NOPASSWDtag).jack CSNETS = ALL
The user jack may run any command on the machines in the CSNETS alias (the networks
188.8.131.52). Of those networks, only
184.108.40.206has 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
220.127.116.11).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:
|To get a good idea of what sudo can do, you really need to take a look at a sample sudoers file.|
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) 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.
Last modified: September 12, 2017