Restricting setuid Executable Files

Executable files can be security risks. Many executable programs have to be run as root, that is, as superuser, to work properly. These programs run with the user ID set to 0, that is, setuid=0. Anyone who is running these programs runs the programs with the root ID. A program that runs with the root ID creates a potential security problem if the program was not written with security in mind.

Except for the executables that Sun ships with the setuid bit set to root, you should disallow the use of setuid programs. If you cannot disallow the use of setuid programs, then you should at least restrict their use. Secure administration requires few setuid programs.

Using the Automated Security Enhancement Tool (ASET)

The ASET security package provides automated administration tools that enable you to control and monitor your system's security. You specify an ASET security level. ASET provides three security levels: low, medium, and high. At each higher level, ASET's file-control functions increase to reduce file access and tighten your machine's security.

For more information, see Chapter 8, Using the Automated Security Enhancement Tool (Tasks).

Using the Resource Manager

Solaris software provides a sophisticated resource management tool, the Resource Manager. The Resource Manager can help prevent denial of service attacks. With the Resource Manager, you can designate resources for particular projects. You can prevent scripts from overrunning the machine's resources. You can limit the space that a project can occupy. For a description and an extensive example of how to use the Resource Manager, see "Solaris 9 Resource Manager Topics" in System Administration Guide: Resource Management and Network Services.

Monitoring Use of Machine Resources

As system administrator, you need to monitor system activity. You need to be aware of all aspects of your machines, including the following:

• What is the normal load?

• Who has access to the system?

• When do individuals access the system?

• What programs normally run on the system?

With this kind of knowledge, you can use the available tools to audit machine use and monitor the activities of individual users. Monitoring is very useful when there is a suspected breach in security. For more information on the auditing module, see Chapter 20, BSM (Overview).

Controlling Access to Files

The Solaris operating environment is a multiuser environment. In a multiuser environment, all the users who are logged in to a machine can read files that belong to other users. With the appropriate file permissions, users can also use files that belong to other users. Table 2-3 describes the commands for file system security. For step-by-step instructions on securing files, see Chapter 4, Securing Files (Tasks).

Commands for File System Security

This table describes the commands for monitoring and securing files and directories.

Table 2-3 Commands for File System Security

File Encryption

You can keep a file secure by making the file inaccessible to other users. For example, a file with permission 600 cannot be read except by its owner and the superuser. A directory with permissions 700 is similarly inaccessible. However, someone who guesses your password or who discovers the root password can access that file. Also, the otherwise inaccessible file is preserved on a backup tape every time that the machine files are backed up to tape.

Fortunately, an additional layer of security is available to all users of Solaris software in the United States, the Solaris Encryption Kit. The encryption kit includes the crypt command, which scrambles the data to disguise the text. For more information, see the crypt(1) man page.

Access Control Lists (ACLs)

ACLs, pronounced "ackkls", can provide greater control over file permissions. You add ACLs when the traditional UNIX file protection in the Solaris operating environment is not sufficient. The traditional UNIX file protection provides read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides finer-grained file security. ACLs enable you to define the following file permissions:

• Owner file permissions

• Owner's group file permissions

• File permissions for other users who are outside the owner's group

• File permissions for specific users

• File permissions for specific groups

• Default permissions for each of the previous categories

For step-by-step instructions on using ACLs, see Using Access Control Lists (ACLs).

The following table lists the commands for administering ACLs on files or directories.

Table 2-4 Access Control List (ACL) Commands

Sharing Files Across Machines

A network file server can control which files are available for sharing. A network file server can also control which clients have access to the files, and what type of access is permitted for those clients. In general, the file server can grant read-write access or read-only access either to all clients or to specific clients. Access control is specified when resources are made available with the share command.

The /etc/dfs/dfstab file on the file server lists the file systems that the server makes available to clients on the network. For more information about sharing file systems, see "Automatic File-System Sharing" in System Administration Guide: Resource Management and Network Services.

Restricting root Access to Shared Files

In general, superuser is not allowed root access to file systems that are shared across the network. The NFS system prevents root access to mounted file systems by changing the user of the requester to the user nobody with user ID 60001. The access rights of user nobody are the same as those access rights that are given to the public. The user nobody has the access rights of a user without credentials. 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. To grant these privileges, use the root=hostname option to the share command. You should use this option with care.

Controlling Network Access

Computers are often part of a configuration of computers. The configuration is called a network. A network allows connected computers to exchange information. Networked computers can access data and other resources from other computers on the network. Networking has created a powerful and sophisticated way of computing. However, networking also jeopardizes computer security.

For instance, within a network of computers, individual machines are open to allow the sharing of information. Also, because many people have access to the network, unwanted access is more likely, especially through user error. For example, a poor use of passwords can allow unwanted access.

Network Security Mechanisms

Network security is usually based on limiting or blocking operations from remote systems. The following figure describes the security restrictions that you can impose on remote operations.

Figure 2-1 Security Restrictions for Remote Operations

Authentication and Authorization for Remote Access

Authentication is a way to restrict access to specific users when these users access a remote machine. Authentication can be set up at both the machine level and the network level. Once a user gains access to a remote machine, authorization is a way to restrict operations that the user can perform on the remote system. The following table lists the types of authentications and authorizations that can help protect your machines on the network against unauthorized use.

Table 2-5 Types of Authentication and Authorization for Remote Access