su or sudo

su or sudo

In Unix, there are two types of users: root and the rest. The root account, also known as the super user, is required for performing system maintenance tasks. If a user requires an account on a machine, the machine needs to be shut down for maintenance, or an application requires direct access to the Ethernet interface, the root account must be used. This constant demand on the holder of the root account can lead to inefficiencies in the management of the system.

There are two solutions to this problem:

• Share the root password.

• Grant privileged access to others.

The first option is unacceptable. From an audit standpoint, generic accounts are typically frowned upon. It is essentially impossible to track which distinct individual accessed a generic account and performed a particular task. Though it may be possible to correlate who was in the office and had access to a particular terminal, the exercise is often futile. If the account in question has complete access to all the files on the system, sharing the password to that account places all the information on the system at risk.

A sound security policy always includes that access is granted on a need-to-have basis. When a system is production ready, most of the requirements for the root account have already been satisfied. In the case in which additional access is required, alternative solutions should be employed. This brings us back to the second option: granting additional privileges.

The su, substitute user, command allows an individual to start a shell under the account context of another user. This allows complete access to the target account, including files, mail, and applications available. The transition can be made for a simple command or an entire session depending on the command-line parameters. Here are a couple of variations on the su command and the resulting environment:

 hart@Athena:~> hart@Athena:~> pwd /home/hart hart@Athena:~> ls bin        login.txt                  photos       su Documents  ls                         public_html  t2.html exit       make_teams.good            pwd          test.html key.txt    Monoalphabetic Crypto.txt  sheila.pdf   t.t hart@Athena:~> hart@Athena:~> su -l eric Password: eric@Athena:~> pwd /home/eric eric@Athena:~> ls bin  Desktop  Documents  exit  ls  public_html  pwd  su eric@Athena:~> exit logout hart@Athena:~> pwd /home/hart hart@Athena:~> 

In this example, a shell is created running under the eric account exactly as it would be if a Telnet or ssh session had been invoked.

In this second example, the ls -l command is executed in the context of the eric account, and control is passed back to the original shell belonging to hart:

 hart@Athena:~> su -l eric -c 'ls -l ; pwd' Password: total 16 drwxr-xr-x  2 eric users 4096 2005-02-15 06:48 bin drwx------  3 eric users 4096 2005-02-15 07:04 Desktop drwxr-xr-x  2 eric users 4096 2005-02-15 06:48 Documents -rw-r--r--  1 eric users   12 2005-02-26 09:55 exit -rw-r--r--  1 eric users  192 2005-02-26 09:55 ls drwxr-xr-x  2 eric users 4096 2005-02-15 06:48 public_html -rw-r--r--  1 eric users   16 2005-02-26 09:55 pwd -rw-r--r--  1 eric users  517 2005-02-26 09:55 su /home/eric hart@Athena:~> pwd /home/hart hart@Athena:~> 

The su command provides the ability for users to access information and resources through other accounts. It does, however, require that individuals share passwords. When this happens, they are invariably written down or shared beyond the originally intended recipient. In the case of the root account, all the functionality of the root account would be available to whoever acquires the password. All the activities of the su command are logged in /var/log/messages as expected, providing a measure of auditing. In many environments, however, the sharing of passwords is against corporate IT policies. Luckily, another utility resolves many of the issues encountered with the su command: sudo.

The sudo utility provides the equivalent functionality of su but with an extra level of granularity. The configuration file for sudo, /etc/sudoers, can be used to limit which users can use sudo and which accounts they are allowed to target. In addition, sudo can be used to limit the verbs available to the new shell.

Listing 5.10 shows a possible configuration for the /etc/sudoers file. In this listing, you can see sample definitions for the various alias types available. A User_Alias can be used to group like users. The current example defines POWERUSER and command aliases to define groups of commands.

The final portion of the sudoers file contains the granting of rights to users and user aliases. In the current example, eric and hart are able to perform most functions commonly associated with an operator type position. In addition, eric has been granted the right to manage disk quotas. Because of the defaults configured in the sudoers file, eric and hart must know the root password to obtain the necessary privileges.

In contrast to this, the user belandja can have direct access to the shutdown command without the need to know the root password. This capability is often convenient when a user, such as an Oracle DBA, needs to reboot the machine during an install. Because such users do not need the root password for day-to-day tasks, this allows them the freedom to restart the server without requiring additional support staff.

Listing 5.10. Sample /etc/sudoers File

 # sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # Defaults specification Defaults targetpw # ask for the password of the target user #%users ALL=(ALL) ALL # WARNING! Only use this together  with 'Defaults targetpw'! # User privilege specification # You should not use sudo as root in an SELinux environment # If you use SELinux, remove the following line root   ALL=(ALL) ALL User_Alias     POWERUSER  = eric, hart Cmnd_Alias     MNT = /bin/mount, /bin/umount Cmnd_Alias     KILL = /bin/kill Cmnd_Alias     USERMGMT = /usr/sbin/useradd, /usr/sbin/groupadd Cmnd_Alias     PRINTING = /usr/sbin/lpc, /usr/bin/lprm Cmnd_Alias     SHUTDOWN = /sbin/shutdown Cmnd_Alias     REBOOT   = /sbin/reboot POWERUSER      ALL = (root) MNT, USERMGMT, KILL, PRINTING,  SHUTDOWN, REBOOT belandja ALL= NOPASSWD: /sbin/shutdown eric     ALL= (root) /usr/sbin/setquota 

With this configuration in effect, members of the POWERUSER group can perform all the tasks they are required to perform, but no more than that. For the user hart, it is possible for him to manage groups but not affect system services even though he can sudo to root. This can be seen in the following excerpt from an online session:

 hart@Athena:~> hart@Athena:~> sudo /usr/sbin/groupadd websales Password: hart@Athena:~> grep -e websales /etc/group websales:!:1000: hart@Athena:~> hart@Athena:~> sudo /etc/init.d/xinetd stop Sorry, user hart is not allowed to execute  '/etc/init.d/xinetd stop' as root on Athena. hart@Athena:~> 

After all the rules are sorted out and access is given to those who need it, the su utility can be retired. The easiest way to do this is to change the permission on /bin/su not to allow Other to have execute access to the program. Replacing the su command with sudoin conjunction with restricting sensitive accounts to known workstations using PAMgreatly reduces the risk exposure of a server. Locking down root to the console further protects the account from external access.