Chapter 15 Managing Machine Security (Overview)

To keep a machine's information secure is an important system administration responsibility. This chapter provides overview information about managing machine security.

The following lists the overview information in this chapter.

• Controlling Access to a Computer System

• Controlling Access to Machine Resources

• Controlling Access to Files

• Controlling Network Access

Controlling Access to a Computer System

In the workplace, a number of machines that are connected to a server can be thought of as one large multifaceted system. You are responsible for the security of this larger system. You need to defend the network from outsiders who are trying to gain access to the network. You also need to ensure the integrity of the data on the machines within the network.

At the file level, the Solaris operating environment 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. The first line of security defense is to control access to your system. You can control and monitor system access by doing the following:

• Maintaining physical security

• Maintaining login control

• Monitoring and limiting resource use

• Protecting files

• Controlling network access

• Reporting security problems

Maintaining Physical Security

To control access to your system, you must maintain the physical security of your computing environment. For instance, a machine that is logged in and left unattended is vulnerable to unwanted access. An intruder can gain access to the operating system and to the network. The computer's surroundings and the computer hardware should be physically protected from unauthorized access.

You can protect a SPARC machine from unwanted access to the hardware settings. Use the eeprom(1M) command to require a password to access the PROM. See How to Require a Password for Hardware Access for more information.

Maintaining Login Control

You also must prevent unauthorized logins to a system or the network, which you can do through password assignment and login control. All accounts on a system should have a password. A password is a simple authentication mechanism. An account without a password makes your entire network accessible to an intruder who guesses a user name. A strong password algorithm protects against brute force attacks.

When a user logs in to a system, the login command consults the appropriate database according to the information that is listed in the /etc/nsswitch.conf file. This file can include the following entries:

• files – Designates the /etc files on the local machine.

• nis – Designates the NIS database on the NIS master server.

• nisplus – Designates the NIS+ database on the NIS+ root server.

• ldap – Designates the LDAP directory service on the LDAP server.

For a description of the nsswitch.conf file, see the nsswitch.conf(4) man page. For information about naming or directory services, see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or the System Administration Guide: Naming and Directory Services (FNS and NIS+).

The login command verifies the user name and password that were entered. If the user name is not in the password file, the login command denies access to the machine. If the password is not correct for the user name that was entered, the login command denies access to the machine. When the user supplies a valid user name and its corresponding password, the system grants the user access to the machine.

Sophisticated authentication and authorization mechanisms are available on Solaris systems. For a discussion of authentication and authorization mechanisms at the network level, see Authentication and Authorization for Remote Access.

Managing Password Information

When users log in to a system, the users must enter both a user name and a password. Although logins are publicly known, passwords must be kept secret. Passwords should be known only to each user. You should ask your users to choose their passwords carefully, and users should change their passwords 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. You can also disable a user account by locking the password. For detailed information about administering passwords, see “Managing User Accounts and Groups (Overview)” in System Administration Guide: Basic Administration and the passwd(1) man page.

Local Passwords

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 security measure 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 the passwd command to change a user's password on a local system.

NIS and NIS+ Passwords

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 the passwd command to change a user's password that is stored in a NIS+ database.

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

LDAP Passwords

The Solaris LDAP Naming Service stores the password information and the shadow information in the ou=people container of the LDAP directory tree. On the Solaris LDAP naming service client, you can use the passwd –r ldap command to change a user's password. The LDAP naming service stores the password in the LDAP repository.

In the Solaris 9 12/02 release, password policy is enforced on the Sun^TM Open Net Environment (Sun ONE) Directory Server. Specifically, the client's pam_ldap module obeys the password policy controls that are enforced on the Sun ONE Directory Server. For more information, see “LDAP Naming Service Security Model” in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Password Encryption

Strong password encryption provides an early barrier against attack. The Solaris 9 12/02 release provides four password encryption modules. The MD5 modules and the Blowfish module provide more robust password encryption than the UNIX algorithm.

You specify the algorithms configuration for your site in the /etc/security/policy.conf file. In the policy.conf file, the algorithms are named by their identifier, as shown in the following table.

Algorithms Configuration in the policy.conf File

The following shows the default policy.conf file:

#
# Copyright 1999-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# /etc/security/policy.conf
#
# security policy configuration for user attributes. see policy.conf(4)
#
#ident  "@(#)policy.conf        1.6     02/06/07 SMI"
#
AUTHS_GRANTED=solaris.device.cdrw
PROFS_GRANTED=Basic Solaris User

# crypt(3c) Algorithms Configuration
#
# CRYPT_ALGORITHMS_ALLOW specifies the algorithms that are allowed to
# be used for new passwords.  This is enforced only in crypt_gensalt(3c).
#
CRYPT_ALGORITHMS_ALLOW=1,2a,md5

# To deprecate use of the traditional unix algorithm, uncomment below
# and change CRYPT_DEFAULT= to another algorithm.  For example,
# CRYPT_DEFAULT=1 for BSD/Linux MD5.
#
#CRYPT_ALGORITHMS_DEPRECATE=__unix__

# The Solaris default is the traditional UNIX algorithm.  This is not
# listed in crypt.conf(4) since it is internal to libc.  The reserved
# name __unix__ is used to refer to it.
#
CRYPT_DEFAULT=__unix__

When you change the value for CRYPT_DEFAULT, the passwords of new users are encrypted with the algorithm that is associated with the new value. When current users change their passwords, how their old password was encrypted affects which algorithm is used to encrypt the new password.

For example, assume that CRYPT_ALGORITHMS_ALLOW=1,2a,md5 and CRYPT_DEFAULT=1. The following table shows which algorithm would be used to generate the encrypted password.

For more information on the syntax for configuring the algorithm choices, see the policy.conf(4) man page. For information on how to use the new password encryption algorithms, see Changing the Default Algorithm for Password Encryption.

Special System Logins

Two common ways to access a system are by using a conventional user login, or by using the root login. In addition, a number of special system logins enable a user to perform administrative commands without using the root account. As system administrator, you assign passwords to these login accounts.

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

Remote Logins

Remote logins offer a tempting avenue for intruders. The Solaris operating environment provides a number of commands to monitor, limit, and disable remote logins. For procedures, see Securing Logins and Passwords.

By default, remote logins cannot gain control or read certain system devices, such as the system mouse, keyboard, frame buffer or audio device. For more information, see the logindevperm(4) man page.

Dial-up Logins

When a computer can be accessed through a modem or a dial-up port, you can add an extra layer of security. You can require a dial-up password for users who access a system through a modem or dial-up port. The dial-up password is an additional password that a user must enter before being granted access to the machine.

Only superuser can create or change a dial-up password. To ensure the integrity of the system, the password should be changed about once a month. The most effective use of this feature is to require a dial-up password to gain access to a gateway system. For how to set up dial-up passwords, see How to Create a Dial-up Password.

Two files are involved in creating a dial-up password, /etc/dialups and /etc/d_passwd. The dialups file contains a list of ports that require a dial-up password. The d_passwd file contains a list of shell programs that require an encrypted password as the additional dial-up password. The information in these two files is processed as follows:

• If the user's login shell in /etc/passwd matches an entry in /etc/d_passwd, the user must supply a dial-up password.

• If the user's login shell in /etc/passwd is not found in /etc/d_passwd, the password entry for /usr/bin/sh is used.

  If the login shell field in /etc/passwd is null, the password entry for /usr/bin/sh is used.

• If the user's login shell in /etc/passwd is not found in /etc/d_passwd, the user must supply the default password. The default password is the entry for /usr/bin/sh.

• If the login shell field in /etc/passwd is empty, the user must supply the default password. The default password is the entry for /usr/bin/sh.

• If /etc/d_passwd has no entry for /usr/bin/sh, then those users whose login shell field in /etc/passwd is empty or does not match any entry in /etc/d_passwd are not prompted for a dial-up password.

• Dial-up logins are disabled if /etc/d_passwd has only the following entry: /usr/bin/sh:*:

Controlling Access to Machine Resources

As system administrator, you can control and monitor system activity. You can set limits on who can use what resources. You can log resource use, and you can monitor who is using the resources. You can also set up your machines to minimize improper use of resources.

Limiting and Monitoring Superuser

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 with the user's username and then use the su command to become root. For security reasons, you can monitor who has been using the su command, especially those users who are trying to gain superuser access. For procedures that monitor superuser and limit access to superuser, see Monitoring and Restricting Superuser.

Configuring Role-Based Access Control to Replace root

Role-based access control, or RBAC, is designed to limit the powers of superuser. Superuser, the root user, has access to every resource in the system. With RBAC, you can replace root with a set of roles with discrete powers. For example, you can set up a role to handle user account creation, and another role to handle system file modification. When you have established a role to handle a function or set of functions, you can remove those functions from root's capabilities.

Each role requires that a known user log in with their username and password. After logging in, the user then assumes the role with a specific role password. Someone who learns the root password, then, has limited ability to damage your system. For more on RBAC, see Chapter 18, Role-Based Access Control (Overview).

Preventing Unintentional Misuse of Machine Resources

You can prevent you and your users from unintentional error. You can keep from running a Trojan horse by setting the PATH variable correctly. You can prevent user error by steering users to those parts of the system that the users need for their jobs. In fact, through careful setup, you can ensure that users see only those parts of the system that help the users work efficiently.

Setting the Path Variable

You should take care to set the path variable correctly. Otherwise, you can accidentally run a program that was introduced by someone else. The intruding program can corrupt your data or harm 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 the substitute program. Such a script would look just like the regular su command. Since the script removes itself after execution, you would have little evidence to show that you have actually run a Trojan horse.

The path variable is automatically set at login time. The path is set through the startup files: .login, .profile, and .cshrc. When you set up the user search path so that the current directory (.) comes last, you are protected from running this type of Trojan horse. The path variable for superuser should not include the current directory at all.

The Automated Security Enhancement Tool (ASET) examines the startup files to ensure that the path variable is set up correctly. ASET also makes sure that the path variable does not contain a dot (.) entry.

Assigning a Restricted Shell

The standard shell allows a user to open files, execute commands, and so on. The restricted shell is invoked with the /usr/lib/rsh command. The restricted shell can be used to limit the ability of a user to change directories and to execute commands. Note that the restricted shell is not the remote shell, which is /usr/sbin/rsh. The restricted shell differs from the standard shell in the following ways:

• The user is limited to the user's home directory, so the user cannot use the cd command to change directories. Therefore, the user cannot browse system files.

• The user cannot change the PATH variable, so the user can use only commands in the PATH set by the system administrator. The user also cannot execute commands or scripts by using a complete path name.

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

The restricted shell enables you to limit a user's ability to stray into the system files. The shell creates a limited environment for a user who needs to perform specific tasks. The restricted shell is not completely secure, however, and is only intended to keep unskilled users from inadvertently doing damage.

For information about the restricted shell, see the rsh(1M) man page.

A more secure alternative to the restricted shell is the Secure Shell, the ssh command. The Secure Shell enables users to securely access a remote host over an unsecured network. For information about using the Secure Shell, see Chapter 6, Secure Shell Administration (Reference).

Restricting Access to Data in Files

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

After you have established login restrictions, you can control access to the data on your machine. 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 16, Securing Files (Tasks) discusses how to set file permissions.

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 21, 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 23, 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 15–3 describes the commands for file system security. For step-by-step instructions on securing files, see Chapter 16, Securing Files (Tasks).

Commands for File System Security

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

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.

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 15–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.

Using Privileged Ports Between Solaris Systems

If you do not want to run Secure RPC, a possible substitute is the Solaris “privileged port” mechanism. A privileged port is assigned with a port number of less than 1024. After a client system has authenticated the client's credential, the client builds a connection to the server by using the privileged port. The server then verifies the client credential by examining the connection's port number.

Non-Solaris clients, however, might be unable to communicate by using the privileged port. If the clients cannot communicate over the port, you see an error message that is similar to the following:

“Weak Authentication
NFS request from unprivileged port”

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. Each network 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 to communicate.

A firewall acts as a gateway and as a barrier. A firewall acts as a gateway that passes data between the networks. A firewall acts as a barrier when the firewall 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.

A firewall can also be useful between some internal networks. For example, you can set up a firewall or secure gateway computer to restrict the transfer of packets. The gateway can forbid packet exchange between two networks unless the gateway computer is the origin address 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 allow packets for the telnet or the rlogin command. ASET, when run at high security, disables the forwarding of Internet Protocol (IP) packets.

In addition, all electronic mail that is sent from the internal network is first sent to the firewall system. The firewall then transfers the mail to a host on an external network. The firewall system receives all incoming electronic mail, and distributes the mail to the hosts on the internal network.

A firewall prevents unauthorized users from accessing the 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 a host from which a user can log in without being required to type in a password. A firewall system should not share any of its file systems, or mount any file systems from other servers.

ASET can be used to harden a machine into a firewall. ASET enforces high security on a firewall system, as described in Chapter 21, Using the Automated Security Enhancement Tool (Tasks). Similarly, IPsec provides firewall protection. For more information on using IPsec to protect network traffic, see “IPsec (Overview)” in System Administration Guide: IP Services.

Packet Smashing

Most local area networks transmit data between computers in blocks that are called packets. Through a procedure that is called packet smashing, unauthorized users can corrupt data. Data can also be destroyed. Packet smashing involves capturing the packets before the packets reach their destination. The intruder then injects arbitrary data into the contents, and sends the packets back on their original course. On a local area network, packet smashing is impossible because packets reach all machines, including the server, at the same time. Packet smashing is possible on a gateway, however, so make sure that all gateways on the network are protected.

The most dangerous attacks are those attacks that affect the integrity of the data. Such attacks involve changing the contents of the packets or impersonating a user. Attacks that involve eavesdropping do not compromise data integrity. An eavesdropper records conversations for later replay. An eavesdropper does not impersonate a user. While eavesdropping attacks do not attack data integrity, the attacks do affect privacy. You can protect the privacy of sensitive information by encrypting data that goes over the network. For how to encrypt IP datagrams, see “Internet Key Exchange” in System Administration Guide: IP Services.

Reporting Security Problems

If you experience a suspected security breach, you can contact the Computer Emergency Response Team/Coordination Center, that is, CERT/CC. CERT/CC is a Defense Advanced Research Projects Agency (DARPA) funded project that is located at the Software Engineering Institute at Carnegie Mellon University. This agency can assist you with any security problems you are having. This agency can also direct you to other Computer Emergency Response Teams that might be more appropriate for 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.