Networking

USER_ADMIN alias

Sudo is a means to allow normal users limited root access. Sudo is also very versatile and can run across several servers. Here, Jim McIntyre gives you the lowdown on more advanced sudo configurations.


In this Daily Drill Down, we will continue our look at the sudo utility. In the first Daily Drill Down of this two-part series, we looked at the installation and configuration of sudo and we configured the /etc/sudoers file for a single server. Today we will cover the following topics:
  • Configuring sudo for multiple servers
  • Using sudo with Pluggable Authentication Modules (PAM)
  • Disabling the su command
  • The sudo logging process
  • Sudo security vulnerabilities

Using sudo with multiple servers
The /etc/sudoers file in Example A shows how sudo may be configured to provide root access to users on a network with several servers.
#Host_Alias Section.
Host_Alias DATABASE=ora-db1,ora-db2
Host_Alias ADMIN=+admin-servers
Host_Alias FINANCE-NET=192.168.12.0/255.255.224.0,10.26.11.0/255.255.192.0
#
#Command_Alias Section
#
Cmnd_Alias BOOT=/sbin/reboot,/sbin/shutdown -r *,/sbin/init 6
Cmnd_Alias SU=/bin/su
Cmnd_Alias SHELL=/bin/bash,/bin/tchs,/bin/csh,/bin/ksh, \
  /bin/zsh,/bin/sh
Cmnd_Alias USER_ADMIN=/usr/bin/useradd,/usr/sbin/userdel,/usr/sbin/userhelper, \
 /usr/sbin/usermod, /usr/sbin/usernetctl,/usr/sbin/adduser, \
 /usr/sbin/groupadd, /usr/sbin/groupdel
Cmnd_Alias PASS=/usr/bin/passwd -u root, \
  /usr/bin chage -m ? -W [3-7] * root, \
  /usr/sbin/useradd *-r*,/usr/sbin/useradd *-o*, \
  /usr/sbin/usermod *,/usr/sbin/groupmod *, \
  /usr/sbin/groupadd *-r*,/usr/sbin/group *
Cmnd_Alias HACKS=*cp * */*bin* *,*mv * */*bin* *,*ln,*mkfile,*mknod,*chown,*chmod
Cmnd_Alias DIST=/usr/bin/make -f /var/yp/Makefile,/bin/vi /etc/yp/*
#
#Runas_Alias Section
#
Runas_Alias DB-ADMIN=root,oracle-admin
#
#User_Alias Section
#
User_Alias SYS-ADMINS=root,jim,susan
User_Alias ORACLE-ADMINS=carol,ted
User_Alias USER-ADMINS=bob,alice,jim
User_Alias NET-ADMINS=root,jim
User_Alias TEMP-ADMINS=joe,linda
#
#Privileges_Section
#
SYS_ADMIN ALL=(ALL) ALL
ORACLE-ADMINS DATABASE=(DB-ADMIN) !PASS,!DIST,!SHELL,!SU
TEMP_ADMINS FINANCE-NET=ALL:ADMIN=!PASS,!HACKS,!SHELL
%wheel ADMIN=ALL
Now let’s take a look at this file and see how we have configured sudo. The first section is the Host_Alias section. This section may contain simple lists of hosts, netgroups, or a group of subnets listed by IP address:
#Host_Alias Section.

In the first entry, we have established a Host_Alias for two Oracle database servers, ora-admin1 and ora-admin2:
Host_Alias DATABASE=ora-db1,ora-db2

The next line establishes the ADMIN netgroup, consisting of all admin servers:
Host_Alias ADMIN=+admin-servers

The last entry in the Host_Alias section establishes the FINANCE_NET alias. This alias consists of all hosts on the 192.168.12.0 subnet and all hosts on the 10.26.11.0 subnet. Note that this entry contains both the network addresses and the subnet masks for these networks:
Host_Alias FINANCE-NET=192.168.12.0/255.255.224.0,10.26.11.0/255.255.192.0

Now we create the Command Aliases. This is where the commands used in the User_Privilege section are defined. In this example, we introduce metacharacters to the /etc/sudoers file:
#Command_Alias

The first Command Alias we define is the BOOT alias. This alias will expand to any of the three commands listed in the next line. The use of an asterisk metacharacter (*) in the /sbin/shutdown -r command allows authorized users to specify a time when using this command. Commands that would allow for system changes other than a reboot are limited to executing a reboot only. We accomplish this by including the command /sbin/init 6, which will run only if the command is explicitly requested:
Cmnd_Alias BOOT=/sbin/reboot,/sbin/shutdown -r *,/sbin/init 6

The next alias is straightforward. It is a simple alias for the su command. Remember, by including a command or directory in this section, we are also able to prevent its use in the Privileges section:
Cmnd_Alias SU=/bin/su

The SHELL alias helps the administrator assign or deny the ability to execute any shell listed in this alias:
Cmnd_Alias SHELL=/bin/bash,/bin/tchs,/bin/csh,/bin/ksh, \
 /bin/zsh,/bin/sh


The USER_ADMIN alias lists the commands to add, delete, and modify user accounts, as shown here.
Cmnd_Alias USER_ADMIN=/usr/bin/useradd,/usr/sbin/userdel,/usr/sbin/userhelper, \
/usr/sbin/usermod, /usr/sbin/usernetctl,/usr/sbin/adduser, \
/usr/sbin/groupadd, /usr/sbin/groupdel
The next line in this alias is used to set the parameters for the chage command. This requires that exactly one character be entered after the - option, which sets the minimum number of days before a password may be changed.

The option -W [3-7] requires that one number, from three to seven, be entered after the -W character. This establishes the number of days before password expiration that a user is warned.

The next option, * ?*, allows for more arguments or options to be used with the chage command. These options or arguments must be followed by at least one character:
/usr/bin/chage -m ? -W [3-7] * ?*

The next command is the PASS alias:
Cmnd_Alias PASS=/usr/bin/passwd -u root, \

The following entry establishes control over the password expiration date:
/usr/bin chage -m ? -W [3-7] * root, \

This entry establishes control over the ability to create system user accounts:
/usr/sbin/useradd *-r*,/usr/sbin/useradd *-o*, \

This entry controls the modification of user accounts:
/usr/sbin/usermod *,/usr/sbin/groupmod *, \

This entry controls the creation of new groups:
/usr/sbin/groupadd *-r*,/usr/sbin/group *

The aliases
The HACKS alias is used to identify commands that may be used to gain unauthorized access to the system. The first two entries, *cp */*bin* * and *mv * */bin* *, match any attempt to copy or move any file or command with bin in the filename or PATH. The next four entries match any attempt to run the link files, create special character or block files, change the ownership of any file, or change the permissions of any file:
Cmnd_Alias HACKS=*cp * */*bin* *,*mv * */*bin* *,*ln,*mkfile,*mknod,*chown,*chmod

The DIST alias is used to grant users the minimum access required for maintaining NIS. Users granted these privileges are allowed to edit the /etc/yap directory. This command is also used to grant permission to compile the Makefile located in /var/yp, which allows network mappings to be converted to the appropriate format and exported to other servers:
Cmnd_Alias DIST=/usr/bin/make -f /var/yp/Makefile,/bin/vi /etc/yp/*

There is only one Runas alias, DB_ADMIN. This alias defines the users, root and oracle-admin, who may be selected with the command sudo -u <username>:
Runas_Alias DB-ADMIN=root,oracle-admin

The User_Alias section is straightforward. It simply assigns users to specified aliases:
User_Alias SYS-ADMINS=root,jim,susan
User_Alias ORACLE-ADMINS=carol,ted
User_Alias USER-ADMINS=bob,alice,jim
User_Alias NET-ADMINS=root,jim
User_Alias TEMP-ADMINS=joe,linda


The last section in /etc/sudoers is the Privileges section. This is where users and groups defined in the User_Alias section are granted or denied permission to run commands on the system.

First, we grant the users in the SYS-ADMINS alias permission to run all commands on all hosts:
SYS_ADMIN ALL=(ALL) ALL

Next, we assign the ORACLE-ADMINS alias permission to run all commands on all Oracle servers as DB-ADMIN, with the exception of the four system commands listed:
ORACLE-ADMINS DATABASE=(DB-ADMIN) !PASS,!DIST,!SHELL,!SU

The last entry assigns privileges to the TEMP-ADMINS user alias. The TEMP-ADMINS user alias is granted permission to run any command on any server listed in the FINANCE-NET host alias. These administrators are also granted the ability to run any command on any host in the ADMIN host alias, with the exception of the PASS, HACKS, and SHELL command aliases:
TEMP-ADMINS FINANCE-NET=ALL:ADMIN=!PASS,!HACKS,!SHELL

Now let’s look at one entry that you may consider placing in the /etc/sudoers file (but that is a bad idea):
%wheel ADMIN=ALL

This entry allows any user in the wheel group on any host in the host alias ADMIN to execute any command as root. Using this entry defeats the purpose of sudo. We want to limit root access system-wide, not grant root access without restrictions. In addition, the lack of parentheses anywhere in the entry above means that sudo cannot be run as any user except root. This is dangerous. Don't ever allow an entry like this in /etc/sudoers.

Disabling the su command
System administrators often deal with users who insist that they need the root password to perform their responsibilities. The easiest way to deal with these situations is to ensure that everyone, including root, must use sudo for root access. Once sudo is installed and configured, the administrator should remove the ability to su to root, allowing root access only through sudo. The easiest way to ensure this is to use Pluggable Authentication Modules (PAM). There are three steps required to disable root access to su.
  1. As root, edit the /etc/pam.d/su file and add the following line to the beginning of this file:
auth required /lib/security/pam_listfile.so onerr=fail \
  item=user sense-deny file=/etc/security/sudeny

  1. As root, run this command:
touch /etc/security/sudeny
  1. As root, edit the /etc/security/sudeny file and add the name of any user for whom you want to deny access to su. To remove the possibility of any user running the su command, add the following line to /etc/pam.d/su:
auth required /lib/security/pam_deny.so

To ensure that root can no longer log in to the system directly, edit the /etc/securetty file and remove all entries from this file. To ensure that /etc/securetty is an empty file, run the following commands as root: First, retain a backup copy of the current /etc/securetty file with the command
cp /etc/securetty /etc/securetty.bak

Next, delete the current /etc/securetty file with the command
rm /etc/securetty

Then create an empty /etc/securetty file with the command
touch /etc/securetty

Sudo logging
Each log entry in /var/log/sudo.log contains the following information:
  • Date
  • Timestamp for the log entry
  • Hostname where the command was executed
  • Username
  • Current directory
  • User the command was executed as
  • Command executed

Example B shows some typical log entries for sudo.

Example B: Typical log entriesSep 20 19:45:54 training sudo jim : TTY=tty1 ; PWD=/home/jim ;
user=root ; COMMAND=/bin/bash

Sep 20 20:25:30 training sudo susan : TTY=tty1 ; PWD=/home/susan ;
user=root ; COMMAND=/usr/sbin/lpc restart all

Sep 20 21:40:10 training sudo carol : command not allowed ; TTY=tty2 ; PWD=home/carol ;
user=root ; COMMAND=/sbin/shutdown now

Sep 20 21:45:30 training sudo ted : TTY=tty1 ; PWD=home/carol ;
user=root ; COMMAND=list


The sudo log entries provide the administrator with the following information:
  • In the first entry in this file, the entry COMMAND=/bin/bash may have been produced by either sudo /bin/bash or sudo -s. Jim's activities created no further log entries. This is because once Jim has executed the /bin/bash command, he has invoked the shell, and no further activities will be logged. The same thing will occur if the vi editor is executed. No commands entered through vi will be logged.
  • The second entry shows that Susan ran the /usr/sbin/lpc restart all command to restart the printer daemons.
  • The third entry is a log of Carol's attempt to execute the /sbin/shutdown now command. She is not authorized to run this command, and she was unable to execute it.
  • The last entry shows that Ted executed the list command. This means that ted executed the sudo -l command.

Potential security holes
Sudo is not a complete solution for limiting root access. It is not difficult to obtain more root privileges than sudo has granted. One way to do this is to run the :shell command from within the vi editor. This will give the user a root shell and effectively nullify the limitations imposed by sudo.

Here are some guidelines to follow when administering sudo:
  • Always make sure that a user absolutely needs root access before granting it. Use sudo as a tool to limit root access.
  • Give users authorization to only the commands they absolutely need.
  • Avoid using user groups and netgroups in the /etc/sudoers file whenever possible. Once a hacker gains access to a group or netgroup with sudo privileges, complete root access is probably easy to obtain. List users individually in the sudoers file.
  • The sudo log files are the most important security benefit of sudo. Read them regularly to track root activity on your system.

Conclusion
This Daily Drill Down concludes our two-part series on the sudo utility. This highly configurable tool allows administrators to easily control the privileges available to users when they require root access. In part one of this series, we covered the installation and configuration of sudo, and we assigned root privileges to users on a single-server network.

In part two, we looked at how sudo is configured for a network running several servers, and we assigned a wider variety of root privileges to both single users and groups of users. We also covered methods for disabling the su command, using sudo with PAM, security vulnerabilities associated with sudo, and sudo logs.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks