Chapter 16 Managing System Security (Overview)

Keeping a system's information secure is an important system administration responsibility. This chapter provides overview information about managing system security at the file, system, and network level.

This is a list of the overview information in this chapter.

• "What's New in Solaris System Security?"

• "Where to Find System Security Tasks"

• "Controlling Access to a Computer System"

• "File Security"

• "System Security"

• "Network Security"

What's New in Solaris System Security?

This section describes new security features.

New Default Ownerships and Permissions on System Files and Directories

Many system files and directories in this Solaris release have different default ownership and stricter permissions than in previous releases. The default ownership and permissions changes are:

• Default file and directory ownership has been changed from bin to root.

• Files and directories previously having default permissions of 775 now have default permissions of 755.

• Files and directories previously having default permissions of 664 now have default permissions of 644.

• Default umask of the system is 022.

Keep the following in mind when creating a package to be added to a system running the Solaris 8 release:

• All files and directories must have root as the default owner.

• Directories and executables must have default permissions of 555 or 755.

• Ordinary files must have default permissions of 644 or 444.

• Files with setuid and/or setgid ownership cannot be writable by the owner, unless the owner is root

These changes do not apply to all files and directories in this release; for example, the changes do not apply to OpenWindows or CDE files and directories.

Role-Based Access Control

Role-based access control (RBAC) provides a flexible way to package superuser privileges for assignment to user accounts so that you don't have to give all superuser privileges to a user that needs to solve a specific problem.

See Chapter 19, Role-Based Access Control for more information.

Sun Enterprise Authentication Mechanism (SEAM) or Kerberos V5 Client Support

This feature provides the Kerberos V5 client-side infrastructure, an addition to the Pluggable Authentication Module (PAM), and utility programs that can be used to secure RPC based applications, such as the NFS service. Kerberos provides selectable strong user or server level authentication, integrity, or privacy support. The Kerberos clients can be used in conjunction with Sun Enterprise Authentication Mechanism (SEAM), a part of SEAS 3.0, or other Kerberos V5 software (for instance, the MIT distribution) to create a complete single network sign-on solution.

See Chapter 21, SEAM Overview for more information.

Where to Find System Security Tasks

Use these references to find step-by-step instructions for setting up system security.

• Chapter 17, Securing Files (Tasks)

• Chapter 18, Securing Systems (Tasks)

• Chapter 19, Role-Based Access Control

• Chapter 20, Using Authentication Services (Tasks)

• Chapter 24, Using Automated Security Enhancement Tool (Tasks)

Controlling Access to a Computer System

At the file level, the SunOS operating system provides some standard security features that you can use to protect files, directories, and devices. At the system and network levels, the security issues are mostly the same. In the workplace, a number of systems connected to a server can be thought of as one large multifaceted system. The system administrator is responsible for the security of this larger system or network. Not only is it important to defend the network from outsiders trying to gain access to the network, but it is also important to ensure the integrity of the data on the systems within the network.

The first line of security defense is to control access to your system. You can control and monitor system access by:

• Maintaining physical site security

• Maintaining login control

• Restricting access to data in files

• Maintaining network control

• Monitoring system usage

• Setting the path variable correctly

• Securing files

• Installing a firewall

• Reporting security problems

Maintaining Physical Site Security

To control access to your system, you must maintain the physical security of your computer environment. For instance, if a system is logged in and left unattended, anyone who can use that system can gain access to the operating system and the network. You need to be aware of your computer's surroundings and physically protect it from unauthorized access.

Maintaining Login and Access Control

You also must restrict unauthorized logins to a system or the network, which you can do through password and login control. All accounts on a system should have a password. An account without a password makes your entire network accessible to anyone who can guess a user name.

Solaris software restricts control of certain system devices to the user login account. Only a process running as superuser or console user can access a system mouse, keyboard, frame buffer, or audio device unless /etc/logindevperm is edited. See logindevperm(4) for more information.

Restricting Access to Data in Files

After you have established login restrictions, you can control access to the data on your system. You might want to allow some users to read some files, and give other users permission to change or delete some files. You might have some data that you do not want anyone else to see. Chapter 17, Securing Files (Tasks) discusses how to set file permissions.

Maintaining Network Control

Computers are often part of a configuration of systems called a network. A network allows connected systems to exchange information and access data and other resources available from systems connected to the network. Networking has created a powerful and sophisticated way of computing. However, networking has also jeopardized computer security.

For instance, within a network of computers, individual systems are open to allow sharing of information. Also, because many people have access to the network, there is more chance for allowing unwanted access, especially through user error (for example, through a poor use of passwords).

Monitoring System Usage

As system administrator, you need to monitor system activity, being aware of all aspects of your systems, including the following:

• What is the normal load?

• Who has access to the system?

• When do individuals access the system?

With this kind of knowledge, you can use the available tools to audit system use and monitor the activities of individual users. Monitoring is very useful when there is a suspected breach in security.

Setting the Correct Path

It is important to set your path variable correctly; otherwise, you can accidentally run a program introduced by someone else that harms your data or your system. This kind of program, which creates a security hazard, is referred to as a "Trojan horse." For example, a substitute su program could be placed in a public directory where you, as system administrator, might run it. Such a script would look just like the regular su command; since it removes itself after execution, it is hard to tell that you have actually run a Trojan horse.

The path variable is automatically set at login time through the startup files: .login, .profile, and .cshrc. Setting up the user search path so that the current directory (.) comes last prevents you or your users from running this type of Trojan horse. The path variable for superuser should not include the current directory at all. The ASET utility examines the startup files to ensure that the path variable is set up correctly and that it does not contain a dot (.) entry.

Securing Files

Since the SunOS operating system is a multiuser system, file system security is the most basic, and important, security risk on a system. You can use both the traditional UNIX file protection or the more secure access control lists (ACLs) to protect your files.

Also, many executable programs have to be run as root (that is, as superuser) to work properly. These executables run with the user ID set to 0 (setuid=0). Anyone running these programs runs them with the root ID, which creates a potential security problem if the programs are not written with security in mind.

Except for the executables shipped with setuid to root, you should disallow the use of setuid programs, or at least restrict and keep them to a minimum.

Installing a Firewall

Another way to protect your network is to use a firewall or secure gateway system. A firewall is a dedicated system separating two networks, each of which approaches the other as untrusted. You should consider this setup as mandatory between your internal network and any external networks, such as the Internet, with which you want internal network users to communicate.

A firewall can also be useful between some internal networks. For example, the firewall or secure gateway computer will not send a packet between two networks unless the gateway computer is the origin or the destination address of the packet. A firewall should also be set up to forward packets for particular protocols only. For example, you can allow packets for transferring mail, but not those for telnet or rlogin. The ASET utility, when run at high security, disables the forwarding of Internet Protocol (IP) packets.

Reporting Security Problems

If you experience a suspected security breach, you can contact the Computer Emergency Response Team/Coordination Center (CERT/CC), which is a Defense Advanced Research Projects Agency (DARPA) funded project located at the Software Engineering Institute at Carnegie Mellon University. It can assist you with any security problems you are having. It can also direct you to other Computer Emergency Response Teams that might be more appropriate to your particular needs. You can call CERT/CC at its 24-hour hotline: (412) 268-7090, or contact the team by email at cert@cert.sei.cmu.edu.

File Security

The SunOS operating system is a multiuser system, which means that all the users logged in to a system can read and use files belonging to one another, as long as they have permission to do so. The table below describes file system administration commands. See Chapter 17, Securing Files (Tasks) for step-by-step instructions on securing files.

File Administration Commands

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

File Encryption

Placing a sensitive file into an inaccessible directory (700 mode) and making the file unreadable by others (600 mode) will keep it secure in most cases. However, someone who guesses your password or the root password can read and write to that file. Also, the sensitive file is preserved on backup tapes every time you back up the system files to tape.

Fortunately, an additional layer of security is available to all SunOS system software users in the United States--the optional file encryption kit. The encryption kit includes the crypt(1) command which scrambles the data to disguise the text.

Access Control Lists (ACLs)

ACLs (ACLs, pronounced "ackkls") can provide greater control over file permissions when the traditional UNIX file protection in the SunOS operating system is not enough. The traditional UNIX file protection provides read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides better file security by enabling you to define file permissions for the owner, owner's group, others, specific users and groups, and default permissions for each of those categories. See "Using Access Control Lists (ACLs)" for step-by-step instructions on using ACLs.

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

System Security

This section describes how to safeguard your system against unauthorized access, such as how to prevent an intruder from logging in to your system, how to maintain the password files, and how to prevent unauthorized superuser access to sensitive system files and programs.

You can set up two security barriers on a system. The first security barrier is the login program. To cross this barrier and gain access to a system, a user must supply a user name and a corresponding password known by the local system or by the name service (NIS or NIS+).

The second security barrier is ensuring that the system files and programs can be changed or removed by superuser only. A would-be superuser must supply the root user name and its correct password.

Login Access Restrictions

When a user logs in to a system, the login program consults the appropriate database according to the information listed in the /etc/nsswitch.conf file. The entries in this file can include files (designating the /etc files), nis (designating the NIS database), and nisplus (designating the NIS+ database). See the Solaris Naming Administration Guide or nsswitch.conf(4) for a description of this file.

The login program verifies the user name and password entered. If the user name is not in the password file or the password is not correct for the user name, the login program denies access to the system. When the user supplies a name from the password file and the correct password for the name, the system grants the user access to the system.

Special Logins

There are two common ways to access a system--by using a conventional user login, or by using the root login. In addition, a number of special system logins allow a user to perform administrative commands without using the root account. The administrator assigns passwords to these login accounts.

The table below lists the system login accounts and their uses. The system logins perform special functions, and each has its own group identifier number (GID). Each of these logins should have its own password, which should be distributed on a need-to-know basis.

You should also set the security of the eeprom command to require a password. See eeprom(1M) for more information.

Managing Password Information

When logging in to a system, users must enter both a user name and a password. Although logins are publicly known, passwords must be kept secret, known only to users. You should ask your users to choose their passwords carefully, and they should change them often.

Passwords are initially created when you set up a user account. To maintain security on user accounts, you can set up password aging to force users to routinely change their passwords, and you can also disable a user account by locking the password. See "Managing User Accounts and Groups (Overview)" in System Administration Guide, Volume 1 and passwd(1) for detailed information about setting up and maintaining passwords.

NIS+ Password File

If your network uses NIS+, the password information is kept in the NIS+ database. Information in the NIS+ database can be protected by restricting access to authorized users. You can use AdminSuite^TM 2.3's User Manager or the passwd command to change a user's NIS+ password.

NIS Password File

If your network uses NIS, the password information is kept in the NIS password map. NIS does not support password aging. You can use AdminSuite 2.3's User Manager or the passwd command to change a user's NIS password.

/etc Files

If your network uses /etc files, the password information is kept in the system's /etc/passwd and /etc/shadow files. The user name and other information are kept in the password file /etc/passwd, while the encrypted password itself is kept in a separate shadow file, /etc/shadow. This is a security measure that prevents a user from gaining access to the encrypted passwords. While the /etc/passwd file is available to anyone who can log in to a machine, only superuser can read the /etc/shadow file. You can use AdminSuite 2.3's User Manager, Admintool, or the passwd command to change a user's password on a local system.

Using the Restricted Shell

The standard shell allows a user to open files, execute commands, and so on. The restricted shell can be used to limit the ability of a user to change directories and execute commands. The restricted shell (rsh) is located in the /usr/lib directory. (Note that this is not the remote shell, which is /usr/sbin/rsh.) The restricted shell differs from the normal shell in these ways:

• The user is limited to the home directory (can't use cd to change directories).

• The user can use only commands in the PATH set by the system administrator (can't change the PATH variable).

• The user can access only files in the home directory and its subdirectories (can't name commands or files using a complete path name).

• The user cannot redirect output with > or >>.

The restricted shell allows the system administrator to limit a user's ability to stray into the system files, and is intended mainly to set up a user who needs to perform specific tasks. The rsh is not completely secure, however, and is only intended to keep unskilled users from getting into (or causing) trouble.

See rsh(1M) for information about the restricted shell.

Tracking Superuser (Root) Login

Your system requires a root password for superuser mode. In the default configuration, a user cannot remotely log in to a system as root. When logging in remotely, a user must log in as himself and then use the su command to become root. This enables you to track who is using superuser privileges on your system.

Monitoring Who is Becoming Superuser or Other Users

You have to use the su command to change to another user, for example, if you want to become superuser. For security reasons, you can monitor who has been using the su command, especially those users who are trying to gain superuser access.

See "How to Monitor Who Is Using the su Command" for detailed instructions.

Network Security

The more available access is across a network, the more advantageous it is for networked systems. However, free access and sharing of data and resources create security problems. Network security is usually based on limiting or blocking operations from remote systems. The figure below describes the security restrictions you can impose on remote operations.

Figure 16-1 Security Restrictions for Remote Operations

Firewall Systems

You can set up a firewall system to protect the resources in your network from outside access. A firewall system is a secure host that acts as a barrier between your internal network and outside networks.

The firewall has two functions. It acts as a gateway which passes data between the networks, and it acts as a barrier which blocks the free passage of data to and from the network. The firewall requires a user on the internal network to log in to the firewall system to access hosts on remote networks. Similarly, a user on an outside network must log in to the firewall system before being granted access to a host on the internal network.

In addition, all electronic mail sent from the internal network is sent to the firewall system for transfer to a host on an external network. The firewall system receives all incoming electronic mail, and distributes it to the hosts on the internal network.

A firewall prevents unauthorized users from accessing hosts on your network. You should maintain strict and rigidly enforced security on the firewall, but security on other hosts on the network can be more relaxed. However, an intruder who can break into your firewall system can then gain access to all the other hosts on the internal network.

A firewall system should not have any trusted hosts. (A trusted host is one from which a user can log in without being required to type in a password.) It should not share any of its file systems, or mount any file systems from other servers.

ASET can be used to make a system into a firewall, and to enforce high security on a firewall system, as described in Chapter 24, Using Automated Security Enhancement Tool (Tasks).

Packet Smashing

Most local area networks transmit data between computers in blocks called packets. Through a procedure called packet smashing, unauthorized users can harm or destroy data. Packet smashing involves capturing packets before they reach their destination, injecting arbitrary data into the contents, then sending the packets back on their original course. On a local area network, packet smashing is impossible because packets reach all systems, including the server, at the same time. Packet smashing is possible on a gateway, however, so make sure all gateways on the network are protected.

The most dangerous attacks are those that affect the integrity of the data. Such attacks involve changing the contents of the packets or impersonating a user. Attacks that involve eavesdropping--recording conversations and replaying them later without impersonating a user--do not compromise data integrity. These attacks do affect privacy, however. You can protect the privacy of sensitive information by encrypting data that goes over the network.

Authentication and Authorization

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

Sharing Files

A network file server can control which files are available for sharing. It can also control which clients have access to the files, and what type of access is permitted to those clients. In general, the file server can grant read/write 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.

A server can use the /etc/dfs/dfstab file to list the file systems it makes available to clients on the network. See the System Administration Guide, Volume 3 for more information about sharing files.

Restricting Superuser (Root) Access

In general, superuser 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 of the requester to the user ID of the user name, nobody; this is generally 60001. The access rights of user nobody are the same as those given to the public (or 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.

Using Privileged Ports

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 credential, 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, however, might not be able to communicate via the privileged port. If they cannot, you will see error messages such as these:

"Weak Authentication
NFS request from unprivileged port"

Using 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 a security level--low, medium, or high--at which ASET will run. At each higher level, ASET's file-control functions increase to reduce file access and tighten your system security.

See Chapter 24, Using Automated Security Enhancement Tool (Tasks) for more information.