Softpanorama

Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)

Unix Sudo (superuser do)

Softpanorama main  >  Access Control in Operating Systems

News

Introduction to Sudo

Recommended Links The su Command Reference Sudoer file Examples
Sudo on AIX Sudo for HPUX SUID/SGID attributes The umask Root Security Wheel Group
Root Account Groups administration User Private Groups System Groups Separation of Duties The su Command
Solaris RBAC Principle of Least Privilege Admin Horror Stories History Humor Etc

Introduction

The key 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

Sudoers file

The most difficult part of sudo is the /etc/sudoers syntax. The most important linesin it are so access right specifications. The special command '"sudoedit"' allows users to run sudo with the -e flag to edit this file.

The basic syntax of access rights specification is as following (in each list multiple entries should be separated by comma):

USER_LIST HOST_LIST = [ (AS_USER) ]  [NOPASSWD:] COMMAND_LIST

But the devil is in details. Here are some simple examples (using the aliases (in capital letters, such as WEBMASTERS, ADMINS,  which are expalined abd defined below):

 # This lets the webmasters run all the web commands on the machine 
 # "webserver" provided they give a password
 WEBMASTERS webserver= WEB_CMDS

Here we have

WEBMASTER -- this a single entry in USER_LIST field. In this case this is a so called alias.

webserver -- this is hostname of particular server.

(AS_USER) field is abesen (itr is optional). Root is assume in such a case.

WEB_CMDS -- is an alas that corresponds to COMMAND_LIST. It defines the set of command that the  user can execute as root.

Some more examples in the same style:

 # users are allowed to assume identity of root on workstation
 USERS WORKSTATIONS=(root) ADMIN_CMDS
This example has field (AS_USER) That means that all users defined in the alias USERS  can assume identity of or root
 # This lets "harry" shutdown his own machine without a password
 harry harrys-machine= NOPASSWD: SHUTDOWN_CMDS
 # And this lets everybody print without requiring a password
 ALL ALL=(ALL) NOPASSWD: PRINTING_CMDS

The user name can also be substituted with a group name - in this case you should start the group name with a % sign. For example:

%users  localhost = /usr/bin/crontab
%oracle  localhost = /usr/bin/crontab, /etc/inint.d/oracle

In addition you can also specify a precise command and not only the tool itself.

oracle  localhost = /usr/bin/crontab -u oracle

This is useful to restrict the use of a certain tool to a specified set of command options. The sudo  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.

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 executed using your current environment.

Using Aliases

In larger environments having to enter all users over and over again (or hosts, or commands) can be a time consuming and error prone  task. To ease the administration of /etc/sudoers you typically define a set of aliases.  By convention, aliases are defined  as names in all capital letters.

Each alias definition is of the form:

Alias_Type NAME = item1, item2, ... 

The format to declare aliases is quite simple and can deducted from the following examples: 

Runas_Alias OPERATORS = sge, vasp, accelrys
Host_Alias CLUSTER = hostname1, hostname2, ...
User_Alias RESEACHERS = user1, user2, ...
Cmnd_Alias STARTUP_AND_SHUTDOWN = command1, command2, ...

As you can see from he examples above there are four kinds of aliases: User_Alias, Runas_Alias, Host_Alias and Cmnd_Alias.

ALL Alias

One alias that always works, for any position, is the ALL alias (again, to make a good distinction between aliases and non-aliases it is highly recommended to use capital letters for aliases). the ALL alias is an alias to all possible settings similar to wildcard * in shell.

Here is an example that uses ALL alias to allow any user to execute the shutdown command if he is logged on locally is:

ALL  localhost = /sbin/shutdown

Another example is to allow the user  defined by an alias RESERACHERS to execute the yum command as root, regardless of where they are logged in:

RESEARCHERS   ALL = /sbin/yum

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!

User_Alias  SOFTWARE_MAINTAINERS = swift, john, danny
User_Alias  PASSWORD_MAINTAINERS = swift, sysop
Cmnd_Alias  SOFTWARE_COMMANDS    = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias  PASSWORD_COMMANDS    = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root

SOFTWARE_MAINTAINERS  localhost = SOFTWARE_COMMANDS
PASSWORD_MAINTAINERS  localhost = PASSWORD_COMMANDS

User Aliases

User aliases are used to specify groups of users. You can specify usernames, system groups (prefixed by a %) and netgroups (prefixed by a +) as follows:

 # Everybody in the system group "admin" is covered by the alias ADMINS
 User_Alias ADMINS = %admin
 # The users "tom", "dick", and "harry" are covered by the USERS alias
 User_Alias USERS = tom, dick, harry
 # The users "tom" and "mary" are in the WEBMASTERS alias
 User_Alias WEBMASTERS = tom, mary
 # You can also use ! to exclude users from an alias
 # This matches anybody in the USERS alias who isn't in WEBMASTERS or ADMINS aliases
 User_Alias LIMITED_USERS = USERS, !WEBMASTERS, !ADMINS

Runas Aliases

Runas Aliases are almost the same as user aliases but you are allowed to specify users by uid's. This is helpful as usernames and groups are matched as strings so two users with the same uid but different usernames will not be matched by entering a single username but can be matched with a uid. For example:

 # UID 0 is normally used for root
 # Note the hash (#) on the following line indicates a uid, not a comment.
 Runas_Alias ROOT = #0
 # This is for all the admin users similar to the User_Alias of ADMINS set earlier 
 # with the addition of "root"
 Runas_Alias ADMINS = %admin, root

Host Aliases

A host alias is a list of hostname, ip addresses, networks and netgroups (prefixed with a +). If you do not specify a netmask with a network the netmask of the hosts ethernet interface(s) will be used when matching.

 # This is all the servers
 Host_Alias SERVERS = 192.168.0.1, 192.168.0.2, server1
 # This is the whole network
 Host_Alias NETWORK = 192.168.0.0/255.255.255.0
 # And this is every machine in the network that is not a server
 Host_Alias WORKSTATIONS = NETWORK, !SERVER
 # This could have been done in one step with 
 # Host_Alias WORKSTATIONS = 192.168.0.0/255.255.255.0, !SERVERS
 # but I think this method is clearer.

Command Aliases

Command aliases are lists of commands and directories. You can use this to specify a group of commands. If you specify a directory it will include any file within that directory but not in any subdirectories.

If you include command line arguments in a command in an alias these must exactly match what the user enters on the command line. If you include any of the following symbols they will need to be escaped with a backslash (\): ",", "\", ":", "=".

Examples:

 # All the shutdown commands
 Cmnd_Alias SHUTDOWN_COMMANDS = /sbin/poweroff, /sbin/reboot, /sbin/halt
 # Printing commands
 Cmnd_Alias PRINTING_COMMANDS = /usr/sbin/lpc, /usr/sbin/lprm
 # Admin commands
 Cmnd_Alias ADMIN_COMMANDS = /usr/sbin/passwd, /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermod, /usr/sbin/visudo
 # Web commands
 Cmnd_Alias WEB_COMMANDS = /etc/init.d/apache2

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:

users  hosts = (run-as) commands

For instance, to allow users defined as WEBMASTERS to run the kill tool as the apache or gorg user:

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

WEBMASTERS   ALL = (apache, gorg) KILL

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

$ 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):

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:

Defaults:john   runaspw, passwd_tries=2

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

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:

RESERACHERS     localhost = NOPASSWD: /sbin/yum

there some addtional capabilities which are nicely explained in Linux Tips Password usage in sudo (PASSWD - NOPASSWD) - MDLog-sysadmin

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

 

Implementing two groups of administrators

In enterprise environment you usually have two group administrators

In this case you can have two privileged groups:

For example:

%admin  ALL=(ALL) ALL
%wheel  ALL=(ALL) NOPASSWD: ALL

Grouping of commands

Here are some examples that give you idea of how to implement grouping of commands via Cmnd_Alias

# User Alias specification
User_Alias      TOMCATTERS = apps_owner1, apps_owner2
# Runas alias specification

# CMND alias specification
#The idea if a group of commands called VIEWCMD
Cmnd_Alias      VIEW_CMDS = /bin/ls, /bin/more, /bin/cat
#start and stop command for particular daemon for application owner
Cmnd_Alias      TOMCAT_CMDS = /etc/init.d/tomcat_stop, /etc/init.d/tomcat_start

%staff          ALL=(root) NOPASSWD: VIEW_CMDS
TOMCATTERS      ALL=(root) NOPASSWD: TOMCAT_CMDS
# grant a single command to user oracle
oracle ALL=(root) NOPASSWD: /usr/bin/crontab

Using multiple tags on a single line

There are times where you need to have both NOPASSWD and NOEXEC or other tags on the same configuration line. The man page for sudoers is less than clear, so here is an example of how this is done:

%staff ALL = (root) NOPASSWD:NOEXEC: /usr/bin/vim

This example lets the user "myuser" run as root the "vim" binary without a password, and without letting vim shell out (the :shell command).

More about Runas_Spec

A Runas_Spec determines the user and/or the group that a command may be run as. A fully-specified Runas_Spec consists of two Runas_Lists (as defined above) separated by a colon (‘:’) and enclosed in a set of parentheses. The first Runas_List indicates which users the command may be run as via sudo's ‑u option. The second defines a list of groups that can be specified via sudo's ‑g option. If both Runas_Lists are specified, the command may be run with any combination of users and groups listed in their respective Runas_Lists. If only the first is specified, the command may be run as any user in the list but no ‑g option may be specified. If the first Runas_List is empty but the second is specified, the command may be run as the invoking user with the group set to any listed in the Runas_List. If both Runas_Lists are empty, the command may only be run as the invoking user. If no Runas_Spec is specified the command may be run as root and no group may be specified.

A Runas_Spec sets the default for the commands that follow it. What this means is that for the entry:

dgb	boulder = (operator) /bin/ls, /bin/kill, /usr/bin/lprm

The user dgb may run /bin/ls, /bin/kill, and /usr/bin/lprm—but only as operator. E.g.,

$ sudo -u operator /bin/ls

It is also possible to override a Runas_Spec later on in an entry. If we modify the entry like so:

dgb	boulder = (operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm

Then user dgb is now allowed to run /bin/ls as operator, but /bin/kill and /usr/bin/lprm as root.

We can extend this to allow dgb to run /bin/ls with either the user or group set to operator:

dgb	boulder = (operator : operator) /bin/ls, (root) /bin/kill,\
	/usr/bin/lprm

Note that while the group portion of the Runas_Spec permits the user to run as command with that group, it does not force the user to do so. If no group is specified on the command line, the command will run with the group listed in the target user's password database entry. The following would all be permitted by the sudoers entry above:

$ sudo -u operator /bin/ls
$ sudo -u operator -g operator /bin/ls
$ sudo -g operator /bin/ls

In the following example, user tcm may run commands that access a modem device file with the dialer group.

tcm	boulder = (:dialer) /usr/bin/tip, /usr/bin/cu,\
	/usr/local/bin/minicom

Note that in this example only the group will be set, the command still runs as user tcm. E.g.

$ sudo -g dialer /usr/bin/cu

Multiple users and groups may be present in a Runas_Spec, in which case the user may select any combination of users and groups via the ‑u and ‑g options. In this example:

alan	ALL = (root, bin : operator, system) ALL

user alan may run any command as either user root or bin, optionally setting the group to operator or system.

Listing Privileges

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

$ sudo -l

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.

$ sudo -v

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

Tips

sudo !!  will repeat the last command entered, except with sudo prepended to it.

Special group (for example tempadm) can be used for temporary granting a specific user access to root: you enroll him to the tempadm  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 temp root access expire...


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Nov 09, 2017] Make sudo work harder

www.linux.com
www.ibm.com/developerworks

Managing sudoers

Over time, your sudoers file will grow with more and more entries, which is to be expected. This could be because more application environments are being placed on the server, or because of splitting the delegation of currents tasks down further to segregate responsibility. With many entries, typos can occur, which is common. Making the sudoers file more manageable by the root user makes good administrative sense. Let's look at two ways this can be achieved, or at least a good standard to build on. If you have many static entries (meaning the same command is run on every machine where sudo is), put these into a separate sudoers file, which can be achieved using the include directive.

Having many entries for individual users can also be time consuming when adding or amending entries. With many user entries, it is good practice to put these into groups. Using groups, you can literally group users together, and the groups are valid AIX groups.

Now look at these two methods more closely.

Include file

Within large-enterprise environments, keeping the sudoers file maintained is an important and regularly required task. A solution to make this chore easier is to reorganize the sudoers file. One way to do this is to extract entries that are static or reusable, where the same commands are run on every box. Like audit/security or storix backups or general performance reports, with sudo you can now use the include directive. The main sudoers file can then contain the local entries, and the include file would barely need editing as those entries are static. When visudo is invoked, it will scan sudoers when it sees the include entry. It will scan that file, then come back to the main sudoers and carry on scanning. In reality, it works like this. When you exit out of visudo from the main sudoers file, it will take you to the include file for editing. Once you quit the include, you are back to the AIX prompt. You can have more than one include file, but I cannot think of a reason why you would want more than one.

Let's call our secondary sudoers file sudo_static.<hostname>. In the examples in this demonstration the hostname I am using is rs6000. In the main sudoers file, make the entry as follows:

1 #include /etc/sudo_static.rs6000

Next, add some entries to the /etc/sudo_static.rs6000 file. You do not have to put in all the sudoers directives or stanzas. If this file contains entries where they are not required, don't include them. For example, my include file contains only the following text, and nothing more.

You can use the %h, instead of typing the actual hostname:

I personally do not use this method because I have experienced returning extra characters on the hostname. This issue is fixed in sudo 1.7.2 p1.

1 2 3 4 bravo rs6000 = (root) NOPASSWD: /usr/opt/db2_08_01/adm/db2licd -end bravo rs6000 = (root) NOPASSWD: /usr/opt/db2_08_01/adm/db2licd bravo rs6000 = (db2inst) NOPASSWD: /home/db2inst/sqllib/adm/db2start bravo rs6000 = (db2inst) NOPASSWD: /home/db2inst/sqllib/adm/db2stop force

When you run visudo, and you save and quit the file, visudo will inform you to click Enter to edit the include sudoers file. Once you have edited the file, sudo will pick up on syntax errors if any, as with the main file. Alternatively, to edit the include file directly, use:

1 visudo -f /etc/sudo_static.rs6000

.

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:

1 2 3 4 5 6 7 8 # 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:

1 2 3 %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.

Timeout with sudo

Sudo has a feature that uses time tickets to determine how long since the last sudo command was run. During this time period, the user can re-run the command without being prompted for the password (that's the user's own password). Once this time allotment has ended, the user is prompted for the password again to re-run the command. If the user gives the correct password, the command is executed, the ticket is then re-set, and the time clock starts all over again. The ticket feature will not work if you have NOPASSWD in the user's entry in sudoers. The default timeout is five minutes. If you wish to change the default value, simply put an entry in sudoers. For example, to set the timeout value for user "bravo" on any commands he runs to 20 minutes, you could use:

1 Defaults:bravo timestamp_timeout=20

To destroy the ticket, as the user, use:

1 $ sudo -k

When the ticket is destroyed, the user will be prompted for his password again, when running a sudo command.

Please do not set the timeout value for all users, as this will cause problems, especially when running jobs in batch and the batch takes longer to run than normal. To disable this feature, use the value -1 in the timestamp_timeout variable. The time tickets are directory entries with the name of the user located in /var/run/sudo.

Those variables

As discussed earlier, sudo will strip out potentially dangerous system variables. To check out what variables are kept and which ones are stripped, use sudo -V . The output will give you a listing of preserved and stripped variables. Stripping out the LIBPATH is clearly an inconvenience. There are a couple of ways around this--either write a wrapper script or specify the environments on the command line. Looking at the wrapper script solution first, suppose you have an application that stops or starts a DB2® instance. You could create a bare-bones script that would keep the variables intact. In Listing 1. rc.db2 , notice that you source the instance profile, which in turn exports various LIBPATH and DB2 environment variables, keeping the environment variable intact, by using:

1 . /home/$inst/sqllib/db2profile

For completeness, the entries in sudoers to execute this is and not strip out any system environment variables are:

1 2 3 4 bravo rs6000 = (dbinst4) NOPASSWD: /home/dbinst4/sqllib/adm/db2start bravo rs6000 = (dbinst4) NOPASSWD: /home/dbinst4/sqllib/adm/db2stop force bravo rs6000 = (dbinst4) NOPASSWD: /usr/local/bin/rc.db2 stop db2inst4 bravo rs6000 = (dbinst4) NOPASSWD: /usr/local/bin/rc.db2 start db2inst4

Note in this example, user "bravo" can execute the above commands as user "dbinst4." Typically, the user would run:

1 2 sudo -u dbinst4 /usr/local/bin/rc.db2 stop db2inst4 sudo -u dbinst4 /usr/local/bin/rc.db2 start db2inst4
Listing 1. rc.db2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 #!/bin/sh # rc.db2 # stop/start db2 instances # check to see if db2 inst is runningdb2_running(){state=`ps -ef |grep db2sysc |grep -v grep| awk '$1=="'${inst}'" { print $1 }'` if [ "$state" = "" ] then return 1 else return 0 fi} usage () { echo "`basename $0` start | stop <instance>" } # stop db2 stop_db2 () { echo "stopping db2 instance as user $inst" if [ -f /home/$inst/sqllib/db2profile ]; then . /home/$inst/sqllib/db2profile else echo "Cannot source DB2..exiting" exit 1 fi /home/$inst/sqllib/adm/db2stop force } # start db2 start_db2 () { echo "starting db2 instance as user $inst" if [ -f /home/$inst/sqllib/db2profile ]; then . /home/$inst/sqllib/db2profile else echo "Cannot source DB2..exiting" exit 1 fi /home/$inst/sqllib/adm/db2start } # check we get 2 params if [ $# != 2 ] then usage exit 1 fi inst=$2 case "$1" in Start|start) if db2_running then echo "db2 instance $inst appears to be already running" exit 0 else echo " instance not running as user $inst..attempting to start it" start_db2 $inst fi ;; Stop|stop) if db2_running then echo "instance running as $inst..attempting to stop it" stop_db2 $inst else echo "db2 instance $inst appears to be not running anyway" exit 0 fi ;; *) usage ;; esac

The other way to preserve system environment variables is to use the Defaults !env_reset directive, like in sudoers:

1 Defaults !env_reset

Then from the command line, specify the environment variable name with its value:

1 $ sudo LIBPATH=″/usr/lib:/opt/db2_09_05/lib64″ -u delta /usr/local/bin/datapmp

If you do not put the !env_reset entry in, you will get the following error from sudo when you try to run the command:

1 sudo: sorry, you are not allowed to set the following environment variables: LIBPATH

If you find that sudo is also stripping out other environment variables, you can specify the variable name in sudoers so that sudo keeps those variables intact (with the Defaults env_keep += directive). For instance, suppose sudo was stripping out the application variables DSTAGE_SUP and DSTAGE_META from one of my suodo-ised scripts. To preserve these variables, I could put the following entries in sudoers:

1 2 Defaults env_keep += "DSTAGE_SUP" Defaults env_keep += "DSTAGE_META"

Notice that I give the variable name and not the variable value. The values are already contained in my script like this:

1 export DSTAGE_SUP=/opt/dstage/dsengine; export DSTAGE_META=/opt/dstage/db2

Now when the sudo script is executed, the above environment variables are preserved.

Securing the sudo path

A default PATH within sudoers can be imposed using the secure_path directive. This directive specifies where to look for binaries and commands when a user executes a sudo command. This option clearly tries to lock down specific areas where a user runs a sudo command, which is good practice. Use the following directive in sudoers, specifying the secure PATH with its search directories:

1 Defaults secure_path="/usr/local/sbin:/usr/local/bin:/opt/freeware/bin:/usr/sbin"
Getting restrictive

Restrictions can be put in place to restrict certain commands to users. Assume you have a group called dataex , whose members are "alpha," "bravo," and "charlie." Now, that group has been allowed to run the sudo command /usr/local/bin/mis_ext * , where the asterisk represents the many parameters passed to the script. However, user "charlie" is not allowed to execute that script if the parameter is import . This type of condition can be met by using the logical NOT '!' operator. Here is how that is achieved in sudoers:

1 2 %dataex rs6000 = (dbmis) NOPASSWD: /usr/local/bin/mis_ext * charlie rs6000 = (dbmis) NOPASSWD: !/usr/local/bin/mis_ext import

Note that the logical NOT operator entries go after the non-restrictive entry. Many conditional NOT entries can be applied on the same line; just make sure that they are comma separated, like so:

1 2 3 4 charlie rs6000 = (dbmis) NOPASSWD: /usr/local/bin/aut_pmp * charlie rs6000 = (dbmis) NOPASSWD: !/usr/local/bin/aut_pmp create, !/usr/local/bin/aut_pmp delete, !/usr/local/bin/aut_pmp amend
When in visudo, do not think just saving the sudo entry and staying in visudo will make the changes effective; it won't. You must exit visudo for the changes to take effect. Rolling out sudo commands

Rolling out sudo commands to remote hosts in an enterprise environment is best done using a ssh script as root, and the keys should have been exchanged between the hosts, for password-less logins. Let's look at one example of how to do this. With geographically remote machines, if you get a hardware issue of some sort (disk or memory), the IBM® engineer will be on-site to replace the failing hardware. There will be occasions when they require the root password to carry out their task. One procedure you might want to put in place is for the engineer to gain access to root they must use sudo. Informing the engineer prior to the visit of the password would be advantageous. Listing 2 demonstrates one way you could roll out this configuration. Looking more closely at Listing 2 , use a for loop containing a list of hosts you are pushing out to. (Generally, though, you would have these hosts in a text file and read them in using a while loop.) Using the 'here' document method, make a backup copy of sudoers, and an entry is then appended to sudoers, like so:

1 2 # -- ibmeng sudo root ibmeng host1 = (root) NOPASSWD:ALL

Next, the user "ibmeng" is created, and the password is set for the user using chpasswd . In this demonstration, it is ibmpw . A message is then appended to their profile, informing the user how to sudo to root. So when the engineer logs in, he is presented with the message:

1 IBM Engineer, to access root account type: sudo -u root su -

Of course the account for ibmeng would be locked after the visit.

Listing 2. dis_ibm
Nov 09, 2017 | www.ibm.com
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 #!/bin/sh # dis_ibm dest_hosts='host1 host2 host3 host4' for host in $dest_hosts do echo "doing [$host]" $ssh -T -t -l root $host<<'mayday' host=`hostname` cp /etc/sudoers /etc/sudoers.bak if [ $? != 0 ] then echo "error: unable to cp sudoers file" exit 1 fi echo "# -- ibmeng sudo root\nibmeng $host = (root) NOPASSWD:ALL">>/etc/sudoers mkuser su=false ibmeng if [ $? = 0 ] then echo "ibmeng:ibmpw" | chpasswd -c else echo "error: unable to create user ibmeng and or passwd" exit 1 fi chuser gecos='IBM engineer acc' ibmeng if [ -f /home/ibmeng/.profile ] then echo "echo \"IBM Engineer, to access root account type: sudo -u root su -"\" >>/home/ibmeng/.profile fi mayday done
Conclusion

Sudo allows you to control who can run what commands as whom. But you must be able to understand the features of sudoers fully to gain maximum understanding of its implications and responsibility.


Downloadable resources
Related topics

[Nov 09, 2017] Understanding sudoers syntax

Nov 09, 2017 | toroid.org

User specifications

The /etc/sudoers file contains "user specifications" that define the commands that users may execute. When sudo is invoked, these specifications are checked in order, and the last match is used. A user specification looks like this at its most basic:

User Host = (Runas) Command

Read this as "User may run Command as the Runas user on Host".

Any or all of the above may be the special keyword ALL, which always matches.

User and Runas may be usernames, group names prefixed with %, numeric UIDs prefixed with #, or numeric GIDs prefixed with %#. Host may be a hostname, IP address, or a whole network (e.g., 192.0.2.0/24), but not 127.0.0.1.

Runas

This optional clause controls the target user (and group) sudo will run the Command as, or in other words, which combinations of the -u and -g arguments it will accept.

If the clause is omitted, the user will be permitted to run commands only as root. If you specify a username, e.g., (postgres), sudo will accept "-u postgres" and run commands as that user. In both cases, sudo will not accept -g.

If you also specify a target group, e.g., (postgres:postgres), sudo will accept any combination of the listed users and groups (see the section on aliases below). If you specify only a target group, e.g., (:postgres), sudo will accept and act on "-g postgres" but run commands only as the invoking user.

This is why you sometimes see (ALL:ALL) in the 90% example.

Commands

In the simplest case, a command is the full path to an executable, which permits it to be executed with any arguments. You may specify a list of arguments after the path to permit the command only with those exact arguments, or write "" to permit execution only without any arguments.

A command may also be the full path to a directory (including a trailing /). This permits execution of all the files in that directory, but not in any subdirectories.

ams ALL=/bin/ls, /bin/df -h /, /bin/date "", \
        /usr/bin/, sudoedit /etc/hosts, \
        OTHER_COMMANDS

The keyword sudoedit is also recognised as a command name, and arguments can be specified as with other commands. Use this instead of allowing a particular editor to be run with sudo, because it runs the editor as the user and only installs the editor's output file into place as root (or other target user).

As shown above, comma-separated lists of commands and aliases may be specified. Commands may also use shell wildcards either in the path or in the argument list (but see the warning below about the latter).

Sudo is very flexible, and it's tempting to set up very fine-grained access, but it can be difficult to understand the consequences of a complex setup, and you can end up with unexpected problems . Try to keep things simple.

Options

Before the command, you can specify zero or more options to control how it will be executed. The most important options are NOPASSWD (to not require a password) and SETENV (to allow the user to set environment variables for the command).

ams ALL=(ALL) NOPASSWD: SETENV: /bin/ls

Other available options include NOEXEC, LOG_INPUT and LOG_OUTPUT, and SELinux role and type specifications. These are all documented in the manpage.

Digests

The path to a binary (i.e., not a directory or alias) may also be prefixed with a digest:

ams ALL=(ALL) sha224:IkotndXGTmZtH5ZNFtRfIwkG0WuiuOs7GoZ+6g== /bin/ls

The specified binary will then be executed only if it matches the digest. SHA-2 digests of 224, 256, 384, and 512-bits are accepted in hex or Base64 format. The values can be generated using, e.g., sha512sum or openssl.

Aliases

In addition to the things listed above, a User, Host, Runas, or Command may be an alias, which is a named list of comma-separated values of the corresponding type. An alias may be used wherever a User, Host, Runas, or Command may occur. They are always named in uppercase, and can be defined as shown in these examples:

# Type_Alias NAME = a, b : NAME_2 = c, d,  

User_Alias TRUSTED = %admin, !ams
Runas_Alias LEGACYUSERS = oldapp1, oldapp2
Runas_Alias APPUSERS = app1, app2, LEGACYUSERS
Host_Alias PRODUCTION = www1, www2, \
    192.0.2.1/24, !192.0.2.222
Cmnd_Alias DBA = /usr/pgsql-9.4/bin, \
    /usr/local/bin/pgadmin

An alias definition can also include another alias of the same type (e.g., LEGACYUSERS above). You cannot include options like NOPASSWD: in command aliases.

Any term in a list may be prefixed with ! to negate it. This can be used to include a group but exclude a certain user, or to exclude certain addresses in a network, and so on. Negation can also be used in command lists, but note the manpage's warning that trying to "subtract" commands from ALL using ! is generally not effective .

Use aliases whenever you need rules involving multiple users, hosts, or commands.

Default options

Sudo has a number of options whose values may be set in the configuration file, overriding the defaults either unconditionally, or only for a given user, host, or command. The defaults are sensible, so you do not need to care about options unless you're doing something special.

Option values are specified in one or more "Defaults" lines. The example below switches on env_reset, turns off insults (read !insults as "not insults"), sets password_tries to 4, and so on. All the values are set unconditionally, i.e. they apply to every user specification.

Defaults env_reset, !insults, password_tries=4, \
    lecture=always
Defaults passprompt="Password for %p:"

Options may also be set only for specific hosts, users, or commands, as shown below. Defaults@host sets options for a host, Defaults:user for a (requesting) user, Defaults!command for a command, and Defaults>user for a target user. You can also use aliases in these definitions.

Defaults@localhost insults
Defaults:ams insults, !lecture
Defaults>root mail_always, mailto="foo@example.org"

Cmnd_Alias FOO = /usr/bin/foo, /usr/bin/bar, \
    /usr/local/bin/baz
Defaults!FOO always_set_home

Unconditional defaults are parsed first, followed by host and user defaults, then runas defaults, then command defaults.

The many available options are explained well in the manpage.

Complications

In addition to the alias mechanism, a User, Host, Runas, or Command may each be a comma-separated list of things of the corresponding type. Also, a user specification may contain multiple host and command sets for a single User. Please be sparing in your use of this syntax, in case you ever have to make sense of it again.

Users and hosts can also be a +netgroup or other more esoteric things, depending on plugins. Host names may also use shell wildcards (see the fqdn option).

If Runas is omitted but the () are not, sudo will reject -u and -g and run commands only as the invoking user.

You can use wildcards in command paths and in arguments, but their meaning is different. In a path, a * will not match a /, so /usr/bin/* will match /usr/bin/who but not /usr/bin/X11/xterm. In arguments, a * does match /; also, arguments are matched as a single string (not a list of separate words), so * can match across words. The manpage includes the following problematic example, which permits additional arguments to be passed to /bin/cat without restriction:

%operator ALL = /bin/cat /var/log/messages*

Warning : Sudo will not work if /etc/sudoers contains syntax errors, so you should only ever edit it using visudo, which performs basic sanity checks, and installs the new file only if it parses correctly.

Another warning: if you take the EBNF in the manpage seriously enough, you will discover that the implementation doesn't follow it. You can avoid this sad fate by linking to this article instead of trying to write your own. Happy sudoing!

[Nov 09, 2017] Make sudo work harder

toroid.org
Managing sudoers

Over time, your sudoers file will grow with more and more entries, which is to be expected. This could be because more application environments are being placed on the server, or because of splitting the delegation of currents tasks down further to segregate responsibility. With many entries, typos can occur, which is common. Making the sudoers file more manageable by the root user makes good administrative sense. Let's look at two ways this can be achieved, or at least a good standard to build on. If you have many static entries (meaning the same command is run on every machine where sudo is), put these into a separate sudoers file, which can be achieved using the include directive.

Having many entries for individual users can also be time consuming when adding or amending entries. With many user entries, it is good practice to put these into groups. Using groups, you can literally group users together, and the groups are valid AIX groups.

Now look at these two methods more closely.

Include file

Within large-enterprise environments, keeping the sudoers file maintained is an important and regularly required task. A solution to make this chore easier is to reorganize the sudoers file. One way to do this is to extract entries that are static or reusable, where the same commands are run on every box. Like audit/security or storix backups or general performance reports, with sudo you can now use the include directive. The main sudoers file can then contain the local entries, and the include file would barely need editing as those entries are static. When visudo is invoked, it will scan sudoers when it sees the include entry. It will scan that file, then come back to the main sudoers and carry on scanning. In reality, it works like this. When you exit out of visudo from the main sudoers file, it will take you to the include file for editing. Once you quit the include, you are back to the AIX prompt. You can have more than one include file, but I cannot think of a reason why you would want more than one.

Let's call our secondary sudoers file sudo_static.<hostname>. In the examples in this demonstration the hostname I am using is rs6000. In the main sudoers file, make the entry as follows:

1 #include /etc/sudo_static.rs6000

Next, add some entries to the /etc/sudo_static.rs6000 file. You do not have to put in all the sudoers directives or stanzas. If this file contains entries where they are not required, don't include them. For example, my include ile contains only the following text, and nothing more.

You can use the %h, instead of typing the actual hostname:

I personally do not use this method because I have experienced returning extra characters on the hostname. This issue is fixed in sudo 1.7.2 p1.

1 2 3 4 bravo rs6000 = (root) NOPASSWD: /usr/opt/db2_08_01/adm/db2licd -end bravo rs6000 = (root) NOPASSWD: /usr/opt/db2_08_01/adm/db2licd bravo rs6000 = (db2inst) NOPASSWD: /home/db2inst/sqllib/adm/db2start bravo rs6000 = (db2inst) NOPASSWD: /home/db2inst/sqllib/adm/db2stop force

When you run visudo, and you save and quit the file, visudo will inform you to click Enter to edit the include sudoers file. Once you have edited the file, sudo will pick up on syntax errors if any, as with the main file. Alternatively, to edit the include file directly, use:

1 visudo -f /etc/sudo_static.rs6000

.

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:

1 2 3 4 5 6 7 8 # 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:

1 2 3 %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.

Timeout with sudo

Sudo has a feature that uses time tickets to determine how long since the last sudo command was run. During this time period, the user can re-run the command without being prompted for the password (that's the user's own password). Once this time allotment has ended, the user is prompted for the password again to re-run the command. If the user gives the correct password, the command is executed, the ticket is then re-set, and the time clock starts all over again. The ticket feature will not work if you have NOPASSWD in the user's entry in sudoers. The default timeout is five minutes. If you wish to change the default value, simply put an entry in sudoers. For example, to set the timeout value for user "bravo" on any commands he runs to 20 minutes, you could use:

1 Defaults:bravo timestamp_timeout=20

To destroy the ticket, as the user, use:

1 $ sudo -k

When the ticket is destroyed, the user will be prompted for his password again, when running a sudo command.

Please do not set the timeout value for all users, as this will cause problems, especially when running jobs in batch and the batch takes longer to run than normal. To disable this feature, use the value -1 in the timestamp_timeout variable. The time tickets are directory entries with the name of the user located in /var/run/sudo.

Those variables

As discussed earlier, sudo will strip out potentially dangerous system variables. To check out what variables are kept and which ones are stripped, use sudo -V . The output will give you a listing of preserved and stripped variables. Stripping out the LIBPATH is clearly an inconvenience. There are a couple of ways around this--either write a wrapper script or specify the environments on the command line. Looking at the wrapper script solution first, suppose you have an application that stops or starts a DB2® instance. You could create a bare-bones script that would keep the variables intact. In Listing 1. rc.db2 , notice that you source the instance profile, which in turn exports various LIBPATH and DB2 environment variables, keeping the environment variable intact, by using:

1 . /home/$inst/sqllib/db2profile

For completeness, the entries in sudoers to execute this is and not strip out any system environment variables are:

1 2 3 4 bravo rs6000 = (dbinst4) NOPASSWD: /home/dbinst4/sqllib/adm/db2start bravo rs6000 = (dbinst4) NOPASSWD: /home/dbinst4/sqllib/adm/db2stop force bravo rs6000 = (dbinst4) NOPASSWD: /usr/local/bin/rc.db2 stop db2inst4 bravo rs6000 = (dbinst4) NOPASSWD: /usr/local/bin/rc.db2 start db2inst4

Note in this example, user "bravo" can execute the above commands as user "dbinst4." Typically, the user would run:

1 2 sudo -u dbinst4 /usr/local/bin/rc.db2 stop db2inst4 sudo -u dbinst4 /usr/local/bin/rc.db2 start db2inst4
Listing 1. rc.db2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 #!/bin/sh # rc.db2 # stop/start db2 instances # check to see if db2 inst is runningdb2_running(){state=`ps -ef |grep db2sysc |grep -v grep| awk '$1=="'${inst}'" { print $1 }'` if [ "$state" = "" ] then return 1 else return 0 fi} usage () { echo "`basename $0` start | stop <instance>" } # stop db2 stop_db2 () { echo "stopping db2 instance as user $inst" if [ -f /home/$inst/sqllib/db2profile ]; then . /home/$inst/sqllib/db2profile else echo "Cannot source DB2..exiting" exit 1 fi /home/$inst/sqllib/adm/db2stop force } # start db2 start_db2 () { echo "starting db2 instance as user $inst" if [ -f /home/$inst/sqllib/db2profile ]; then . /home/$inst/sqllib/db2profile else echo "Cannot source DB2..exiting" exit 1 fi /home/$inst/sqllib/adm/db2start } # check we get 2 params if [ $# != 2 ] then usage exit 1 fi inst=$2 case "$1" in Start|start) if db2_running then echo "db2 instance $inst appears to be already running" exit 0 else echo " instance not running as user $inst..attempting to start it" start_db2 $inst fi ;; Stop|stop) if db2_running then echo "instance running as $inst..attempting to stop it" stop_db2 $inst else echo "db2 instance $inst appears to be not running anyway" exit 0 fi ;; *) usage ;; esac

The other way to preserve system environment variables is to use the Defaults !env_reset directive, like in sudoers:

1 Defaults !env_reset

Then from the command line, specify the environment variable name with its value:

1 $ sudo LIBPATH=″/usr/lib:/opt/db2_09_05/lib64″ -u delta /usr/local/bin/datapmp

If you do not put the !env_reset entry in, you will get the following error from sudo when you try to run the command:

1 sudo: sorry, you are not allowed to set the following environment variables: LIBPATH

If you find that sudo is also stripping out other environment variables, you can specify the variable name in sudoers so that sudo keeps those variables intact (with the Defaults env_keep += directive). For instance, suppose sudo was stripping out the application variables DSTAGE_SUP and DSTAGE_META from one of my suodo-ised scripts. To preserve these variables, I could put the following entries in sudoers:

1 2 Defaults env_keep += "DSTAGE_SUP" Defaults env_keep += "DSTAGE_META"

Notice that I give the variable name and not the variable value. The values are already contained in my script like this:

1 export DSTAGE_SUP=/opt/dstage/dsengine; export DSTAGE_META=/opt/dstage/db2

Now when the sudo script is executed, the above environment variables are preserved.

Securing the sudo path

A default PATH within sudoers can be imposed using the secure_path directive. This directive specifies where to look for binaries and commands when a user executes a sudo command. This option clearly tries to lock down specific areas where a user runs a sudo command, which is good practice. Use the following directive in sudoers, specifying the secure PATH with its search directories:

1 Defaults secure_path="/usr/local/sbin:/usr/local/bin:/opt/freeware/bin:/usr/sbin"
Getting restrictive

Restrictions can be put in place to restrict certain commands to users. Assume you have a group called dataex , whose members are "alpha," "bravo," and "charlie." Now, that group has been allowed to run the sudo command /usr/local/bin/mis_ext * , where the asterisk represents the many parameters passed to the script. However, user "charlie" is not allowed to execute that script if the parameter is import . This type of condition can be met by using the logical NOT '!' operator. Here is how that is achieved in sudoers:

1 2 %dataex rs6000 = (dbmis) NOPASSWD: /usr/local/bin/mis_ext * charlie rs6000 = (dbmis) NOPASSWD: !/usr/local/bin/mis_ext import

Note that the logical NOT operator entries go after the non-restrictive entry. Many conditional NOT entries can be applied on the same line; just make sure that they are comma separated, like so:

1 2 3 4 charlie rs6000 = (dbmis) NOPASSWD: /usr/local/bin/aut_pmp * charlie rs6000 = (dbmis) NOPASSWD: !/usr/local/bin/aut_pmp create, !/usr/local/bin/aut_pmp delete, !/usr/local/bin/aut_pmp amend
When in visudo, do not think just saving the sudo entry and staying in visudo will make the changes effective; it won't. You must exit visudo for the changes to take effect. Rolling out sudo commands

Rolling out sudo commands to remote hosts in an enterprise environment is best done using a ssh script as root, and the keys should have been exchanged between the hosts, for password-less logins. Let's look at one example of how to do this. With geographically remote machines, if you get a hardware issue of some sort (disk or memory), the IBM® engineer will be on-site to replace the failing hardware. There will be occasions when they require the root password to carry out their task. One procedure you might want to put in place is for the engineer to gain access to root they must use sudo. Informing the engineer prior to the visit of the password would be advantageous. Listing 2 demonstrates one way you could roll out this configuration. Looking more closely at Listing 2 , use a for loop containing a list of hosts you are pushing out to. (Generally, though, you would have these hosts in a text file and read them in using a while loop.) Using the 'here' document method, make a backup copy of sudoers, and an entry is then appended to sudoers, like so:

1 2 # -- ibmeng sudo root ibmeng host1 = (root) NOPASSWD:ALL

Next, the user "ibmeng" is created, and the password is set for the user using chpasswd . In this demonstration, it is ibmpw . A message is then appended to their profile, informing the user how to sudo to root. So when the engineer logs in, he is presented with the message:

1 IBM Engineer, to access root account type: sudo -u root su -

Of course the account for ibmeng would be locked after the visit.

Listing 2. dis_ibm
Nov 09, 2017 | www.ibm.com
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 #!/bin/sh # dis_ibm dest_hosts='host1 host2 host3 host4' for host in $dest_hosts do echo "doing [$host]" $ssh -T -t -l root $host<<'mayday' host=`hostname` cp /etc/sudoers /etc/sudoers.bak if [ $? != 0 ] then echo "error: unable to cp sudoers file" exit 1 fi echo "# -- ibmeng sudo root\nibmeng $host = (root) NOPASSWD:ALL">>/etc/sudoers mkuser su=false ibmeng if [ $? = 0 ] then echo "ibmeng:ibmpw" | chpasswd -c else echo "error: unable to create user ibmeng and or passwd" exit 1 fi chuser gecos='IBM engineer acc' ibmeng if [ -f /home/ibmeng/.profile ] then echo "echo \"IBM Engineer, to access root account type: sudo -u root su -"\" >>/home/ibmeng/.profile fi mayday done
Conclusion

Sudo allows you to control who can run what commands as whom. But you must be able to understand the features of sudoers fully to gain maximum understanding of its implications and responsibility.


Downloadable resources
Related topics

[Nov 09, 2017] Example of the sudoers file

Nov 09, 2017 | support.symantec.com

Example of the sudoers file

This is an example of the contents of the sudoers file is located in the /etc directory of the UNIX target computer. This example contains sample configurations required to use the sudo functionality as mentioned in the section Using sudo functionality for querying Oracle UNIX targets .

# User alias specification
##
User_Alias UNIX_USERS = unix1, unix2, unix3
User_Alias BV_CONTROL_USERS = bvunix1, bvunix2, bvunix3
##
# Runas alias specification
Defaults:UNIX_USERS !authenticate
Defaults:BV_CONTROL_USERS !authenticate
##
Runas_Alias SUPER_USERS = root
Defaults logfile=/var/log/sudolog
##
# Cmnd alias specification
##
Cmnd_Alias APPLICATIONS = /usr/sbin/named
Cmnd_Alias AIX_ADMINCMDS = /usr/sbin/lsps, /usr/sbin/lsattr
Cmnd_Alias ADMINCMDS = /usr/sbin/prtconf, /sbin/runlevel, ulimit, AIX_ADMINCMDS,
Cmnd_Alias NETWORKCMDS = /sbin/ifconfig, /usr/local/bin/nslookup, inetadm -p
Cmnd_Alias FILECMDS = /bin/cat, /bin/date '+%Z', /usr/bin/strings -n, \
/usr/bin/diff, /usr/bin/cmp, /usr/bin/find, \
/bin/echo, /usr/bin/file, /bin/df -P, \
/usr/bin/cksum, /bin/ls -la, /bin/ls -lad, \
/bin/ls -lac, /bin/ls -lau
#Cmnd_Alias COMMONCMDS = /usr/bin, /bin, /usr/local/bin
Cmnd_Alias SU = /usr/bin/su
Cmnd_Alias SYSADMCMD = /usr/lib/sendmail
Cmnd_Alias ACTIVEADMCMDS = /usr/sbin/adduser
UNIX_USERS ALL = (SUPER_USERS) APPLICATIONS, NETWORKCMDS, ADMINCMDS, FILECMDS, !SU, !ACTIVEADMCMDS,
!SYSADMCMD, NOPASSWD: ALL
BV_CONTROL_USERS ALL = NOPASSWD: ALL

See Using sudo functionality for querying Oracle UNIX targets .

See Disabling password prompt in the sudoers file .

See Minimum required privileges to query an Oracle database .

[Nov 09, 2017] Add an netgroup in sudoers instead a group

Nov 09, 2017 | hd.free.fr

5 thoughts on "sudo command & sudoers file : Concepts and Practical examples"

  1. Pingback: sudo | Site Title
  2. Andres Ferreo July 16, 2014 at 21:18

    I'll like to add an netgroup in sudoers instead a group. That is possible? How should I do this setup

    Thanks.

    Reply ↓
    1. Pier Post author July 17, 2014 at 22:50

      In order to use a netgroup in the sudoers file, you just need to explicitly define it as a netgroup by using the " + " sign (instead of a " % " sign that would be used for a system group).

      You will need to include this netgroup inside a User_Alias (you may want to create a new User_Alias for this purpose)

      Please check the " 3.1.2 User_Alias " section for more infos, and feel free to ask for more detailed explanation.

      Hope this helps.

      Pier.

      Reply ↓
  3. Matthew February 14, 2014 at 15:43

    Great info, just diving into the world of this, and was trying to figure out how to limit a login to run a cache clearing command

    user ALL=NOPASSWD: rm -rf /usr/nginx/cache/*

    but i got a syntax error

    Reply ↓
    1. Pier Post author February 17, 2014 at 07:22

      Hi,

      Looks like you forgot the following part of the command specs :
      3. (ALL) : This is the part that specify which user(s) you may act as.

      Check the 2.1 Section of the current page, you may want to have something like :
      user ALL=(ALL) NOPASSWD: /sbin/rm -rf /usr/nginx/cache/*

      Always use the full path for any given command : This will prevent you from using a bad aliased command.

[Nov 09, 2017] Sudoers - Community Help Wiki

Nov 09, 2017 | help.ubuntu.com

... ... ...

Aliases

There are four kinds of aliases: User_Alias, Runas_Alias, Host_Alias and Cmnd_Alias. Each alias definition is of the form:

Where Alias_Type is one of User_Alias, Runas_Alias, Host_Alias or Cmnd_Alias. A name is a string of uppercase letters, numbers and underscores starting with an uppercase letter. You can put several aliases of the same type on one line by separating them with colons (:) as so:

You can include other aliases in an alias specification provided they would normally fit there. For example you can use a user alias wherever you would normally expect to see a list of users (for example in a user or runas alias).

There are also built in aliases called ALL which match everything where they are used. If you used ALL in place of a user list it matches all users for example. If you try and set an alias of ALL it will be overridden by this built in alias so don't even try.

User Aliases

User aliases are used to specify groups of users. You can specify usernames, system groups (prefixed by a %) and netgroups (prefixed by a +) as follows:

 # Everybody in the system group "admin" is covered by the alias ADMINS
 User_Alias ADMINS = %admin
 # The users "tom", "dick", and "harry" are covered by the USERS alias
 User_Alias USERS = tom, dick, harry
 # The users "tom" and "mary" are in the WEBMASTERS alias
 User_Alias WEBMASTERS = tom, mary
 # You can also use ! to exclude users from an alias
 # This matches anybody in the USERS alias who isn't in WEBMASTERS or ADMINS aliases
 User_Alias LIMITED_USERS = USERS, !WEBMASTERS, !ADMINS
Runas Aliases

Runas Aliases are almost the same as user aliases but you are allowed to specify users by uid's. This is helpful as usernames and groups are matched as strings so two users with the same uid but different usernames will not be matched by entering a single username but can be matched with a uid. For example:

 # UID 0 is normally used for root
 # Note the hash (#) on the following line indicates a uid, not a comment.
 Runas_Alias ROOT = #0
 # This is for all the admin users similar to the User_Alias of ADMINS set earlier 
 # with the addition of "root"
 Runas_Alias ADMINS = %admin, root
Host Aliases

A host alias is a list of hostname, ip addresses, networks and netgroups (prefixed with a +). If you do not specify a netmask with a network the netmask of the hosts ethernet interface(s) will be used when matching.

 # This is all the servers
 Host_Alias SERVERS = 192.168.0.1, 192.168.0.2, server1
 # This is the whole network
 Host_Alias NETWORK = 192.168.0.0/255.255.255.0
 # And this is every machine in the network that is not a server
 Host_Alias WORKSTATIONS = NETWORK, !SERVER
 # This could have been done in one step with 
 # Host_Alias WORKSTATIONS = 192.168.0.0/255.255.255.0, !SERVERS
 # but I think this method is clearer.
Command Aliases

Command aliases are lists of commands and directories. You can use this to specify a group of commands. If you specify a directory it will include any file within that directory but not in any subdirectories.

The special command '"sudoedit"' allows users to run sudo with the -e flag or as the command sudoedit . If you include command line arguments in a command in an alias these must exactly match what the user enters on the command line. If you include any of the following they will need to be escaped with a backslash (\): ",", "\", ":", "=".

Examples:

 # All the shutdown commands
 Cmnd_Alias SHUTDOWN_CMDS = /sbin/poweroff, /sbin/reboot, /sbin/halt
 # Printing commands
 Cmnd_Alias PRINTING_CMDS = /usr/sbin/lpc, /usr/sbin/lprm
 # Admin commands
 Cmnd_Alias ADMIN_CMDS = /usr/sbin/passwd, /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermod, /usr/sbin/visudo
 # Web commands
 Cmnd_Alias WEB_CMDS = /etc/init.d/apache2
User Specifications

User Specifications are where the sudoers file sets who can run what as who. It is the key part of the file and all the aliases have just been set up for this very point. If this was a film this part is where all the key threads of the story come together in the glorious unveiling before the final climatic ending. Basically it is important and without this you ain't going anywhere.

A user specification is in the format

<user list> <host list> = <operator list> <tag list> <command list>

The user list is a list of users or a user alias that has already been set, the host list is a list of hosts or a host alias, the operator list is a list of users they must be running as or a runas alias and the command list is a list of commands or a cmnd alias.

The tag list has not been covered yet and allows you set special things for each command. You can use PASSWD and NOPASSWD to specify whether the user has to enter a password or not and you can also use NOEXEC to prevent any programs launching shells themselves (as once a program is running with sudo it has full root privileges so could launch a root shell to circumvent any restrictions in the sudoers file.

For example (using the aliases and users from earlier)

 # This lets the webmasters run all the web commands on the machine 
 # "webserver" provided they give a password
 WEBMASTERS webserver= WEB_CMDS
 # This lets the admins run all the admin commands on the servers
 ADMINS SERVERS= ADMIN_CMDS
 # This lets all the USERS run admin commands on the workstations provided 
 # they give the root password or and admin password (using "sudo -u <username>")
 USERS WORKSTATIONS=(ADMINS) ADMIN_CMDS
 # This lets "harry" shutdown his own machine without a password
 harry harrys-machine= NOPASSWD: SHUTDOWN_CMDS
 # And this lets everybody print without requiring a password
 ALL ALL=(ALL) NOPASSWD: PRINTING_CMDS
The Default Ubuntu Sudoers File

The sudoers file that ships with Ubuntu 8.04 by default is included here so if you break everything you can restore it if needed and also to highlight some key things.

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults    env_reset

# Uncomment to allow members of group sudo to not need a password
# %sudo ALL=NOPASSWD: ALL

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

This is pretty much empty and only has three rules in it. The first ( Defaults env_reset ) resets the terminal environment after switching to root. So, ie: all user set variables are removed. The second ( root ALL=(ALL) ALL ) just lets root do everything on any machine as any user. And the third ( %admin ALL=(ALL) ALL ) lets anybody in the admin group run anything as any user. Note that they will still require a password (thus giving you the normal behaviour you are so used to).

If you want to add your own specifications and you are a member of the admin group then you will need to add them after this line. Otherwise all your changes will be overridden by this line saying you (as part of the admin group) can do anything on any machine as any user provided you give a password.

Common Tasks

This section includes some common tasks and how to accomplish them using the sudoers file.

Shutting Down From The Console Without A Password

Often people want to be able to shut their computers down without requiring a password to do so. This is particularly useful in media PCs where you want to be able to use the shutdown command in the media centre to shutdown the whole computer.

To do this you need to add some cmnd aliases as follows:

Cmnd_Alias SHUTDOWN_CMDS = /sbin/poweroff, /sbin/halt, /sbin/reboot

You also need to add a user specification (at the end of the file after the " %admin ALL = (ALL) ALL " line so it takes effect - see above for details):

<your username> ALL=(ALL) NOPASSWD: SHUTDOWN_CMDS

Obviously you need to replace "<your username>" with the username of the user who needs to be able to shutdown the pc without a password. You can use a user alias here as normal.

Multiple tags on a line

There are times where you need to have both NOPASSWD and NOEXEC or other tags on the same configuration line. The man page for sudoers is less than clear, so here is an example of how this is done:

myuser ALL = (root) NOPASSWD:NOEXEC: /usr/bin/vim

This example lets the user "myuser" run as root the "vim" binary without a password, and without letting vim shell out (the :shell command).

Enabling Visual Feedback when Typing Passwords

As of Ubuntu 10.04 (Lucid), you can enable visual feedback when you are typing a password at a sudo prompt.

Simply edit /etc/sudoers and change the Defaults line to read:

Defaults        env_reset,pwfeedback
Troubleshooting

If your changes don't seem to have had any effect, check that they are not trying to use aliases that are not defined yet and that no other user specifications later in the file are overriding what you are trying to accomplish.

[Aug 01, 2014] How to make Shared Keys .ssh/authorized_keys and sudo work together?

I've setup the .ssh/authorized_keys and am able to login with the new "user" using the pub/private key ... I have also added "user" to the sudoers list ... the problem I have now is when I try to execute a sudo command, something simple like:
$ sudo cd /root

it will prompt me for my password, which I enter, but it doesn't work (I am using the private key password I set)

Also, ive disabled the users password using

$ passwd -l user

What am I missing?

Somewhere my initial remarks are being misunderstood ...

I am trying to harden my system ... the ultimate goal is to use pub/private keys to do logins versus simple password authentication. I've figured out how to set all that up via the authorized_keys file.

Additionally I will ultimately prevent server logins through the root account. But before I do that I need sudo to work for a second user (the user which I will be login into the system with all the time).

For this second user I want to prevent regular password logins and force only pub/private key logins, if I don't lock the user via" passwd -l user ... then if i dont use a key, i can still get into the server with a regular password.

But more importantly I need to get sudo to work with a pub/private key setup with a user whos had his/her password disabled.


Edit: Ok I think I've got it (the solution):

1) I've adjusted /etc/ssh/sshd_config and set PasswordAuthentication no This will prevent ssh password logins (be sure to have a working public/private key setup prior to doing this

2) I've adjusted the sudoers list visudo and added

root      ALL=(ALL) ALL
dimas     ALL=(ALL) NOPASSWD: ALL

3) root is the only user account that will have a password, I am testing with two user accounts "dimas" and "sherry" which do not have a password set (passwords are blank, passwd -d user)

The above essentially prevents everyone from logging into the system with passwords (a public/private key must be setup).

Additionally users in the sudoers list have admin abilities. They can also su to different accounts. So basically "dimas" can sudo su sherry, however "dimas can NOT do su sherry. Similarly any user NOT in the sudoers list can NOT do su user or sudo su user.

NOTE The above works but is considered poor security. Any script that is able to access code as the "dimas" or "sherry" users will be able to execute sudo to gain root access. A bug in ssh that allows remote users to log in despite the settings, a remote code execution in something like firefox, or any other flaw that allows unwanted code to run as the user will now be able to run as root. Sudo should always require a password or you may as well log in as root instead of some other user.

ssh and sudo have nothing to do with each other. Setting up an ssh authentication method isn't going to do anything for sudo. sudo isn't going to understand an ssh password.

passwd -l is intended to lock a user's account, so that he can no longer authenticate by password. That's pretty much the opposite of what you want, which is letting the user authenticate without a password.

I think what you want is the NOPASSWD option in your sudoers file.

(PS, there's no reason to be running a cd command with sudo. cd does not propagate to parent processes, so as soon as the sudo exits, you're back where you started.)

Edit: You keep saying that you want to lock the account password and want sudo to understand public/private keys. Sorry, sudo isn't going to use ssh keys. It isn't ssh. If you don't want users to be able to log in with their passwords, I think the answer is to disable ssh password authentication, not to lock the account. Then you can retain a password for the users, which they can use to sudo after they log in via ssh authorized_keys.

coneslayer
ok, but does the fact that the user has no password via: passwd -l user ... cause the sudo command not to work? –

farinspace Jul 15 '10 at 16:40

@farinspace Yes, I understand the question better and have substantially expanded my remarks. passwd -l removes the password in the sense that the account is LOCKED--that is, no password will work. You want to turn off password authentication in sudo. –
coneslayer Jul 15 '10 at 16:46
how is this logic: turning off the password in the sudoers file would still be secure, as the system is hardened via the pub/private key logins ... and again only admin would be able to add users to sudoers list –

farinspace Jul 15 '10 at 18:53

when using a private key is it typical to set a password for it, or is it secure enough to simply not have it set and bypass any password entry on server login –

farinspace Jul 15 '10 at 19:37
@coneslayer this reply is not 100% accurate. As you can see below, sudo can be configured to respect ssh authentication. –
Andre de Miranda Oct 10 '12 at 12:29
What you want to do is possible but it will require some experience as you will have to compile a PAM module called pam-ssh-agent-auth.

The process is reasonably simple:

$ sudo aptitude install libssl-dev libpam0g-dev build-essential checkinstall
$ wget "http://downloads.sourceforge.net/project/pamsshagentauth/pam_ssh_agent_auth/v0.9.3/pam_ssh_agent_auth-0.9.3.tar.bz2"
$ tar -xjvf pam_ssh_agent_auth-0.9.3.tar.bz2
$ cd pam_ssh_agent_auth-0.9.3

$ ./configure --libexecdir=/lib/security --with-mantype=man

$ make
$ sudo checkinstall

The edit the sudo configuration:

$ sudo visudo

Add the following:

Defaults env_keep += SSH_AUTH_SOCK

Continue by changing the sudo PAM settings:

$ sudo vi /etc/pam.d/sudo

Add (just above the @include lines):

**auth [success=2 default=ignore] pam_ssh_agent_auth.so file=~/.ssh/authorized_keys**
@include common-auth
@include common-account
 

Sudo authentication with libpam-ssh-agent

Sep 28, 2010 | projects.tryphon.eu

With virtualization environments, a simple infrastructure contains easily 15/20 hosts. Administrators often have to perform operations across several hosts. One of the consequences : a (good) administrator has to input his passwords to "unlock" sudo several dozen times per day.

There are many bad solutions. Good ones are not so numerous. We're testing one of them for 2 weeks : libpam-ssh-agent or pam ssh agent auth (its original name).

The principle is simple : you're already using a password-less authentication for ssh. libpam-ssh-agent provides a solution to use this mechanism in every pam configuration. It looks like a real good solution for sudo authentication.

Configure libpam-ssh-agent

A small example with your laptop and one of your servers : your ssh dsa/rsa private/public key pair is on your laptop, it has a strong passphrase (or … create a new one !). A ssh-agent allows you to enter this passphrase less frequently.

On your server, install libpam-ssh-agent. The libpam-ssh-agent debian packages are available in our repository debian.tryphon.eu :

apt-get install libpam-ssh-agent

Change the server sudo pam configuration /etc/pam.d/sudo to authenticate users via pam_ssh_agent_auth :

auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
auth requisite pam_unix.so nullok_secure

@include common-account

session required pam_permit.so
session required pam_limits.so

In this configuration, each user can authorize its own keys. If you don't trust them enough, use a file managed by you (like /etc/security/authorized_keys).

Allow the ssh authentication socket to be accessible in the a sudo environment by adding this line in the server /etc/sudoers :

Defaults env_keep += SSH_AUTH_SOCK

Here is the puppet snippet for this server configuration.

Use libpam-ssh-agent

Connect you to the server from your laptop by forwarding the connection to the authentication agent (the -A ssh option) :

laptop$ ssh -A your.server.tld
server$

A sudo should not ask your password (if needed, use sudo -K to clear our time stamp) :

server$ sudo /bin/true
server$ 

Sudo should use pam_ssh_agent_auth to authenticate you :

server$ tail /var/log/auth.log
Sep 28 21:13:58 www sudo[30348]: pam_ssh_agent_auth: Authenticated: ...

Into your ~/.ssh/config, you can add :

Host *.myservers.priv
ForwardAgent yes

Ssh agent

Most environments (KDE, Gnome, etc) provide ssh agent implementations (with nice graphical interface or not).

Choose a smart timeout to keep your key(s) safe when your laptop is alone during your coffee pause.

Read this dpkg's post You should be using ssh-agent on Debian Administration.

libpam-ssh-agent debian package

The libpam-ssh-agent isn't provided by Debian (or Ubuntu) for the moment (see ITP #595817).

But we created a first package. libpam-ssh-agent binaries are available for lenny i386 and amd64 on debian.tryphon.eu.

The package sources are available in this git repository.

Create an ssh key …

If you need to create a (new) ssh key, backup existing one :

$ rename 's/(.*)/$1.bak/' ~/.ssh/id_[rd]sa*

To create a new DSA key :

$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in ~/.ssh/id_dsa.
Your public key has been saved in ~/.ssh/id_dsa.pub.
The key fingerprint is:
5e:9f:8c:b4:84:57:5b:23:67:18:37:57:6e:d8:27:2d alban@hyppo
The key's randomart image is:
+--[ DSA 1024]----+
|            . o +|
|             + B |
|            + E *|
|         . . * =.|
|        S = .    |
|       . = = .   |
|        . o +    |
|                 |
|                 |
+-----------------+

If needed, you can use the previous key by using the -i ssh options :

ssh -i ~/.ssh/id_rsa.bak ...

How To Create SSH Keys with PuTTY to Connect to a VPS DigitalOcean

Take Control of your Linux sudoers file How to with Examples

Written by Guillermo Garron .
Date: 2012-05-22 14:56:30 +0000

... ... ....

In order to use sudo you first need to configure the sudoers file. The sudoers file is located at /etc/sudoers. And you should not edit it directly, you need to use the visudo command.

Once you enter visudo command, you will see something like this:

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

Almost all lines are commented out, the one that matters in this sudoers file example is:

root ALL=(ALL) ALL

This line means: The root user can execute from ALL terminals, acting as ALL (any) users, and run ALL (any) command.

The first part is the user, the second is the terminal from where the user can use sudo command, the third part is which users he may act as, and the last one, is which commands he may run when using sudo.

sudoers examples

operator ALL= /sbin/poweroff

The above command, makes the user operator can from any terminal, run the command power off.

You can also create aliases for: users -> User_Alias, run commands as other users -> Runas_Alias, host -> Host_Alias and command -> Cmnd_Alias

User_Alias OPERATORS = joe, mike, jude 
Runas_Alias OP = root, operator 
Host_Alias OFNET = 10.1.2.0/255.255.255.0 
Cmnd_Alias PRINTING = /usr/sbin/lpc, /usr/bin/lprm

As you can see the alias OPERATORS includes the users joe, mike and jude, the alias OP includes the users root and operator, alias OFNET includes the network 10.1.2.0 (all the C class), and the command alias PRINTING includes the commands lpc and lprm.

So, a typical sudoers file may look like this:

 User_Alias     OPERATORS = joe, mike, jude
 Runas_Alias    OP = root, operator
 Host_Alias     OFNET = 10.1.2.0/255.255.255.0
 Cmnd_Alias     PRINTING = /usr/sbin/lpc, /usr/bin/lprm

OPERATORS ALL=ALL

#The users in the OPERATORS group can run any command from
 any terminal.

linus ALL=(OP) ALL

# The user linus can run any command from any terminal as any 
user in the OP group (root or operator).

user2 OFNET=(ALL) ALL

# user user2 may run any command from any machine in the 
OFNET network, as any user.

user3 ALL= PRINTING

# user user3 may run lpc and lprm from any machine.

go2linux ALL=(ALL) ALL

# user go2linux may run any command from any machine acting
 as any user. (like Ubuntu)

If you want not to be asked for a password use this form:

go2linux ALL=(ALL) NOPASSWD: ALL

[May 24, 2012] Sudo Netmask Matching Security Bypass Vulnerability

As of May 24, 2012 the current stable release of sudo is 1.8.5p1.
May 17, 2012

A vulnerability has been reported in Sudo, which can be exploited by malicious users to bypass certain security restrictions.

The vulnerability is caused due to an error within the network matching mechanism when processing hosts based on the IPv4 netmask. This can be exploited to execute commands from otherwise restricted hosts.

Successful exploitation requires that the user exists in the sudoers file and is granted access to commands on hosts on one or more IPv4 networks.

The vulnerability is reported in versions 1.6.9p3 through 1.8.4p4.

Solution:

Update to version 1.8.4p5 or 1.7.9p1.

Provided and/or discovered by: Jan Lieskovsky (Red Hat).

Original Advisory:

[Feb 17, 2011] Sudoers file

Jan 21, 2011 | IT Resource Center forums

ozas (Question Author )

Hi,

Please just a quick one. Does any one know how I can restrict users from being able to switch to root in sudoers file?? Presently the users are defined in the sudoers file and could switch to another user without password but I do not want them to be able to switch to root.

Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click here

Patrick Wallek

:Use a command alias like this:

Cmnd_Alias SU=!/usr/bin/su -, !/usr/bin/su *root* 

Add this to each user and they should not be able to su to root.

ozas ( Question Author )

I have tried that before it did not work. See below my sudoers file, maybe I need to change anything.

This is the sudoers file:

# User_Alias 
User_Alias WAS = g343ahe,m017ahe,y073ahe 
User_Alias SUPPORT = d060ahe,h070ahe,s029ahe  
#User privilege specification
root ALL=(ALL) ALL SUPPORT ALL=(ALL) ALL
SUPPORT ALL=(ALL) NOPASSWD: ALL WAS 
ALL=(ALL) NOPASSWD: ALL WAS ALL=/usr/bin/su - wasdevadmin,/bin/su - wasdevadmin  

What I want is that the users in WAS should not be able to switch to root, but they should be able to switch to user "wasdevadmin". Only users in SUPPORT should be able to switch to root.

Jeff Traigle:

> WAS ALL=(ALL) NOPASSWD: ALL
> WAS ALL=/usr/bin/su - wasdevadmin,/bin/su - wasdevadmin

The first line is saying to allow the WAS users to run any command on any host as any user. The second line is redundantly saying to allow WAS users to run the su commands specified on all hosts as root. You don't have anything restricting them from running su to root as a previous post stated to do.

Patrick Wallek:

What about the following:

WAS ALL=!/usr/bin/su -, !/usr/bin/su *root*, /usr/bin/su - wasdevadmin,/bin/su - wasdevadmin

You also have 2 lines for WAS. I don't remember which will take priority, but the 2 may be conflicting.

What happens if you comment out the first WAS line?

ofure:

Thanks for your prompt reply. This has partly resolved the issue. At least users in WAS cannot su to root again but now the WAS cannot switch to wasdevadmin user.

I want a situation where they can switch to wasdevadmin without been prompted for a password.

Matti Kurkela:

> I want a situation where they [= the users in sudo group WAS] can switch to wasdevadmin without been prompted for a password.

You need this line in your sudoers file:

WAS ALL=(wasdevadmin) NOPASSWD: ALL

Then tell your users to use the sudo command like this:

sudo -H -u wasdevadmin -i (to run a shell as wasdevadmin; equivalent to "sudo su - wasdevadmin")

...or like this:

sudo -H -u wasdevadmin <command> (to run <command> as wasdevadmin and then continue the session as themselves)

MK

ofure:

Below is how my sudoers file now look:

User_Alias WAS = g343ahe,m017ahe,y073ahe,y072ahe,h234ahe,r019ahe

User_Alias SUPPORT = d060ahe,h070ahe,s029ahe #User privilege specification root ALL=(ALL) ALL SUPPORT ALL=(ALL) ALL SUPPORT ALL=(ALL) NOPASSWD: ALL WAS ALL=!/usr/bin/su -, !/usr/bin/su *root*, /usr/bin/su - wasdevadmin,/bin/su - wasdevadmin WAS ALL=(wasdevadmin) NOPASSWD: ALL

But the users in WAS still cannot switch to wasdevadmin account. I want the users in WAS to be able to do this without prompting for password. Thanks. Regards.

INH :

Remove the user name you dont wantthem to do sudo to root in sudoers file

if you have to grant specfic access you can grant in sudoers file for required users. by defining user alias, command alias and host alias for those users

ofure:

;The challenge I have now is that I want the users in WAS to be able to switch to the account wasdevadmin without prompting for password. I have tried this below but did not work.

WAS ALL=(wasdevadmin) NOPASSWD: ALL

Regards,

Matti Kurkela Jan 24, 2011 15:49:55 GMT Unassigned

> WAS ALL=(wasdevadmin) NOPASSWD: ALL

When you use this sudoers line, your user *must* use "sudo -u wasdevadmin -i" or similar sudo command to become wasdevadmin. The "-H" option is optional, but probably in line with the user's expectations.

With this sudoers line, a command like "sudo su wasdevadmin" or "sudo su - wasdevadmin" will *not* work. This is because these commands first use sudo to become root, then use su to become the target user. Sudo can do it in one step - but it requires that the user uses the correct syntax.

MK

ofure:

Hi All,

When I type this: sudo -u wasdevadmin -i it works without prompting me for password but it is a long command. I want to be able to type su - wasdevadmin and for it to call up sudo -u wasdevadmin -i

Presently, I have this configuration:

#cd /bin # ls -l su* root root 45 Feb 16 17:17 su root root 28336 Oct 30 2008 su.original

# cat su sudo su.original $@

So presently when I type su -, it call up sudo su.original, which works fine for my switching to root access. How can I also have: "sudo -u wasdevadmin -i" equal to "su - wasdevadmin"

Thanks.

ofure:

I have resolved this by creating an alias for wasdevadmin.

Thanks all.

Tags: Sudo, Sudo for HPUX

[Oct 17, 2009] Make sudo work harder

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

Using groups

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

# lsgroup -f -a users devops

devops:
        users=joex,delta,charlie,tstgn

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

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

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

We could have the following sudoers entries:

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

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

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

It's better to have sudo file standard and periodically overwritable from baseline as unauthorized (and undetected) modifications of the sudoer file is a security risk. Enrollment of users should be done via adding them to a privileged group such as wheel.
LG #166

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.

Running Complex Commands with sudo

Linux Journal

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

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

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

But, this fails too:

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

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

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

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

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

Secure Cooking with Linux, Part 2

O'Reilly

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.

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

Sudoers Syntax

Basic Syntax>

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

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

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:

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

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:

$ sudo emerge -uDN world

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

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

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

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

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

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

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:

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:

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!

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:

users  hosts = (run-as) commands

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

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:

$ 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):

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:

Defaults:john   runaspw, passwd_tries=2

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

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:

swift     localhost = NOPASSWD: /usr/bin/emerge

3. Using Sudo

Listing Privileges

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

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

$ sudo -v

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

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

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

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

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

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

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

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

# Command aliases

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

# The rights: who gets to run what

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

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

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

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

[Jan 30, 2008] Sudo FAQ

polishlinux.org

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

user computer = command

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

johnny localhost = /usr/bin/du

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

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

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

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

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

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

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

[Jan 30, 2008] Eliminating Root with Sudo

ONLamp.com

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

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

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

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

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

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

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

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

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

admin    ALL=(ALL) ALL

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

targetpw

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

Defaults    targetpw

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

NOPASSWD

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

admin    ALL = NOPASSWD: ALL

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

authenticate

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

Defaults    !authenticate

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

admin    ALL=(ALL) PASSWD: ALL

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

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

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

[Oct 27, 2007] RootSudo - Community Ubuntu Documentation

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

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

     joe            ALL = /usr/bin/su operator

    Sys Admin Magazine RBAC instead of sudo

    SUMMARY sudo vs RBAC

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

    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.

    Recommended Links

    Google matched content

    Softpanorama Recommended

    Top articles

    Sites

    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.

    sudo - Wikipedia

    4.2. The sudo Command - Red Hat Customer Portal

    Sys Admin Magazine RBAC instead of sudo

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

    A Brief History of Sudo

    sudo-tools - some handy utilities for sudo

    Other Sudo-like Utilities

    Sudo at a VERY LARGE site by Alek Komarnitsky

    Using Sudo -- article by A.P. Lawrence

    Managing Root Access with Sudo. About.com

    Installing sudo on Solaris

    ONLamp.com Eliminating Root with Sudo

    RootSudo - Community Ubuntu Documentation

    Linux Help - Sudo Setup Guide

    Sudo and other ways to avoid root!



    Etc

    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 in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

    ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

    Society

    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

    Quotes

    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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

    Bulletin:

    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

    History:

    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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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

    Classic books:

    The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow 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-2016 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. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

    The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

    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

    Disclaimer:

    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: December 26, 2017