The UNIX superuser identity is immune from restrictions placed on other users of the system. Any UNIX account with a UID of zero (0) is the superuser. All UNIX systems have a default superuser login named root. The user of this account can access any file and run any command. This login is valuable because any user who might have gotten himself into trouble by removing access permissions, forgetting his password, or simply needing a file from an area to which he doesn’t have access can be helped by root.
However, root access can be dangerous. Root can delete anything, including the operating system (most system administrators have deleted the entire root file system at some time). The root login is both dangerous and necessary. System administrators must not give this password to anyone and should use it themselves only when required. If it becomes necessary to grant superuser privileges to nonroot users, utilize roles as described in the next Chapter 17.
Root access needs to be safeguarded against unauthorized use. Assume that any intruder is looking for root access. You can protect the superuser account on a system by restricting access to a specific device through the /etc/default/login file. For example, if superuser access is restricted to the console, the superuser can log in only at the console, which should be in a locked room. Anybody who remotely logs in to the system to perform an administrative function must first log in with his login and then use the su command to become superuser.
Exercise 16.3 Restricting Root Access
Do the following to restrict superuser (root) from logging into the system console from a remote system:
1. |
Become superuser. |
2. |
Edit the /etc/default/login file. |
3. |
Uncomment the following line: CONSOLE=/dev/console |
The previous example set the variable CONSOLE to /dev/console. If the variable CONSOLE were set as follows with no value defined, then root could not log in from anywhere, not even the console:
CONSOLE=
The only way to get into the system as root is to first log in as a regular user and then become root by issuing the su command. If the system console is not in a controlled environment, this option might be useful.
Solaris provides a utility for monitoring all attempts to become superuser. These logs are useful when you’re trying to track down unauthorized activity. Whenever someone issues the su command to switch from user and become root, this activity is logged in a file called /var/adm/sulog. The sulog file lists all uses of the su command, not only those used to switch user to superuser. The entries show the date and time the command was entered, whether it was successful, the port from which the command was issued, and the name of the user and the switched identity.
Exercise 16.4 Monitoring Superuser Access
To monitor who is using the su command, you must first turn on this logging utility. To turn on logging of the su command, follow these steps:
1. |
Become superuser. |
2. |
Edit the /etc/default/su file. |
3. |
Uncomment the following line: SULOG=/var/adm/sulog |
Through the /etc/default/su file, you can also set up the system to display a message on the console each time an attempt is made to use the su command to gain superuser access from a remote system. This is a good way to immediately detect someone trying to gain superuser access to the system on which you are working.
Exercise 16.5 Monitoring Superuser (root) Access Attempts
Do the following to display superuser (root) access attempts to the console:
1. |
Become superuser. |
2. |
Edit the /etc/default/su file. |
3. |
Uncomment the following line: CONSOLE=/dev/console |
4. |
SUDO, an acronym for “superuser do,” is a public-domain software package that enables a system administrator to give certain users (or groups of users) the capability to run some (or all) commands as root or as another user while logging the commands and arguments to a log file for auditing. SUDO enables the system administrator to give access to and track specific root commands without actually giving out the root password. To give a user access to a command that requires root privileges, the system administrator configures the access list or sudoers file. Here is a sample sudoers file:
# sample sudoers file. # This file MUST be edited with the 'visudo' command as root. # See the man page for the details on how to write a sudoers file. # Host alias specification # User alias specification User_Alias DBA=oracle User_Alias APPLMGR=applmgr User_Alias SA=tej1,wbc4,wck2,wbp9 User_Alias OPER=tbw1,tdk1,tss1,wcs6,wjsh,yhq1,yjsd,ylb7 # Cmnd alias specification Cmnd_Alias MOUNT=/sbin/mount,/sbin/umount Cmnd_Alias BACKUP=/usr/sbin/ufsdump Cmnd_Alias RESTORE=/usr/sbin/ufsrestore Cmnd_Alias SHUTDOWN=/sbin/shutdown Cmnd_Alias KILL=/usr/bin/kill Cmnd_Alias CRONTAB=/usr/bin/crontab # User privilege specification root ALL=(ALL) ALL DBA ALL=MOUNT,KILL,BACKUP APPLMGR ALL=MOUNT,KILL OPER ALL=SHUTDOWN
To run a command, simply add sudo to your command, as follows:
sudo shutdown
You’ll be prompted for your personal password, not root’s password. SUDO confirms that you are allowed to execute the command and logs what you did to the SUDO log file.
Note
SUDO caches your password so that you don’t need to keep entering it for successive sudo commands. The default is five minutes for the caching of the password.
The following are the advantages of SUDO:
You don’t have to give out the root password to everyone. It’s a handy way to give users controlled access for commands they need to get their work done.
It’s a good tool to get beginning system administrators started without giving them full access.
The audit logs are quite handy to track root activities. If something changes, you can go to the log to see when it happened and who did it.
It works well and is a simple but effective point solution.
The disadvantage of SUDO is that it’s not part of the Solaris 9 operating system and must be downloaded from the Internet. Visit my web site, www.pdesigninc.com, for an up-to-date site from which to download SUDO. Another disadvantage is that it is not an integrated facility, but an application.
I describe SUDO in this chapter because many sites have been using it for years. Providing similar functionality is the Role-Based Access Control (RBAC) facility. RBAC was introduced in Solaris 8 and is described in Chapter 17. It is a great alternative to SUDO—best of all, it comes bundled in the Solaris operating system.