Previous Table of Contents Next


Restricting Superuser (root) Access

In general, superuser on a local system is not allowed root access to file systems shared across the network. Unless the server specifically grants superuser privileges, a user who is logged in as superuser on a client cannot gain root access to files that are remotely mounted on the client. The NFS system implements this by changing the user ID (usually 60001) of the requester to the user ID of the user named nobody. The access rights of user nobody are the same as those given to the public or to a user without credentials for a particular file. For example, if the public has only execute permission for a file, then user nobody can only execute that file.

An NFS server can grant superuser privileges on a shared file system on a per-host basis, using the root=<hostname> option to the share command.

Controlling and Monitoring Superuser Access

The following sections describe how to restrict and monitor superuser access in the following ways:

  Restrict superuser login to the console.
  Monitor who is using the su command.

Restricting Superuser Logins to the Console

The superuser account has complete control over the entire operating system. It has access to and can execute essential system programs. For this reason, there are almost no security restraints for any program that is run by superuser.

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, root can log in to a system only from the console. If individuals remotely log in to the system to perform administrative functions, they must first log in with their user logins and then use the su command to become superuser.


NOTE:  Restricting superuser login to the console is the default setup when a system is installed.

Use the following steps to restrict superuser (root) login to the console:

1.  Become superuser.
2.  Edit the /etc/default/login file and remove the # comment from the beginning of the #CONSOLE=/dev/console line.
3.  Save the changes to the file.
4.  Try to rlogin to the system as superuser and verify that the operation fails.

Monitoring Who Is Using the su Command

You can monitor su attempts with the /etc/default/su file. By using this file, you can enable the /var/adm/sulog file to monitor each time the su command is used to change to another user.


NOTE:  Enabling the /var/adm/sulog file to monitor su use is the default setup when a system is installed.

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 used, whether or not it was successful (+ or -), the port from which the command was issued, and the name of the user and the switched identity.

Use the following steps to monitor who is using the su command:

1.  Become superuser.
2.  Edit the /etc/default/login file and remove the remove the # comment from the beginning of the #SULOG=/var/adm/sulog line.
3.  Save the changes to the file.
4.  Use the su command several times and, as superuser, display the contents of the /var/adm/sulog file.

The following example shows the tail of the /var/adm/sulog file.

castle% su
Password:
# tail -20 /var/adm/sulog
SU 10/07 10:35 + pts/3 winsor-root
SU 10/07 15:05 + console root-daemon
SU 10/07 15:54 + console root-daemon
SU 10/07 16:28 + pts/3 winsor-root
SU 10/08 08:23 + console root-daemon
SU 10/08 09:43 + pts/3 winsor-root
SU 10/08 10:03 + pts/3 winsor-root
SU 10/08 12:34 + pts/3 winsor-des
SU 10/08 12:39 + pts/3 winsor-root
SU 10/08 12:39 + pts/3 winsor-des
SU 10/08 12:39 - pts/3 winsor-ray
SU 10/08 12:39 - pts/3 winsor-ray
SU 10/08 12:39 - pts/3 winsor-ray
SU 10/08 12:39 - pts/3 winsor-ray
SU 10/08 12:40 - pts/3 winsor-ray
SU 10/08 12:40 - pts/3 winsor-ray
SU 10/08 12:40 + pts/3 winsor-root
SU 10/08 12:41 + pts/5 winsor-root
SU 10/08 12:44 + console root-daemon
SU 10/08 12:56 + pts/3 winsor-root
#

Using Privileged Ports

Secure RPC is a method of providing additional security that authenticates both the host and the user making a request. For more information about Secure RPC, refer to Chapter 19, “Using Authentication Services.” If you do not want to run Secure RPC, a possible substitute is the Solaris privileged port mechanism. A privileged port is built up by the superuser with a port number of less than 1024. After a client system has authenticated the client's credentials, it builds a connection to the server via the privileged port. The server then verifies the client credential by examining the connection's port number.

Non-Solaris clients might not, however, be able to communicate via the privileged port. If they cannot, you might see error messages such as Weak Authentication NFS request from unprivileged port.

Automated Security Enhancement Tool (ASET)

The ASET security package provides automated administration tools that enable you to control and monitor system security. You specify a security level—low, medium, or high—at which ASET runs. At each higher level, ASET's file control functions increase to reduce file access and tighten your system security. For more information, see Chapter 20, “Using the Automated Security Enhancement Tool (ASET).”


Previous Table of Contents Next