Securing Superuser Access

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.

Restricting Root Access

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.

Monitoring Superuser Access

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.
Use the su command to become root, and verify that a message is printed on the system console.

SUDO

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset