Part XIII Managing System Security

This part provides instructions for managing system security in the Solaris 2.x environment. This part contains these chapters.

Chapter 50 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 System Security"

• "Where to Find System Security Tasks"

• "Granting Access to a Computer System"

• "File Security"

• "System Security"

• "Network Security"

At the file level, the SunOS 5.x 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.

What's New in System Security

This section describes new security features in the Solaris 2.6 release.

Pluggable Authentication Module (PAM)

The Pluggable Authentication Module (PAM) framework enables you to "plug in" new authentication technologies without changing the login, ftp, or telnet commands. You can also use PAM to integrate UNIX login with other security mechanisms like DCE or Kerberos.

Mechanisms for account, session, and password management can also be plugged in using this framework.

Some of the benefits PAM provides are:

• Flexible configuration policy

• Ease of use for the end user

• The ability to pass optional parameters to the user authentication services

See Chapter 53, Using Authentication Services (Tasks) for more information.

Executable Stacks and Security

A number of security bugs are related to default executable stacks when their permissions are set to read, write and execute. While stacks with execute permissions set are mandated by the SPARC ABI and Intel ABI, most programs can function correctly without using executable stacks.

The noexec_user_stack variable is available in the Solaris 2.6 release which enables the system administrator to specify whether stack mappings are executable or not. By default, the variable is zero, which provides ABI-compliant behavior. If the variable is set to non-zero, the system will mark the stack of every process in the system as readable and writable, but not executable.

Once this variable is set, programs that attempt to execute code on their stack will be sent a SIGSEGV signal, which usually results in the program terminating with a core dump. Such programs also generate a warning message that includes the name of the offending program, the process ID, and real UID of the user who ran the program. For example:

a.out[347] attempt to execute code on stack by uid 555 

The message is logged by the syslogd(1m) daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf(4) file, which means the message is sent to both the console and to the /var/adm/messages file.

This message is useful both for observing potential security problems, as well as to identify valid programs that depend upon executable stacks which have been prevented from correct operation by setting this variable. If the administrator does not want any messages logged, then the noexec_user_stack_log variable can be set to zero to disable it in the /etc/system file, though the SIGSEGV signal may continue to cause the executing program to core dump.

You can use mprotect(2) if you want programs to explicitly mark their as stack executable.

Because of hardware limitations, the capability of catching and reporting executable stack problems is only available on sun4m, sun4d and sun4u platforms.

How to Disable Programs From Using Executable Stacks

1. Become superuser.

2. Edit the /etc/system file and add the following line:

   set noexec_user_stack=1

3. Reboot the system.

   # init 6

How to Disable Executable Stack Message Logging

1. Become superuser.

2. Edit the /etc/system file and add the following line:

   set noexec_user_stack_log=0

3. Reboot the system.

   # init 6

Where to Find System Security Tasks

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

• Chapter 51, Securing Files (Tasks)

• Chapter 52, Securing Systems (Tasks)

• Chapter 53, Using Authentication Services (Tasks)

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

Granting Access to a Computer System

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

• Monitoring setuid programs

• Tracking superuser (root) login

• Installing a firewall

• Using Automated Security Enhancement Tool (ASET)

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 2.x system 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 may want to allow some people to read some files, and give other people permission to change or delete some files. You may have some data that you do not want anyone else to see. Chapter 51, 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 may accidently 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.

setuid Programs

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 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 may 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 may be more appropriate to your particular needs. You can call CERT/CC at its 24-hour hotline: (412) 268-7090, or contact the team via email to cert@cert.sei.cmu.edu.

File Security

The SunOS 5.x 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. Table 50-1 describes file system administration commands. See Chapter 51, Securing Files (Tasks) for information on file security.

File Administration Commands

Table 50-1 lists the file administration commands that you can use on files or 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 5.x system software users in the United States--the optional file encryption kit. The encryption kit includes the crypt 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 Chapter 51, Securing Files (Tasks) for information about setting ACLs on files.

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 NIS+ and FNS 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 password to these login accounts.

Table 50-2 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, and known only to users. You should ask your users to choose their passwords carefully, and 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 Chapter 2, Setting Up and Maintaining User Accounts and Groups (Tasks) 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 Solstice User Manager or the passwd(1) 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 Solstice User Manager or the passwd(1) 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 Solstice AdminSuite's User Manager, Admintool, or the passwd(1) 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 sh(1) 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 may want to monitor who has been using the su command, especially those user's 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. Figure 50-1 describes the security restrictions you can impose on remote operations.

Figure 50-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 54, 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. Table 50-3 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 NFS Administration Guide 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 may 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 54, Using Automated Security Enhancement Tool (Tasks) for more information.

Chapter 51 Securing Files (Tasks)

This chapter describes the procedures for securing files. This is a list of the step-by-step instructions in this chapter.

• "How to Display File Information"

• "How to Change the Owner of a File"

• "How to Change Group Ownership of a File"

• "How to Change Permissions in Absolute Mode"

• "How to Change Permissions in Symbolic Mode"

• "How to Set Special Permissions in Absolute Mode"

• "How to Find Files With setuid Permissions"

• "How to Set ACL Entries on a File"

• "How to Check If a File Has an ACL"

• "How to Add or Modify ACL Entries on a File"

• "How to Delete ACL Entries From a File"

• "How to Display ACL Entries for a File"

Introducing File Security

This section describes file security concepts and terminology needed to understand file security.

User Classes

For each file, there are three classes of users:

• The file or directory owner--usually the user who created the file. The owner of a file can decide who has the right to read it, to write to it (make changes to it), or, if it is a command, to execute it.

• Members of a group.

• All others who are not the file or group owner.

Only the owner of the file or root can assign or modify file permissions.

File Permissions

Table 51-1 lists and describes the file permissions.

These file permissions apply to special files such as devices, sockets, and named pipes (FIFOs), as they do to regular files.

For a symbolic link, the permissions that apply are those of the file the link points to.

Directory Permissions

Table 51-2 lists and describes the directory permissions.

You can protect the files in a directory (and in its subdirectories) by disallowing access to that directory. Note, however, that superuser has access to all files and directories on the system.

Default umask

When you create a file or directory, it has a default set of permissions. These default permissions are determined by the value of umask in the system file /etc/profile, or in your .cshrc or .login file. By default, the system sets the permissions on a text file to 666, granting read and write permission to user, group, and others, and to 777 on a directory or executable file.

The value assigned by umask is subtracted from the default. This has the effect of denying permissions in the same way that chmod grants them. For example, while the command chmod 022 grants write permission to group and others, umask 022 denies write permission for group and others.

Table 51-3 shows some typical umask settings, and the effect on an executable file.

File Types

A file can be one of six types. Table 51-4 lists the possible file types.

Displaying File Information

This section describes how to display file information.

How to Display File Information

Display information about all the files in a directory by using the ls command.

$ ls -la

Each line in the display has the following information about a file:

• Type of file and its permissions

• Number of hard links

• Owner of the file

• Group of the file

• Size of the file, in bytes

• Date the file was created or the last date it was changed

• Name of the file

Example--Displaying File Information

The following example displays the partial list of the files in the /sbin directory.

$ cd /sbin
$ ls -la
total 5980
drwxrwxr-x   2 root  sys       512 May  1  1996 ./
drwxr-xr-x  33 root  root     1024 Sep  5 14:42 ../
-r-xr-xr-x   1 bin   bin    118840 Oct 25  1995 autopush*
lrwxrwxrwx   1 root  root       21 May  1  1996 bpgetfile -> ...
-r-xr-xr-x   1 bin   bin    515272 Oct 25  1995 hostconfig*
-r-xr-xr-x   1 bin   bin    569792 Oct 25  1995 ifconfig*
-r-xr-xr-x   1 root  sys    246688 Oct 25  1995 init*
-r-xr-xr-x   2 bin   root   189364 Oct 25  1995 jsh*
-r-xr-xr-x   1 bin   bin    161140 Oct 25  1995 mount*
-r-xr-xr-x   1 root  sys      6908 Jan  1  1970 mountall*
.
.
.

Changing File Ownership

This section describes how to change the ownership of a file.

How to Change the Owner of a File

1. If you are not the owner of the file or directory, become superuser.

   Only the current owner or superuser can use the chown command to change the owner of a file or directory.

2. Change the owner of a file by using the chown command.

   $ chown newowner filename

   newowner	Name of the new owner of the file or directory.
   filename	File or directory.

3. Verify the owner of the file is changed.

   $ ls -l filename

Example--Changing the Owner of a File

The following example sets the ownership on myfile to the user rimmer.

$ chown rimmer myfile
$ ls -l myfile
-rw-r--r--   1 rimmer   scifi   112640 May 24 10:49 myfile

How to Change Group Ownership of a File

1. If you are not the owner of the file or directory, become superuser.

   Only the current owner or superuser can use the chgrp command to change the group of a file or directory.

2. Change the group owner of a file by using the chgrp command.

   $ chgrp group filename

   group	Name of the new group of the file or directory.
   filename	File or directory.

3. Verify the group owner of the file is changed.

   $ ls -l filename

Example--Changing Group Ownership of a File

The following example sets the group ownership on myfile to the group scifi.

$ chgrp scifi myfile
$ ls -l myfile
-rwxrw-- 1 rimmer scifi 12985 Nov 12 16:28 myfile
 

Changing File Permissions

The chmod command enables you to change the permissions on a file. You must be superuser or the owner of a file or directory to change its permissions.

You can use the chmod command to set permissions in either of two modes:

• Absolute Mode - Use numbers to represent file permissions (the method most commonly used to set permissions). When you change permissions by using the absolute mode, represent permissions for each triplet by an octal mode number.

• Symbolic Mode - Use combinations of letters and symbols to add or remove permissions.

Table 51-5 lists the octal values for setting file permissions in absolute mode.

Table 51-6 lists the symbols for setting file permissions in symbolic mode. Symbols can specify whose permissions are to be set or changed, the operation to be performed, or the permissions being assigned or changed.

The who operator permission designations in the function column specifies the symbols that change the permissions on the file or directory.

How to Change Permissions in Absolute Mode

1. If you are not the owner of the file or directory, become superuser.

   Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.

2. Change permissions in absolute mode by using the chmod command.

   $ chmod nnn filename

   nnn	Specifies the octal values that change permissions on the file or directory. See Table 51-5 for the list of valid octal values.
   filename	File or directory.

3. Verify the permissions of the file have changed.

   $ ls -l filename

Example--Changing Permissions in Absolute Mode

The following example sets rwxr-xr-x permissions on myfile.

$ chmod 755 myfile
$ ls -l myfile
-rwxr-xr-x   1 kryten   staff   6144 May 24 10:49 myfile

How to Change Permissions in Symbolic Mode

1. If you are not the owner of the file or directory, become superuser.

   Only the current owner or superuser can use the chmod command to change file permissions on a file or directory.

2. Change permissions in symbolic mode by using the chmod command.

   $ chmod who operator permission filename

   who operator permission	who specifies whose permissions are changed, operator specifies the operation to perform, and permission specifies what permissions are changed. See Table 51-6 for the list of valid symbols.
   filename	Is the file or directory.

3. Verify the permissions of the file have changed.

   $ ls -l filename

Examples--Changing Permissions in Symbolic Mode

The following example takes away read permission from others.

$ chmod o-r filea

The following example adds read and execute permissions for user, group, and others.

$ chmod a+rx fileb

The following example assigns read, write, and execute permissions to group.

$ chmod g=rwx filec
 

Using Special File Permissions (setuid, setgid and Sticky Bit)

Three special types of permissions are available for executable files and public directories. When these permissions are set, any user who runs that executable file assumes the permissions of the owner (or group) of the executable file.

You must be extremely careful when setting special permissions, because special permissions constitute a security risk. For example, a user can gain superuser permission by executing a program that sets the user ID to root.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. See "How to Find Files With setuid Permissions" to search for the file systems and print out a list of all programs using these permissions. A suspicious listing would be one that grants ownership of such a program to a user rather than to bin or sys. Only superuser can set these permissions.

setuid Permission

When set-user identification (setuid) permission is set on an executable file, a process that runs this file is granted access based on the owner of the file (usually root), rather than the user who created the process. This allows a user to access files and directories that are normally only available to the owner. For example, the setuid permission on the passwd command makes it possible for a user to change passwords, assuming the permissions of the root ID:

-r-sr-sr-x   1 root     sys    10332 May  3 08:23 /usr/bin/passwd

This presents a security risk, because some determined users can find a way to maintain the permissions granted to them by the setuid process even after the process has finished executing.

Using setuid permissions with the reserved UIDs (0-99) from a program may not set the effective UID correctly. Use a shell script instead or avoid using the reserved UIDs with setuid permissions.

setgid Permission

The set-group identification (setgid) permission is similar to setuid, except that the process's effective group ID (GID) is changed to the group owner of the file, and a user is granted access based on permissions granted to that group. The /usr/bin/mail program has setgid permissions:

-r-x--s--x   1 bin      mail       62504 May  3 07:58 /usr/bin/mail

When setgid permission is applied to a directory, files created in this directory belong to the group the directory belongs to, not the group the creating process belongs to. Any user who has write permission in the directory can create a file there--however, the file will not belong to the group of the user, but will belong to the group of the directory.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. See "How to Find Files With setuid Permissions" to search for the file systems and print out a list of all programs using these permissions. A suspicious listing would be one that grants ownership of such a program to a user rather than to bin or sys. Only superuser can set these permissions.

Sticky Bit

The sticky bit is a permission bit that protects the files within a directory. If the directory has the sticky bit set, a file can be deleted only by the owner of the file, the owner of the directory, or by root. This prevents a user from deleting other users' files from public directories such as uucppublic:

drwxrwxrwt   2 uucp   uucp   512 May 24 09:48 /var/spool/uucppublic

Be sure to set the sticky bit manually when you set up a public directory on a TMPFS file system.

Setting and Searching for Special Permissions

You can set special permissions on a file in absolute or symbolic modes. In absolute mode, you set special permissions by adding a new octal value to the left of the permission triplet. Table 51-7 lists the octal values to set special permissions on a file.

Table 51-6 lists the symbols to change the special permissions in symbolic mode.

How to Set Special Permissions in Absolute Mode

1. If you are not the owner of the file or directory, become superuser.

   Only the current owner or superuser can use the chmod command to change the special permissions on a file or directory.

2. Change special permissions in absolute mode by using the chmod command.

   $ chmod nnnn filename

   nnnn	Specifies the octal values that change the permissions on the file or directory. The first octal value on the left sets the special permissions on the file. See Table 51-7for the list of valid octal values for the special permissions.
   filename	Is the file or directory.

3. Verify the permissions of the file have changed.

   $ ls -l filename

Examples--Setting Special Permissions in Absolute Mode

The following example sets setuid permission on the dbprog file.

$ chmod 4555 dbprog
$ ls -l dbprog
-r-sr-xr-x   1 db     staff        12095 May  6 09:29 dbprog

The following example sets setgid permission on the dbprog2 file.

$ chmod 2551 dbprog2
$ ls -l dbprog2
-r-xr-s--x   1 db     staff       24576 May  6 09:30 dbprog2

The following example sets sticky bit permission on the pubdir directory.

$ chmod 1777 pubdir
 

How to Find Files With setuid Permissions

1. Become superuser.

2. Find files with setuid permissions set by using the find command.

   # find directory -user root -perm -4000 -exec ls -ldb {}\; >/tmp/filename

   find directory	Checks all mounted paths starting at the specified directory, which can be root (/), sys, bin, or mail.
   -user root	Displays files only owned by root.
   -perm -4000	Displays files only with permissions set to 4000.
   -exec ls -ldb	Displays the output of the find command in ls -ldb format.
   >/tmp/filename	Writes results to this file.

3. Display the results in /tmp/filename.

   If you need background information about setuid permissions, see "setuid Permission".

Example--Finding Files With setuid Permissions

# find / -user root -perm -4000 -exec ls -ldb { }\; > /tmp/ckprm 
	# cat /tmp/ckprm 
	-r-sr-xr-x 1 root bin 38836 Aug 10 16:16 /usr/bin/at
	-r-sr-xr-x 1 root bin 19812 Aug 10 16:16 /usr/bin/crontab
	---s--x--x 1 root sys 46040 Aug 10 15:18 /usr/bin/ct
	-r-sr-xr-x 1 root sys 12092 Aug 11 01:29 /usr/lib/mv_dir
	-r-sr-sr-x 1 root bin 33208 Aug 10 15:55 /usr/lib/lpadmin
	-r-sr-sr-x 1 root bin 38696 Aug 10 15:55 /usr/lib/lpsched
	---s--x--- 1 root rar 45376 Aug 18 15:11 /usr/rar/bin/sh
	-r-sr-xr-x 1 root bin 12524 Aug 11 01:27 /usr/bin/df
	-rwsr-xr-x 1 root sys 21780 Aug 11 01:27 /usr/bin/newgrp
	-r-sr-sr-x 1 root sys 23000 Aug 11 01:27 /usr/bin/passwd
	-r-sr-xr-x 1 root sys 23824 Aug 11 01:27 /usr/bin/su
	#

An unauthorized user (rar) has made a personal copy of /usr/bin/sh, and has set the permissions as setuid to root. This means that rar can execute /usr/rar/bin/sh and become the privileged user. If you want to save this output for future reference, move the file out of the /tmp directory.

Using Access Control Lists (ACLs)

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.

For example, assume you had a file that you wanted everyone in a group to be able to read. With that situation, you would give group read permissions on that file. Now, assume you wanted only one person in the group to be able to write to that file. Standard UNIX doesn't let you set that up. However, you could set up an ACL for that file to give only one person in the group write permissions on the file.

Table 51-8 lists the ACL commands that you can use on files or directories.

ACL entries are the way to define an ACL on a file, and they are set through the ACL commands. ACL entries consist of the following fields separated by colons:

entry_type:[uid|gid]:perms

In an ACL entry,

The following example shows an ACL entry that sets read/write permissions for the user nathan.

user:nathan:rw-

UFS file system attributes such as ACLs are supported in UFS file systems only. This means that if you restore or copy files with ACL entries into the /tmp directory, which is usually mounted as a TMPFS file system, the ACL entries will be lost. Use the /var/tmp directory for temporary storage of UFS files.

ACL Entries for Files

Table 51-9 lists the valid ACL entries. The first three ACL entries provide the basic UNIX file protection.

u[ser]::perms 

g[roup]::perms 

o[ther]:perms 

m[ask]:perms 

u[ser]:uid:perms

g[roup]:gid:perms

ACL Entries for Directories

In addition to the ACL entries described in Table 51-9, you can set default ACL entries on a directory that will apply to files created within the directory. Files created in a directory that has default ACL entries will have the same ACL entries as the default ACL entries. Table 51-10 lists the default ACL entries for directories.

When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the owner, owner's group, others, and the mask (these are required and are the first four default ACL entries in Table 51-10).

d[efault]:u[ser]::perms 

d[efault]:g[roup]::perms 

d[efault]:o[ther]:perms 

d[efault]:m[ask]:perms 

d[efault]:u[ser]:uid:perms

d[efault]:g[roup]:gid:perms

How to Set ACL Entries on a File

1. Set ACL entries on a file by using the setfacl command.

   $ setfacl -s user::perms,group::perms,other:perms,mask:perms,acl_entry_list filename ...

   -s	Replaces the entire ACL with the new ACL entries, if an ACL already exists on the file.
   user::perms	Specifies the owner's permissions.
   group::perms	Specifies the permissions for the owner's group.
   other:perms	Specifies the permissions for users other than the owner or members of the owner's group.
   mask:perms	Specifies the permissions for the ACL mask. The mask indicates the maximum permissions allowed for users (other than the owner) and for groups.
   acl_entry_list	Is the list of one or more ACL entries to set for specific users and groups on the file or directory. You can also set default ACL entries on a directory. Table 51-9 and Table 51-10 show the valid ACL entries.
   filename	File or directory on which to set the ACL entries.

2. To verify that an ACL was set on the file, see "How to Check If a File Has an ACL". To verify which ACL entries were set on the file, use the getfacl command.

   $ getfacl filename

If an ACL already exists on the file, the -s option will replace the entire ACL with the new ACL entries.

Examples--Setting ACL Entries on a File

The following example sets the user permissions to read/write, group permissions to read only, and other permissions to none on the ch1.doc file. In addition, the user george is given read/write permissions on the file, and the ACL mask permissions is set to read/write, which means no user or group can have execute permissions.

$ setfacl -s user::rw-,group::r--,other:---,mask:rw-,
user:george:rw-
ch1.doc
$ ls -l
total 124
-rw-r-----+  1 nathan  sysadmin   34816 Nov 11 14:16 ch1.doc
-rw-r--r--   1 nathan  sysadmin   20167 Nov 11 14:16 ch2.doc
-rw-r--r--   1 nathan  sysadmin    8192 Nov 11 14:16 notes
$ getfacl ch1.doc
# file: ch1.doc
# owner: nathan
# group: sysadmin
user::rw-
user:george:rw-    #effective:rw-
group::r--         #effective:r--
mask:rw-
other:---

The following example sets the user permissions to read/write/execute, group permissions to read only, and other permissions to none on the ch2.doc file. In addition, users in the sysadmin group are given read/write permissions on the file, and the ACL mask permissions is set to read/write.

$ setfacl -s u::7,g::4,o:0,g:sysadmin:6,m:6 ch2.doc 
$ getfacl ch2.doc

How to Check If a File Has an ACL

Check if a file has an ACL by using the ls command.

$ ls -l filename

A `+' to the right of the mode field indicates the file has an ACL.

Example--Checking If a File Has an ACL

The following example shows that ch1.doc has an ACL.

$ ls -l ch1.doc
-rwxr-----+  1 nathan   sysadmin      167 Nov 11 11:13 ch1.doc

How to Add or Modify ACL Entries on a File

1. Add or modify ACL entries on a file by using the setfacl command.

   $ setfacl -m acl_entry_list filename1 [filename2...]

   -m	Modifies the existing ACL entry.
   acl_entry_list	List of one or more ACL entries to add or modify on the file or directory. You can also add or modify default ACL entries on a directory. Table 51-9 and Table 51-10 show the valid ACL entries.
   filename ...	File or directory on which to add or modify ACL entries.

2. To verify that the ACL entries were added or modified on the file, use the getfacl command.

   $ getfacl filename

Examples--Adding or Modifying ACL Entries on a File

The following example adds read/write permissions for the user george on the ch3.doc file.

$ setfacl -m user:george:6 ch3.doc
getfacl ch3.doc
# file: ch3.doc
# owner: george
# group: staff
user::rw-				
user::george:rw-				#effective:rw-
group::r-						#effective:r--
mask:r--
other:r--

The following example adds default ACL entries for the book directory, which already has a default entry specified for the owner of the directory, for the group owner of the directory, and for others. The users in the staff group are given read permissions and the required default mask is set to read/write.

$ setfacl -m default:group:staff:4,default:mask:6 book
getfacl book

How to Delete ACL Entries From a File

1. Delete ACL entries from a file by using the setfacl command.

   $ setfacl -d acl_entry_list filename1 ...

   -d	Deletes the specified ACL entries.
   acl_entry_list	List of ACL entries (without specifying the permissions) to delete from the file or directory. You can only delete ACL entries and default ACL entries for specific users and groups. Table 51-9 and Table 51-10 show the valid ACL entries.
   filename ...	File or directory from which to delete the ACL entries.

   Alternately, you can use the setfacl -s command to delete all the ACL entries on a file and replace them with the new ACL entries specified.

2. To verify that the ACL entries were deleted from the file, use the getfacl command.

   $ getfacl filename

Example--Deleting ACL Entries on a File

The following example deletes read permission for the user nigel on the ch4.doc file.

$ setfacl -d user:nigel:4 ch4.doc
$ getfacl ch4.doc
# file: ch4.doc
# owner: nigel
# group: staff
user::r--
group::r--					#effective:r--
other:r--

How to Display ACL Entries for a File

Display ACL entries for a file by using the getfacl command.

$ getfacl [-a | -d] filename1 ...

If you specify multiple file names on the command line, the ACL entries are separated by a blank line.

Examples--Displaying ACL Entries for a File

The following example shows all the ACL entries for the ch1.doc file. The #effective: note beside the user and group entries indicates what the permissions are after being modified by the ACL mask.

$ getfacl ch1.doc
 
# file: ch1.doc
# owner: nathan
# group: sysadmin
user::rw-
user:george:rw-         #effective:rw-
group::r--              #effective:r--
mask:rw-
other:---

The following example shows the default ACL entries for the book directory.

$ getfacl -d book
 
# file: book
# owner: nathan
# group: sysadmin
default:user::rw-
default:user:george:r--
default:group::rw-
default:mask:rw-
default:other:r--

Chapter 52 Securing Systems (Tasks)

This chapter describes the procedures for securing systems. This is a list of the step-by-step instructions in this chapter.

• "How to Display a User's Login Status"

• "How to Display Users Without Passwords"

• "How to Temporarily Disable User Logins"

• "How to Save Failed Login Attempts"

• "How to Create a Dial-Up Password"

• "How to Temporarily Disable Dial-up Logins"

• "How to Restrict Superuser (root) Login to the Console"

• "How to Monitor Who Is Using the su Command"

• "How to Display Superuser (root) Access Attempts to the Console"

For overview information about securing systems, see "System Security".

Displaying Security Information

This section describes how to display user login information.

How to Display a User's Login Status

1. Become superuser.

2. Display a user's login status by using the logins command.

   # logins -x -l username

   -x	Displays an extended set of login status information.
   -l username	Displays login status for the specified user. username is a user's login name. Multiple login names must be specified as a comma-separated list.

   The logins command uses the local /etc/passwd file and the NIS or NIS+ password databases to obtain a user's login status.

Example--Displaying a User's Login Status

The following example displays login status for the user rimmer.

# logins -x -l rimmer
rimmer       500     staff           10   Arnold J. Rimmer
                     /export/home/rimmer
                     /bin/sh
                     PS 010170 10 7 -1

In this example,

How to Display Users Without Passwords

You should make sure that all users have a valid password.

1. Become superuser.

2. Display users who have no passwords by using the logins command.

   # logins -p

   -p	Displays a list of users with no passwords.

   The logins command uses the local /etc/passwd file and the NIS or NIS+ password databases to obtain a user's login status.

Example--Displaying Users With No Passwords

The following example displays that the user pmorph does not have a password.

# logins -p
pmorph          501     other           1       Polly Morph
# 

Temporarily Disabling User Logins

You can temporarily disable user logins by:

• Creating the /etc/nologin file.

• Bringing the system to run level 0 (single-user mode). See Chapter 7, Shutting Down a System (Tasks) for information on bringing the system to single-user mode.

Creating the /etc/nologin File

Create this file to disallow user logins and notify users when a system will be unavailable for an extended period of time due to a system shut down or routine maintenance.

If a user attempts to log in to a system where this file exists, the contents of the nologin file is displayed, and the user login is terminated. Superuser logins are not affected.

How to Temporarily Disable User Logins

1. Become superuser.

2. Create the /etc/nologin file using an editor.

   # vi /etc/nologin

3. Include a message regarding system availability.

4. Close and save the file.

Example--Disabling User Logins

This example shows how to notify users of system unavailability.

# vi /etc/nologin
(Add system message here)
 
# cat /etc/nologin 
***No logins permitted.***
 
***The system will be unavailable until 12 noon.***

Saving Failed Login Attempts

You can save failed login attempts by creating the /var/adm/loginlog file with read and write permission for root only. After you create the loginlog file, all failed login activity will be written to this file automatically after five failed attempts. See "How to Save Failed Login Attempts" for detailed instructions.

The loginlog file contains one entry for each failed attempt. Each entry contains the user's login name, tty device, and time of the failed attempt. If a person makes fewer than five unsuccessful attempts, none of the attempts are logged.

The loginlog file may grow quickly. To use the information in this file and to prevent the file from getting too large, you must check and clear its contents occasionally. If this file shows a lot of activity, it may suggest an attempt to break into the computer system. For more information about this file, see loginlog(4).

How to Save Failed Login Attempts

1. Become superuser.

2. Create the loginlog file in the /var/adm directory.

   # touch /var/adm/loginlog

3. Set read and write permissions for root on the loginlog file.

   # chmod 600 /var/adm/loginlog

4. Change group membership to sys on the loginlog file.

   # chgrp sys /var/adm/loginlog

5. Make sure the log works by attempting to log into the system five times with the wrong password after the loginlog file is created. Then display the /var/adm/loginlog file.

   # more /var/adm/loginlog pmorph:/dev/pts/0:Fri Jan 13 08:55:23 1996 pmorph:/dev/pts/0:Fri Jan 13 08:55:31 1996 pmorph:/dev/pts/0:Fri Jan 13 08:55:39 1996 pmorph:/dev/pts/0:Fri Jan 13 08:55:50 1996 pmorph:/dev/pts/0:Fri Jan 13 08:56:00 1996 #

Password Protection Using Dial-Up Passwords

You can add a layer of security to your password mechanism by requiring a dial-up password for users who access a system through a modem or dial-up port. A dial-up password is an additional password that a user must enter before being granted access to the system.

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 mechanism is to require a dial-up password to gain access to a gateway system.

Two files are involved in creating a dial-up password, /etc/dialups and /etc/d_passwd. The first contains a list of ports that require a dial-up password, and the second contains a list of shell programs that require an encrypted password as the additional dial-up password.

The /etc/dialups file is a list of terminal devices, for example:

/dev/term/a
/dev/term/b

The /etc/d_passwd file has two fields. The first is the login shell that will require a password, and the second is the encrypted password. The /etc/dialups and /etc/d_passwd files work like this:

When a user attempts to log in on any of the ports listed in /etc/dialups, the login program looks at the user's login entry stored in /etc/passwd, and compares the login shell to the entries in /etc/d_passwd. These entries determine whether the user will be required to supply the dial-up password.

/usr/lib/uucp/uucico:encrypted_password:
/usr/bin/csh:encrypted_password:
/usr/bin/ksh:encrypted_password:
/usr/bin/sh:encrypted_password:

The basic dial-up password sequence is shown in Figure 52-1.

Figure 52-1 Basic Dial-Up Password Sequence

The /etc/d_passwd File

Because most users will be running a shell when they log in, all shell programs should have entries in /etc/d_passwd. Such programs include uucico, sh, ksh, and csh. If some users run something else as their login shell, include that login shell in the file, too.

If the user's login program (as specified in /etc/passwd) is not found in /etc/d_passwd, or 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 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 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 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 will not be prompted for a dial-up password.

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

How to Create a Dial-Up Password

When you first establish a dial-up password, be sure to remain logged in on at least one terminal while testing the password on a different terminal. If you make a mistake while installing the extra password and log off to test the new password, you might not be able to log back on. If you are still logged in on another terminal, you can go back and fix your mistake.

1. Become superuser.

2. Create an /etc/dialups file containing a list of terminal devices, including all the ports that will require dial-up password protection.

   The /etc/dialups file should look like this:

   /dev/term/a

   /dev/term/b

   /dev/term/c

3. Create an /etc/d_passwd file containing the login programs that will require a dial-up password, and the encrypted dial-up password.

   Include shell programs that a user could be running at login, for example, uucico, sh, ksh, and csh. The /etc/d_passwd file should look like this:

   /usr/lib/uucp/uucico:encrypted_password:

   /usr/bin/csh:encrypted_password:

   /usr/bin/ksh:encrypted_password:

   /usr/bin/sh:encrypted_password:

4. Set ownership to root on the two files.

   # chown root /etc/dialups /etc/d_passwd

5. Set group ownership to root on the two files.

   # chgrp root /etc/dialups /etc/d_passwd

6. Set read and write permissions for root on the two files.

   # chmod 600 /etc/dialups /etc/d_passwd

7. Create the encrypted passwords.

   1. Create a temporary user.

      # useradd user-name

   2. Create a password for the temporary user.

      # passwd user-name

   3. Capture the encrypted password.

      # grep user-name /etc/shadow > user-name.temp

   4. Edit the user-name.temp file.

      Delete all fields except the encrypted password (the second field).

      For example, in the following line, the encrypted password is U9gp9SyA/JlSk.

      temp:U9gp9SyA/JlSk:7967:::::7988:

   5. Delete the temporary user.

      # userdel user-name

8. Copy the encrypted password from user-name.temp file into the /etc/d_passwd file.

   You can create a different password for each login shell, or use the same one for each.

How to Temporarily Disable Dial-up Logins

1. Become superuser.

2. Put the following entry by itself into the /etc/d_passwd file:

   /usr/bin/sh:*:

Restricting Superuser (root) Access on the Console

The superuser account is used by the operating system to accomplish basic functions, and has wide-ranging 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, you can log in to a system as superuser only from the console. If anybody remotely logs in to the system to perform an administrative function, they must first log in with their user login and then use the su command to become superuser. See "How to Restrict Superuser (root) Login to the Console" for detailed instructions.

Restricting superuser login to the console is set up by default when you install a system.

How to Restrict Superuser (root) Login to the Console

1. Become superuser.

2. Edit the /etc/default/login file.

3. Uncomment the following line.

   CONSOLE=/dev/console

   Any users who try to remotely log in to this system must first log in with their user login, and then use the su command to become superuser.

4. Attempt to log in remotely as superuser to this system, and verify that the operation fails.

Monitoring Who Is Using the su Command

You can start monitoring su attempts through the /etc/default/su file. Through this file, you can enable the /var/adm/sulog file to monitor each time the su command is used to change to another user. See "How to Monitor Who Is Using the su Command" for step-by-step instructions.

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

Through the /etc/default/su file, you can also set up the system to display 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 on the system you are currently working on. See "How to Display Superuser (root) Access Attempts to the Console" for detailed instructions.

How to Monitor Who Is Using the su Command

1. Become superuser.

2. Edit the /etc/default/su file.

3. Uncomment the following line.

   SULOG=/var/adm/sulog

4. After modifying the /etc/default/su file, use the su command several times and display the /var/adm/sulog file. You should see an entry for each time you used the su command.

   # more /var/adm/sulog SU 12/20 16:26 + pts/0 nathan-root SU 12/21 10:59 + pts/0 nathan-root SU 01/12 11:11 + pts/0 root-joebob SU 01/12 14:56 + pts/0 pmorph-root SU 01/12 14:57 + pts/0 pmorph-root

How 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.

Chapter 53 Using Authentication Services (Tasks)

The first section of this chapter provides information about the authentication mechanisms that may be used with Secure RPC. Both Diffie-Hellman and Kerberos Version 4 authentication are supported. The second section covers the Pluggable Authentication Module (PAM) framework. PAM provides a method to "plug-in" authentication services and provides support for multiple authentication services.

This is a list of the step-by-step instructions in this chapter.

• "How to Set Up NIS+ Credentials for Diffie-Hellman Authentication"

• "How to Set Up NIS Credentials with Diffie-Hellman Authentication"

• "How to Share and Mount Files With Diffie-Hellman Authentication"

• "How to Share and Mount Files With Kerberos Authentication"

• "How to Acquire a Kerberos Ticket for Superuser on a Client"

• "How to Log In to Kerberos Service"

• "How to Access a Directory With Kerberos Authentication"

• "How to Add a PAM Module"

• "How to Prevent Unauthorized Access from Remote Systems with PAM"

• "How to Initiate PAM Error Reporting"

Overview of Secure RPC

Secure RPC is a method of authentication that authenticates both the host and the user making a request. Secure RPC uses either Diffie-Hellman or Kerberos authentication. Both of these authentication mechanisms use DES encryption. Applications that use Secure RPC include NFS and the NIS+ name service.

NFS Services and Secure RPC

The NFS software enables several hosts to share files over the network. Under the NFS system, a server holds the data and resources for several clients. The clients have access to the file systems that the server exports to the clients. Users logged in to the client machine can access the file systems by mounting them from the server. To the user on the client machine, it appears as if the files were local to the client. One of the most common uses of the NFS environment is to allow systems to be installed in offices, while keeping all user files in a central location. Some features of the NFS system, such as the -nosuid mount option, can be used to prohibit the opening of devices as well as file systems by unauthorized users.

The NFS environment uses Secure RPC to authenticate users who make requests over the network. This is known as Secure NFS. The authentication mechanism, AUTH_DH, uses DES encryption with Diffie-Hellman authentication to ensure authorized access. The AUTH_DH mechanism has also been called AUTH_DES. The AUTH_KERB4 mechanism uses DES encryption with Kerberos authentication. This mechanism is has also been called AUTH_KERB.

The NFS Administration Guide describes how to set up and administer Secure NFS. Setting up the NIS+ tables and entering names in the cred table are discussed in Solaris Naming Administration Guide. See "Implementation of Diffie-Hellman Authentication" for an outline of the steps involved in RPC authentication.

DES Encryption

The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt a secret key. If two credential users (or principals) know the same DES key, they can communicate in private, using the key to encipher and decipher text. DES is a relatively fast encryption mechanism. A DES chip makes the encryption even faster; but if the chip is not present, a software implementation is substituted.

The risk of using just the DES key is that, with enough time, an intruder can collect enough cipher-text messages encrypted with the same key to be able to discover the key and decipher the messages. For this reason, security systems such as Secure NFS change the keys frequently.

Diffie-Hellman Authentication

The Diffie-Hellman method of authenticating a user is non-trivial for an intruder to crack. The client and the server each has its own private key (sometimes called a secret key) which they use together with the public key to devise a common key. They use the common key to communicate with each other, using an agreed-upon encryption/decryption function (such as DES). This method was identified as DES authentication in previous Solaris releases.

Authentication is based on the ability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time. Make sure you synchronize the time on the client and the server.

The public and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map, and NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users.

The system administrator is responsible for setting up NIS or NIS+ tables and generating a public key and a private key for each user. The private key is stored encrypted with the user's password. This makes the private key known only to the user.

Implementation of Diffie-Hellman Authentication

This section describes the series of transactions in a client-server session using DH authorization (AUTH_DH).

Generating the Public and Secret Keys

Sometime prior to a transaction, the administrator runs either the newkey or nisaddcred commands that generates a public key and a secret key. (Each user has a unique public key and secret key.) The public key is stored in a public database; the secret key is stored in encrypted form in the same database. To change the key pair, use the chkey command.

Running the keylogin Command

Normally, the login password is identical to the secure RPC password. In this case, a keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin explicitly.

The keylogin program prompts the user for a secure RPC password and uses the password to decrypt the secret key. The keylogin program then passes the decrypted secret key to a program called the keyserver. (The keyserver is an RPC service with a local instance on every computer.) The keyserver saves the decrypted secret key and waits for the user to initiate a secure RPC transaction with a server.

If the passwords are the same, the login process passes the secret key to the keyserver. If the passwords are required to be different and the user must always run keylogin, then the keylogin program may be included in the user's environment configuration file, such as ~/.login, ~/.cshrc, or ~/.profile, so that it runs automatically whenever the user logs in.

Generating the Conversation Key

When the user initiates a transaction with a server:

1. The keyserver randomly generates a conversation key.

2. The kernel uses the conversation key to encrypt the client's time stamp (among other things).

3. The keyserver looks up the server's public key in the public-key database (see the publickey(4) man page).

4. The keyserver uses the client's secret key and the server's public key to create a common key.

5. The keyserver encrypts the conversation key with the common key.

First Contact with the Server

The transmission including the encrypted time stamp and the encrypted conversation key is then sent to the server. The transmission includes a credential and a verifier. The credential contains three components:

• The client's net name

• The conversation key, encrypted with the common key

• A "window," encrypted with the conversation key

The window is the difference the client says should be allowed between the server's clock and the client's time stamp. If the difference between the server's clock and the time stamp is greater than the window, the server would reject the client's request. Under normal circumstances this will not happen because the client first synchronizes with the server before starting the RPC session.

The client's verifier contains:

• The encrypted time stamp

• An encrypted verifier of the specified window, decremented by 1

The window verifier is needed in case somebody wants to impersonate a user and writes a program that, instead of filling in the encrypted fields of the credential and verifier, just stuffs in random bits. The server will decrypt the conversation key into some random key and use it to try to decrypt the window and the time stamp. The result will be random numbers. After a few thousand trials, however, there is a good chance that the random window/time stamp pair will pass the authentication system. The window verifier makes guessing the right credential much more difficult.

Decrypting the Conversation Key

When the server receives the transmission from the client:

1. The keyserver local to the server looks up the client's public key in the publickey database.

2. The keyserver uses the client's public key and the server's secret key to deduce the common key--the same common key computed by the client. (Only the server and the client can calculate the common key because doing so requires knowing one secret key or the other.)

3. The kernel uses the common key to decrypt the conversation key.

4. The kernel calls the keyserver to decrypt the client's time stamp with the decrypted conversation key.

Storing Information on the Server

After the server decrypts the client's time stamp, it stores four items of information in a credential table:

• The client's computer name

• The conversation key

• The window

• The client's time stamp

The server stores the first three items for future use. It stores the time stamp to protect against replays. The server accepts only time stamps that are chronologically greater than the last one seen, so any replayed transactions are guaranteed to be rejected.

Implicit in these procedures is the name of the caller, who must be authenticated in some manner. The keyserver cannot use DES authentication to do this because it would create a deadlock. To solve this problem, the keyserver stores the secret keys by UID and grants requests only to local root processes.

Verifier Returned to the Client

The server returns a verifier to the client, which includes:

• The index ID, which the server records in its credential cache

• The client's time stamp minus 1, encrypted by conversation key

The reason for subtracting 1 from the time stamp is to ensure that the time stamp is invalid and cannot be reused as a client verifier.

Client Authenticates the Server

The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what time stamp the client sent.

Additional Transactions

With every transaction after the first, the client returns the index ID to the server in its second transaction and sends another encrypted time stamp. The server sends back the client's time stamp minus 1, encrypted by the conversation key.

Kerberos Version 4

Kerberos is an authentication system that was developed at the Massachusetts Institute of Technology. Kerberos uses DES encryption to authenticate a user when logging in to the system. Authentication is based on the ability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time. Kerberos Version 4 is supported in the Solaris 2.6 release.

Kerberos works by authenticating the user's login password. A user enters the kinit command, which acquires a ticket that is valid for the time of the session (or eight hours, the default session time) from the Kerberos authentication server. When the user logs out, the ticket can be destroyed (using the kdestroy command).

The Kerberos software is available from MIT project Athena, and is not part of the SunOS 5.x software. SunOS 5.x software provides:

• Commands and APIs used by the client to create, acquire, and verify tickets

• An authentication option to Secure RPC

• A client-side daemon, kerbd(1M)

"Implementation of Kerberos Authentication with NFS" gives an overview of how the Kerberos authentication procedure works.

Solaris provides the ability to connect to the Kerberos functionality. It does not provide the Kerberos package. However, you can ftp Kerberos 4 source from athena-dist.mit.edu using anonymous as a username and your email address as a password. The source is located in the pub/kerberos directory.

Implementation of Kerberos Authentication with NFS

The following process assumes that the Kerberos key distribution center (KDC) is already installed on the network, using publicly available sources from MIT project Athena.

1. The /usr/sbin/kerbd daemon must be running on the NFS client and server.

   This daemon is normally started when needed by inetd. The rpcinfo command can be used to make sure that the kerbd service is registered. kerbd is the user-mode daemon. It interfaces with the kernel RPC and the KDC. It generates and validates authentication tickets.

2. The system administrator sets up the NFS server to use Kerberos authentication.

   The MIT Kerberos software is used to register the principal names in the Kerberos key distribution center (KDC) on the Kerberos server. The following entries are required:

   • root.hostname (required for each NFS client)

   • nfs.hostname (required for each NFS server)

3. The user mounts the shared file system.

   The user on the client must get a ticket for root on the client to mount the shared file system.

4. The user logs in to the Kerberos service, using the kinit command.

   The Kerberos authentication server authenticates the request, and grants a ticket for the ticket-granting service.

5. The user accesses the mounted directory.

   The kerbd daemon automatically secures a ticket on behalf of the client for the NFS server exporting the file system. At this point, there are two valid tickets, the original ticket-granting ticket and one for the server.

6. The user destroys the tickets at the end of the session to prevent them from being compromised.

   The kdestroy command destroys the user's active Kerberos authorization tickets by writing zeros to the file that contains the tickets. You can put the kdestroy command in your .logout file, so that all Kerberos tickets are automatically destroyed when you log out of the system.

7. If tickets have been destroyed before the session has finished, the user must request a new ticket with the kinit command.

Administering Diffie-Hellman Authentication

A system administrator can implement policies that help secure the network. The level of security required will differ with each site. This section provides instructions for some tasks associated with network security.

How to Restart the Keyserver

1. Become superuser.

2. Verify that the keyserv daemon (the keyserver) is not running.

   # ps -ef | grep keyserv root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv

3. Start the keyserver if it isn't running.

   # /usr/sbin/keyserv

How to Set Up NIS+ Credentials for Diffie-Hellman Authentication

For detailed description of NIS+ security, see Solaris Naming Administration Guide.

To set up a new key for root on an NIS+ client:

1. Become superuser.

2. Edit the /etc/nsswitch.conf file and add the following line:

   publickey: nisplus

3. Initialize the NIS+ client.

   # nisinit -cH hostname

   hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client machine.

4. Add the client to the cred table by typing the following commands.

   # nisaddcred local # nisaddcred des

5. Verify the setup by using the keylogin command.

   If you are prompted for a password, the procedure has succeeded.

Example of Setting Up a New Key for root on a NIS+ Client

The following example uses the host pluto to set up earth as an NIS+ client. You can ignore the warnings. The keylogin command is accepted, verifying that earth is correctly set up as a secure NIS+ client.

# nisinit -cH pluto
NIS Server/Client setup utility.
This machine is in the North.Abc.COM. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@North.Abc.COM
Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.)
 
Network password: xxx <Press Return>
Warning, password differs from login password.
Retype password: xxx <Press Return>
 
# keylogin
Password:
#

To set up a new key for an NIS+ user:

1. Add the user to the cred table on the root master server by typing the following command:

   # nisaddcred -p unix.UID@domainname -P username.domainname. des

   Note that, in this case, the username-domainname must end with a dot (.)

2. Verify the setup by logging in as the client and typing the keylogin command.

Example of Setting Up a New Key for an NIS+ User

The following example gives DES security authorization to user george.

# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des
DES principal name : unix.1234@North.Abc.COM
Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.)
 
Password:
Retype password:
 
# rlogin rootmaster -l george
# keylogin
Password:
#

How to Set Up NIS Credentials with Diffie-Hellman Authentication

To create a new key for sueruser on a client:

1. Become superuser on the client.

2. Edit the /etc/nsswitch.conf file and add the following line:

   publickey: nis

3. Create a new key pair by using the newkey command.

   # newkey -h hostname

   hostname is the name of the client.

Example of Setting Up an NIS+ Client to Use Diffie-Hellman Security

The following example sets up earth as a secure NIS client.

# newkey -h earth
Adding new key for unix.earth@North.Abc.COM
New Password:
Retype password:
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

To create a new key for a user:

1. Log in to the server as superuser.

   Only the system administrator, logged in to the NIS+ server, can generate a new key for a user.

2. Create a new key for a user.

   # newkey -u username

   username is the name of the user. The system prompts for a password. The system administrator can type a generic password. The private key is stored encrypted with the generic password.

   # newkey -u george Adding new key for unix.12345@Abc.North.Acme.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. #

3. Tell the user to log in and type the chkey -p command.

   This allows the user to re-encrypt their private key with a password known only to the user.

   earth% chkey -p Updating nis publickey database. Reencrypting key for unix.12345@Abc.North.Acme.COM Please enter the Secure-RPC password for george: Please enter the login password for george: Sending key change request to pluto... #

   ---

   Note -

   The chkey command can be used to create a new key-pair for a user.

   ---

How to Share and Mount Files With Diffie-Hellman Authentication

Prerequisite

The Diffie-Hellman publickey authentication must be enabled on the network. See "How to Set Up NIS+ Credentials for Diffie-Hellman Authentication", and "How to Set Up NIS Credentials with Diffie-Hellman Authentication".

To share a file system with Diffie-Hellman authentication:

1. Become superuser.

2. Share the file system with Diffie-Hellman authentication.

   # share -F nfs -o sec=dh /filesystem

To mount a file system with Diffie-Hellman authentication:

1. Become superuser.

2. Mount the file system with Diffie-Hellman authentication.

   # mount -F nfs -o sec=dh server:resource mountpoint

   The -o sec=dh option mounts the file system with AUTH_DH authentication.

Administering Kerberos Version 4 Authentication

A system administrator can implement policies that help secure the network. The level of security required will differ with each site. This section provides instructions for some tasks associated with network security.

How to Share and Mount Files With Kerberos Authentication

Prerequisite

Kerberos Version 4 authentication must be enabled on the network.

To share a file system with Kerberos authentication:

1. Become superuser.

2. Share the file system with Kerberos authentication.

   # share -F nfs -o sec=krb4 /filesystem

To mount a file system with Kerberos authentication:

1. Become superuser.

2. Mount the file system with Kerberos authentication.

   # mount -F nfs -o sec=krb4 server:resource mountpoint

   The -o sec=krb4 option mounts the file system with AUTH_KERB authentication.

How to Acquire a Kerberos Ticket for Superuser on a Client

If the NFS file system that you need to access has not been mounted, you need to acquire a ticket for superuser on the client before mounting it.

To acquire a ticket for a not-yet-mounted file system:

1. Become superuser.

2. Acquire a Kerberos ticket on the client.

   # kinit root.hostname

   hostname is the name of the client system.

   # kinit root.earth Password: #

To acquire a ticket for a mounted file system:

If the entry root.hostname for the client has been entered into the /etc/srvtab configuration file, you can use the ksrvtgt command to get a ticket for superuser. In this case, you are not required to give a superuser password. Consult the MIT documentation for information about initializing the /etc/srvtab file.

1. Become superuser.

2. Acquire a ticket for a mounted file system.

   # ksrvtgt root.hostname

Example--Acquiring a Kerberos Ticket for Superuser on a Client

# ksrvtgt root.earth
#

How to Log In to Kerberos Service

Log in to the Kerberos service by using the kinit -l username command.

earth% kinit -l username 

The kinit command prompts you for the ticket lifetime (-l option), and your password. It prints out ticket status using the verbose mode (-v option).

Example of Logging In to Kerberos Service

earth% kinit -l jjones
SunOS (earth)
Kerberos Initialization for "jjones"
Kerberos ticket lifetime (minutes): 480
Password:
earth%

How to List Kerberos Tickets

earth% klist

Example of Listing Kerberos Tickets

earth% klist
Ticket file: /tmp/tkt8516
Principal: jjones@North.Abc.COM
  Issued            Expires          Principal
  Jan 14 20:40:54   Jan
15:04:40:54  krbtgt.North.Abc.COM@North.Abc.COM

How to Access a Directory With Kerberos Authentication

Type cd /mountpoint.

Access the mounted directory, just as you would any other mounted directory. You can list the files in the directory with the ls command, or list the Kerberos tickets with the klist command.

Example of Accessing a Directory With Kerberos Authentication

In the following example, user jjones can change to the mounted mntkrb directory and list the files in this directory.

The kerbd daemon has automatically secured a ticket on the user's behalf for the NFS server exporting the file system. At this point there are two valid tickets--the original ticket-granting ticket, and the server ticket. These two tickets are listed by klist.

earth% cd /mntkrb
earth% ls -l /mntkrb
-rw-r--r-- 1 marks  staff  29 Jul 14 12:22 sports
drwxr-xr-x 3 jjones staff 512 Sep 13 13:44 market
 
earth% klist
Ticket file: /tmp/tkt8516
Principal: jjones@North.Abc.COM
  Issued            Expires          Principal
  Jan 14 20:40:54   Jan
15:04:40:54  krbtgt.North.Abc.COM@North.Abc.COM
  Jan 14 20:43:21   Jan 15:04:43:21  nfs.pluto@North.Abc.COM

How to Destroy a Kerberos Ticket

Enter kdestroy.

Destroy Kerberos tickets when the session is over, so that an unauthorized user cannot to gain access to it. If you want to reinitiate Kerberos authentication, use the kinit command.

Example of Destroying a Kerberos Ticket

The following example shows how to destroy the Kerberos ticket. If the user then tries to change to or list a Kerberos-protected directory, the ticket server denies access.

earth% kdestroy
Tickets destroyed
earth% ls /mntkrb
Can't get Kerberos key: No ticket file (tf_util)
NFS getattr failed for server pluto: RPC: Authentication error
can not access directory /mntkrb.

Introduction to PAM

The Pluggable Authentication Module (PAM) framework lets you "plug in" new authentication technologies without changing system entry services such as login, ftp, telnet, and so on. You can also use PAM to integrate UNIX login with other security mechanisms like DCE or Kerberos. Mechanisms for account, session, and password management can also be "plugged-in" using this framework.

Benefits of Using PAM

The PAM framework allows a system administrator to choose any combination of system entry services (ftp, login, telnet, or rsh, for example) for user authentication. Some of the benefits PAM provides are:

• Flexible configuration policy

  • Per application authentication policy

  • The ability to choose a default authentication mechanism

  • Multiple passwords on high-security systems

• Ease of use for the end user

  • No retyping of passwords if they are the same for different mechanisms

  • The ability to use a single password for multiple authentication methods with the password mapping feature, even if the passwords associated with each authentication method are different

  • The ability to prompt the user for passwords for multiple authentication methods without having the user enter multiple commands.

• The ability to pass optional parameters to the user authentication services

Overview of PAM

PAM employs run-time pluggable modules to provide authentication for system entry services. These modules are broken into four different types based on their function: authentication, account management, session management, and password management. A stacking feature is provided to let you authenticate users through multiple services, as well as a password-mapping feature to not require that users remember multiple passwords.

PAM Module Types

It is important to understand the PAM module types because the module type defines the interface to the module. These are the four types of run-time PAM modules:

• The authentication modules provide authentication for the users and allow for credentials to be set, refreshed, or destroyed. They provide a valuable administration tool for user identification.

• The account modules check for password aging, account expiration, and access hour restrictions. After the user is identified through the authentication modules, the account modules determine if the user should be given access.

• The session modules manage the opening and closing of an authentication session. They can log activity or provide for clean-up after the session is over.

• The password modules allow for changes to the actual password.

Stacking Feature

The PAM framework provides a method for authenticating users with multiple services using stacking. Depending on the configuration, the user can be prompted for passwords for each authentication method. The order in which the authentication services are used is determined through the PAM configuration file.

Password-Mapping Feature

The stacking method can require that a user remember several passwords. With the password-mapping feature, the primary password is used to decrypt the other passwords, so the user doesn't need to remember or enter multiple passwords. The other option is to synchronize the passwords across each authentication mechanism. Note that this could increase the security risk, since the security of each mechanism is limited by the least secure password method used in the stack.

PAM Functionality

The PAM software consists of a library, several modules, and a configuration file. New versions of several system entry commands or daemons which take advantage of the PAM interfaces are also included.

Figure 53-1 illustrates the relationship between the applications, the PAM library, the pam.conf file, and the PAM modules.

Figure 53-1 How PAM Works

The applications (ftp, telnet, and login) use the PAM library to access the appropriate module. The pam.conf file defines which modules to use, and in what order they are to be used with each application. Responses from the modules are passed back through the library to the application.

The following sections describe this relationship.

PAM Library

The PAM library, /usr/lib/libpam, provides the framework to load the appropriate modules and manage the stacking process. It provides a generic structure to which all of the modules can plug in.

PAM Modules

Each PAM module implements a specific mechanism. When setting up PAM authentication, you need to specify both the module and the module type, which defines what the module will do. More than one module type (auth, account, session, or password) may be associated with each module.

The following list describes each of the PAM modules.

• The pam_unix module, /usr/lib/security/pam_unix.so.1, provides support for authentication, account management, session management, and password management. Any of the four module type definitions can be used with this module (see the pam_unix(5) man page). It uses UNIX passwords for authentication. In the Solaris environment, the selection of appropriate name services to get password records is controlled through the /etc/nsswitch.conf file.

• The dial_auth module, /usr/lib/security/pam_dial_auth.so.1, can only be used for authentication (see the pam_dial_auth(5) man page). It uses data stored in the /etc/dialups and /etc/d_passwd files for authentication. This is mainly used by login.

• The rhosts_auth module, /usr/lib/security/pam_rhosts_auth.so.1, can also only be used for authentication (see the pam_rhosts_auth(5) man page). It uses data stored in the ~/.rhosts and /etc/host.equiv files through ruserok(). This is mainly used by the rlogin and rsh commands.

  For security reasons, these module files must be owned by root and must not be writable through group or other permissions. If the file is not owned by root, PAM will not load the module.

PAM Configuration File

The PAM configuration file, /etc/pam.conf, determines the authentication services to be used, and in what order they are used. This file can be edited to select authentication mechanisms for each system-entry application.

Configuration File Syntax

The PAM configuration file consists of entries with the following syntax:

service_name module_type control_flag module_path module_options

You can add comments to the pam.conf file by starting the line with a # (pound sign). Use white space to delimit the fields.

An entry in the PAM configuration file is ignored if one of the following conditions exist: the line has less than four fields, an invalid value is given for module_type or control_flag, or the named module is not found.

Valid Service Names

Table 53-1 lists some of the valid service names, the module types that can be used with that service, and the daemon or command associated with the service name.

There are several module types that are not appropriate for each service. For example, the -password module type is only specified to go with the passwd command. There is no -auth module type associated with this command since it is not concerned with authentication.

Control Flags

To determine continuation or failure behavior from a module during the authentication process, you must select one of four control flags for each entry. The control flags indicate how a successful or a failed attempt through each module are handled. Even though these flags apply to all module types, the following explanation assumes that these flags are being used for authentication modules. The control flags are as follows:

• required - This module must return success in order to have the overall result be successful.

  If all of the modules are labeled as required, then authentication through all modules must succeed for the user to be authenticated.

  If some of the modules fail, then an error value from the first failed module is reported.

  If a failure occurs for a module flagged as required, all modules in the stack are still tried but failure is returned.

  If none of the modules are flagged as required, then at least one of the entries for that service must succeed for the user to be authenticated.

• requisite - This module must return success for additional authentication to occur.

  If a failure occurs for a module flagged as requisite, an error is immediately returned to the application and no additional authentication is done. If the stack does not include prior modules labeled as required that failed, then the error from this module is returned. If a earlier module labeled as required has failed, the error message from the required module is returned.

• optional - If this module fails, the overall result can be successful if another module in this stack returns success.

  The optional flag should be used when one success in the stack is enough for a user to be authenticated. This flag should only be used if it is not important for this particular mechanism to succeed.

  If your users need to have permission associated with a specific mechanism to get their work done, then you should not label it as optional.

• sufficient - If this module is successful, skip the remaining modules in the stack, even if they are labeled as required.

  The sufficient flag indicates that one successful authentication will be enough for the user to be granted access.

  More information about these flags is provided in "Configuring PAM" which describes the default /etc/pam.conf file.

Generic pam.conf File

The following is an example of a generic pam.conf file:

# PAM configuration
# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	required	/usr/lib/security/pam_dial_auth.so.1
rlogin	auth	sufficient	/usr/lib/security/pam_rhost_auth.so.1
rlogin	auth	required	/usr/lib/security/pam_unix.so.1
dtlogin	auth	required	/usr/lib/security/pam_unix.so.1
telnet	auth	required	/usr/lib/security/pam_unix.so.1
su	auth	required	/usr/lib/security/pam_unix.so.1
ftp	auth	required	/usr/lib/security/pam_unix.so.1
uucp	auth	required	/usr/lib/security/pam_unix.so.1
rsh	auth	required	/usr/lib/security/pam_rhost_auth.so.1
OTHER	auth	required	/usr/lib/security/pam_unix.so.1
#
# Account management
#
login	account	required	/usr/lib/security/pam_unix.so.1
rlogin	account	required	/usr/lib/security/pam_unix.so.1
dtlogin	account	required	/usr/lib/security/pam_unix.so.1
telnet	account	required	/usr/lib/security/pam_unix.so.1
ftp	account	required	/usr/lib/security/pam_unix.so.1
OTHER	account	required	/usr/lib/security/pam_unix.so.1
#
# Session management
#
login	session	required	/usr/lib/security/pam_unix.so.1
rlogin	session	required	/usr/lib/security/pam_unix.so.1
dtlogin	session	required	/usr/lib/security/pam_unix.so.1
telnet	session	required	/usr/lib/security/pam_unix.so.1
uucp	session	required	/usr/lib/security/pam_unix.so.1
OTHER	session	required	/usr/lib/security/pam_unix.so.1
#
# Password management
#
passwd	password	required	/usr/lib/security/pam_unix.so.1
OTHER	password	required	/usr/lib/security/pam_unix.so.1

This generic pam.conf file specifies:

1. When running login, authentication must succeed for both the pam_unix and the pam_dial_auth modules.

2. For rlogin, authentication through the pam_unix module must succeed, if authentication through pam_rhost_auth fails.

3. The sufficient control flag indicates that for rlogin the successful authentication provided by the pam_rhost_auth module is sufficient and the next entry will be ignored.

4. Most of the other commands requiring authentication require successful authentication through the pam_unix module.

5. Authentication for rsh must succeed through the pam_rhost_auth module.

The OTHER service name allows a default to be set for any other commands requiring authentication that are not included in the file. The OTHER option makes it easier to administer the file, since many commands that are using the same module can be covered using only one entry. Also, the OTHER service name, when used as a "catch-all," can ensure that each access is covered by one module. By convention, the OTHER entry is included at the bottom of the section for each module type.

The rest of the entries in the file control the account, session and password management.

With the use of the default service name, OTHER, the generic PAM configuration file is simplified to:

# PAM configuration
#
# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	required	/usr/lib/scurty/pam_dial_auth.so.1
rlogin	auth	sufficient	/usr/lib/security/pam_unix.so.1
rlogin	auth	required	/usr/lib/security/pam_rhost_auth.so.1
rsh	auth	required	/usr/lib/security/pam_rhost_auth.so.1
OTHER	auth	required	/usr/lib/security/pam_unix.so.1
#
# Account management
#
OTHER	account	required	/usr/lib/security/pam_unix.so.1
#
# Session management
#
OTHER	session	required	/usr/lib/security/pam_unix.so.1
#
# Password management
#
OTHER	password	required	/usr/lib/security/pam_unix.so.1

Normally, the entry for the module_path is "root-relative." If the filename you enter for module_path does not begin with a slash (/), the path /usr/lib/security/ is prepended to the filename. A full pathname must be used for modules located in other directories.

The values for the module_options can be found in the man pages for the module (for example, pam_unix(5)).

The use_first_pass and try_first_pass options, which are supported by the pam_unix module, let users reuse the same password for authentication without retyping it.

If login specifies authentication through both pam_local and pam_unix, then the user is prompted to enter a password for each module. In situations where the passwords are the same, the use_first_pass module option prompts for only one password and uses that password to authenticate the user for both modules. If the passwords are different, the authentication fails. In general, this option should be used with an optional control flag, as shown below, to make sure that the user can still log in.

# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	optional	/usr/lib/security/pam_local.so.1	use_first_pass

If the try_first_pass module option is used instead, the local module prompts for a second password if the passwords do not match or if an error is made. If both methods of authentication are necessary for a user to get access to all the tools they need, using this option could cause some confusion for the user since the user could get access with only one type of authentication.

Configuring PAM

The section below discusses some of the tasks that may be required to make the PAM framework fully functional. In particular, you should be aware of some of the security issues associated with the PAM configuration file.

Planning for PAM

When deciding how best to employ PAM in your environment, start by focusing on these issues:

• Determine what your needs are, especially which modules you should select.

• Identify the services that need special attention; use OTHER if appropriate.

• Decide on the order in which the modules should be run.

• Select the control flag for that module.

• Choose any options necessary for the module.

  Here are some suggestions to consider before changing the configuration file:

• Use the OTHER entry for each module type so that every application does not have to be included.

• Make sure to consider the security implications of the sufficient and optional control flags.

• Review the man pages associated with the modules to understand how each module will function, what options are available, and the interactions between stacked modules.

  ---

  Caution -

  If the PAM configuration file is misconfigured or gets corrupted, it is possible that even the superuser would be unable to log in. Since sulogin does not use PAM, the superuser would then be required to boot the machine into single user mode and fix the problem.

  ---

  After changing the /etc/pam.conf file, review it as much as possible while still logged in as superuser. Test all of the commands that might have been affected by your changes. For example, if you added a new module to the telnet service, use the telnet command and verify that the changes you made behave as expected.

How to Add a PAM Module

1. Become superuser.

2. Determine which control flags and other options should be used.

   Refer to "PAM Modules" information on the module.

3. Copy the new module to /usr/lib/security.

4. Set the permissions so that the module file is owned by root and permissions are 555.

5. Edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services.

Verification

It is very important to do some testing before the system is rebooted in case the configuration file is misconfigured. Run rlogin, su, and telnet before rebooting the system. If the service is a daemon spawned only once when the system is booted, it may be necessary to reboot the system before you can verify that the module has been added.

How to Prevent Unauthorized Access from Remote Systems with PAM

Remove the rlogin auth rhosts_auth.so.1 entry from the PAM configuration file. This prevents reading the ~/.rhosts files during an rlogin session and therefore prevents unauthenticated access to the local system from remote systems. All rlogin access requires a password, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.

To prevent other unauthenticated access to the ~/.rhosts files, remember to disable the rsh service. The best way to disable a service is to remove the service entry from /etc/inetd.conf. Changing the PAM configuration file does not prevent the service from being started.

How to Initiate PAM Error Reporting

1. Edit the /etc/syslog.conf to add any of the following PAM error reporting entries:

   • auth.alert -- messages about conditions that should be fixed immediately

   • auth.crit -- critical messages

   • auth.err -- error messages

   • auth.info -- informational messages

   • auth.debug -- debugging messages

2. Restart the syslog daemon or send a SIGHUP signal to it to activate the PAM error reporting.

Example--Initiating PAM Error Reporting

The example below displays all alert messages on the console. Critical messages are mailed to root. Informational and debug messages are added to the /var/log/pamlog file.

auth.alert	/dev/console
auth.crit	'root'
auth.info;auth.debug	/var/log/pamlog

Each line in the log contains a time stamp, the name of the system that generated the message, and the message itself. The pamlog file is capable of logging a large amount of information.

Chapter 54 Using Automated Security Enhancement Tool (Tasks)

This chapter describes how to use the Automated Security Enhancement Tool (ASET) to monitor or restrict access to system files and directories.

This is a list of step-by-step instructions in this chapter.

• "How to Run ASET Interactively"

• "How to Run ASET Periodically"

• "How to Stop Running ASET Periodically"

• "How to Collect Reports on a Server"

Automated Security Enhancement Tool (ASET)

SunOS 5.x system software includes the Automated Security Enhancement Tool (ASET). ASET helps you monitor and control system security by automatically performing tasks that you would otherwise do manually.

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.

There are seven tasks involved with ASET, each performing specific checks and adjustments to system files. The ASET tasks tighten file permissions, check the contents of critical system files for security weaknesses, and monitor crucial areas. ASET can safeguard a network by applying the basic requirements of a firewall system to a system that serves as a gateway system. (See "Firewall Setup" on page 598.)

ASET uses master files for configuration. Master files, reports, and other ASET files are in the /usr/aset directory. These files can be changed to suit the particular requirements of your site.

Each task generates a report noting detected security weaknesses and changes the task has made to the system files. When run at the highest security level, ASET will attempt to modify all system security weaknesses. If it cannot correct a potential security problem, ASET reports the existence of the problem.

You can initiate an ASET session by using the /usr/aset command interactively, or you can also set up ASET to run periodically by putting an entry into the crontab file.

ASET tasks are disk-intensive and can interfere with regular activities. To minimize the impact on system performance, schedule ASET to run when system activity level is lowest, for example, once every 24 or 48 hours at midnight.

ASET Security Levels

ASET can be set to operate at one of three security levels: low, medium, or high. At each higher level, ASET's file-control functions increase to reduce file access and heighten system security. These functions range from monitoring system security without limiting users' file access, to increasingly tightening access permissions until the system is fully secured.

The three levels are outlined below:

• Low security - This level ensures that attributes of system files are set to standard release values. ASET performs several checks and reports potential security weaknesses. At this level, ASET takes no action and does not affect system services.

• Medium security - This level provides adequate security control for most environments. ASET modifies some of the settings of system files and parameters, restricting system access to reduce the risks from security attacks. ASET reports security weaknesses and any modifications it makes to restrict access. At this level, ASET does not affect system services.

• High security - This level renders a highly secure system. ASET adjusts many system files and parameter settings to minimum access permissions. Most system applications and commands continue to function normally, but at this level, security considerations take precedence over other system behavior.

ASET does not change the permissions of a file to make it less secure, unless you downgrade the security level or intentionally revert the system to the settings that existed prior to running ASET.

ASET Tasks

This section discusses what ASET does. You should understand each ASET task--what its objectives are, what operations it performs, and what system components it affects--to interpret and use the reports effectively.

ASET report files contain messages that describe as specifically as possible any problems discovered by each ASET task. These messages can help you diagnose and correct these problems. However, successful use of ASET assumes that you possess a general understanding of system administration and system components. If you are a new administrator, you can refer to other SunOS 5.x system administration documentation and related manual pages to prepare yourself for ASET administration.

The taskstat utility identifies the tasks that have been completed and the ones that are still running. Each completed task produces a report file. For a complete description of the taskstat utility, refer to taskstat(1M).

System Files Permissions Verification

This task sets the permissions on system files to the security level you designate. It is run when the system is installed. If you decide later to alter the previously established levels, run this task again. At low security, the permissions are set to values that are appropriate for an open information-sharing environment. At medium security, the permissions are tightened to produce adequate security for most environments. At high security, they are tightened to severely restrict access.

Any modifications that this task makes to system files permissions or parameter settings are reported in the tune.rpt file. "Tune Files" shows an example of the files that ASET consults when setting permissions.

System Files Checks

This task examines system files and compares each one with a description of that file listed in a master file. The master file is created the first time ASET runs this task. The master file contains the system file settings enforced by checklist for the specified security level.

A list of directories whose files are to be checked is defined for each security level. You can use the default list, or you can modify it, specifying different directories for each level.

For each file, the following criteria are checked:

• Owner and group

• Permission bits

• Size and checksum

• Number of links

• Last modification time

Any discrepancies found are reported in the cklist.rpt file. This file contains the results of comparing system file size, permission, and checksum values to the master file.

User/Group Checks

This task checks the consistency and integrity of user accounts and groups as defined in the passwd and group files. It checks the local, and NIS or NIS+ password files. NIS+ password file problems are reported but not corrected. This task checks for the following violations:

• Duplicate names or IDs

• Entries in incorrect format

• Accounts without a password

• Invalid login directories

• The nobody account

• Null group password

• A plus sign (+) in the /etc/passwd file on an NIS (or NIS+) server

Discrepancies are reported in the usrgrp.rpt file.

System Configuration Files Check

During this task, ASET checks various system tables, most of which are in the /etc directory. These files are:

• /etc/default/login

• /etc/hosts.equiv

• /etc/inetd.conf

• /etc/aliases

• /var/adm/utmp

• /var/adm/utmpx

• /.rhosts

• /etc/vfstab

• /etc/dfs/dfstab

• /etc/ftpusers

ASET performs various checks and modifications on these files, and reports all problems in the sysconf.rpt file.

Environment Check

This task checks how the PATH and UMASK environment variables are set for root, and other users, in the /.profile, /.login, and /.cshrc files.

The results of checking the environment for security are reported in the env.rpt file.

eeprom Check

This task checks the value of the eeprom security parameter to ensure that it is set to the appropriate security level. You can set the eeprom security parameter to none, command, or full.

ASET does not change this setting, but reports its recommendations in the eeprom.rpt file.

Firewall Setup

This task ensures that the system can be safely used as a network relay. It protects an internal network from external public networks by setting up a dedicated system as a firewall, which is described in "Firewall Systems". The firewall system separates two networks, each of which approaches the other as untrusted. The firewall setup task disables the forwarding of Internet Protocol (IP) packets and hides routing information from the external network.

The firewall task runs at all security levels, but takes action only at the highest level. If you want to run ASET at high security, but find that your system does not require firewall protection, you can eliminate the firewall task by editing the asetenv file.

Any changes made are reported in the firewall.rpt file.

ASET Execution Log

ASET generates an execution log whether it runs interactively or in the background. By default, ASET generates the log file on standard output. The execution log confirms that ASET ran at the designated time, and also contains any execution error messages. The -n option of the aset command directs the log to be delivered by electronic mail to a designated user. For a complete list of ASET options, refer to aset(1M).

Example of an Execution Log File

ASET running at security level low

Machine=example; Current time = 0325_08:00


aset: Using /usr/aset as working directory

Executing task list...
        firewall
        env
        sysconfig
        usrgrp
        tune
        cklist
        eeprom
All tasks executed. Some background tasks may still be running.

Run /usr/aset/util/taskstat to check their status:
     $/usr/aset/util/taskstat     aset_dir
Where aset_dir is ASET's operating directory, currently=/usr/aset

When the tasks complete, the reports can be found in:
     /usr/aset/reports/latest/*.rpt
You can view them by:
more /usr/aset/reports/latest/*.rpt 

The log first shows the system and time that ASET was run. Then it lists each task as it is started.

ASET invokes a background process for each of these tasks, which are described in "ASET Tasks". The task is listed in the execution log when it starts; this does not indicate that it has been completed. To check the status of the background tasks, use the taskstat utility.

ASET Reports

All report files generated from ASET tasks are in subdirectories under the /usr/aset/reports directory. This section describes the structure of the /usr/aset/reports directory, and provides guidelines on managing the report files.

ASET places the report files in subdirectories that are named to reflect the time and date when the reports are generated. This enables you to keep an orderly trail of records documenting the system status as it varies between ASET executions. You can monitor and compare these reports to determine the soundness of your system's security.

Figure 54-1 shows an example of the reports directory structure.

Figure 54-1 reports Directory Structure

Two report subdirectories are shown in this example:

• 0124_01:00

• 0125_01:00

The subdirectory names indicate the date and time the reports were generated. Each report subdirectory name has the following format:

monthdate_hour:minute

where month, date, hour, and minute are all two-digit numbers. For example, 0125_01:00 represents January 25, at 1 a.m.

Each of the two report subdirectories contains a collection of reports generated from one execution of ASET.

The directory latest is a symbolic link that always points to the subdirectory that contains the latest reports. Therefore, to look at the latest reports that ASET has generated, you can go to the /usr/aset/reports/latest directory. There is a report file in this directory for each task that ASET performed during its most recent execution.

Format of Report Files

Each report file is named after the task that generates it. See Table 54-1 for a list of tasks and their reports.

Within each report file, messages are bracketed by a beginning and an ending banner line. Sometimes a task terminates prematurely; for example, when a component of ASET is accidently removed or damaged. In most cases, the report file will contain a message near the end that indicates the reason for the premature exit.

The following is a sample report file, usrgrp.rpt.

*** Begin User and Group Checking ***
 
Checking /etc/passwd ...
Warning! Password file, line 10, no passwd
:sync::1:1::/:/bin/sync
..end user check; starting group check ...
Checking /etc/group...
*** End User And group Checking ***
 

Examining Report Files

After initially running or reconfiguring ASET, you should examine the report files closely. (Reconfiguration includes modifying the asetenv file or the master files in the masters subdirectory, or changing the security level at which ASET operates.) The reports record any errors introduced when you reconfigured. By watching the reports closely, you can react to, and solve, problems as they arise.

Comparing Report Files

After you monitor the report files for a period during which there are no configuration changes or system updates, you may find that the content of the reports begin to stabilize and that it contains little, if any, unexpected information. You can use the diff utility to compare reports.

ASET Master Files

ASET's master files, tune.high, tune.low, tune.med, and uid_aliases, are located in the /usr/aset/masters directory. ASET uses the master files to define security levels.

Tune Files

The tune.low, tune.med, and tune.high master files define the available ASET security levels. They specify the attributes of system files at each level and are used for comparison and reference purposes.

The uid_aliases File

The uid_aliases file contains a list of multiple user accounts sharing the same ID. Normally, ASET warns about such multiple user accounts because this practice lessens accountability. You can allow for exceptions to this rule by listing the exceptions in the uid_aliases file. ASET does not report entries in the passwd file with duplicate user IDs if these entries are specified in the uid_aliases file.

Avoid having multiple user accounts (password entries) share the same user ID. You should consider other methods of achieving your objective. For example, if you intend for several users to share a set of permissions, you could create a group account. Sharing user IDs should be your last resort, used only when absolutely necessary and when other methods will not accomplish your objectives.

You can use the UID_ALIASES environment variable to specify an alternate aliases file. The default is /usr/aset/masters/uid_aliases.

The Checklist Files

The master files used by the systems files checklist are generated when you first execute ASET, or when you run ASET after you change the security level.

The files checked by this task are defined by the following environment variables:

• CKLISTPATH_LOW

• CKLISTPATH_MED

• CKLISTPATH_HIGH

ASET Environment File (asetenv)

The environment file, asetenv, contains a list of variables that affect ASET tasks. These variables can be changed to modify ASET operation.

Configuring ASET

This section discusses how ASET is configured and the environment under which it operates.

ASET requires minimum administration and configuration, and in most cases, you can run it with the default values. You can, however, fine-tune some of the parameters that affect the operation and behavior of ASET to maximize its benefit. Before changing the default values, you should understand how ASET works, and how it affects the components of your system.

ASET relies on four configuration files to control behavior of its tasks:

• /usr/aset/asetenv

• /usr/aset/masters/tune.low

• /usr/aset/masters/tune.med

• /usr/aset/masters/tune.high

Modifying the Environment File (asetenv)

The /usr/aset/asetenv file has two main sections:

• A user-configurable parameters section

• An internal environment variables section

You can alter the user-configurable parameters section. However, the settings in the internal environment variables section are for internal use only and should not be modified.

You can edit the entries in the user-configurable parameters section to:

• Choose which tasks to run

• Specify directories for checklist task

• Schedule ASET execution

• Specify an aliases file

• Extend checks to NIS+ tables

Choose Which Tasks to Run: TASKS

Each of the tasks ASET performs monitors a particular area of system security. In most system environments, all the tasks are necessary to provide balanced security coverage. However, you may decide to eliminate one or more of the tasks.

For example, the firewall task runs at all security levels, but takes action only at the high security level. You may want to run ASET at the high-security level, but do not require firewall protection.

It's possible to set up ASET to run at the high level without the firewall feature by editing the TASKS list of environment variables in the asetenv file. By default, the TASKS list contains all of the ASET tasks. (An example is shown below). To delete a task, remove the task setting from the file. In this case, you would delete the firewall environment variable from the list. The next time ASET runs, the excluded task will not be performed.

TASKS="env sysconfig usrgrp tune cklist eeprom firewall"
 

Specify Directories for Checklist Task: CKLISTPATH

The system files check checks attributes of files in selected system directories. You define which directories to check by using these checklist path environment variables:

• CKLISTPATH_LOW

• CKLISTPATH_MED

• CKLISTPATH_HIGH

The CKLISTPATH_LOW variable defines the directories to be checked at the low security level. CKLISTPATH_MED and CKLISTPATH_HIGH environment variables function similarly for the medium and high security levels.

The directory list defined by a variable at a lower security level should be a subset of the directory list defined at the next higher level. For example, all directories specified for CKLISTPATH_LOW should be included in CKLISTPATH_MED, and all the directories specified for CKLISTPATH_MED should be included in CKLISTPATH_HIGH.

Checks performed on these directories are not recursive; ASET only checks those directories explicitly listed in the variable. It does not check their subdirectories.

You can edit these variable definitions to add or delete directories that you want ASET to check. Note that these checklists are useful only for system files that do not normally change from day to day. A user's home directory, for example, is generally too dynamic to be a candidate for a checklist.

Schedule ASET Execution: PERIODIC_SCHEDULE

When you start ASET, you can start it interactively, or use the -p option to request that the ASET tasks run at a scheduled time and period. You can run ASET periodically, at a time when system demand is light. For example, ASET consults PERIODIC_SCHEDULE to determine how frequently to execute the ASET tasks, and at what time to run them. For detailed instructions about setting up ASET to run periodically, see "How to Run ASET Periodically".

The format of PERIODIC_SCHEDULE follows the format of crontab entries. See crontab(1) for complete information.

Specify an Aliases File: UID_ALIASES

The UID_ALIASES variable specifies an aliases file that lists shared user IDs. The default is /usr/aset/masters/uid_aliases.

Extend Checks to NIS+ Tables: YPCHECK

The YPCHECK environment variable specifies whether ASET should also check system configuration file tables. YPCHECK is a Boolean variable; you can specify only true or false for it. The default value is false, disabling NIS+ table checking.

To understand how this variable works, consider its effect on the passwd file. When this variable is set to false, ASET checks the local passwd file. When it is set to true, the task also checks the NIS+ passwd file for the domain of the system.

Although ASET automatically repairs the local tables, it only reports potential problems in the NIS+ tables; it does not change them.

Modifying the Tune Files

ASET uses the three master tune files, tune.low, tune.med, and tune.high, are used by ASET to ease or tighten access to critical system files. These master files are located in the /usr/aset/masters directory, and they can be modified to suit your environment. For additional information, see "Tune Files".

The tune.low file sets permissions to values appropriate for default system settings. The tune.med file further restricts these permissions and includes entries not present in tune.low. The tune.high file restricts permissions even further.

Modify settings in the tune file by adding or deleting file entries. Setting a permission to a less restrictive value than the current setting has no effect; the ASET tasks do not relax permissions unless you downgrade your system security to a lower level.

Restoring System Files Modified by ASET

When ASET is executed for the first time, it saves and archives the original system files. The aset.restore utility reinstates these files. It also deschedules ASET, if it is currently scheduled for periodic execution. The aset.restore utility is located in /usr/aset, the ASET operating directory.

Changes made to system files are lost when you run aset.restore.

You should use aset.restore:

• When you want to remove ASET changes and restore the original system. If you want to deactivate ASET permanently, you can remove it from cron scheduling if the aset command had been added to root's crontab previously. For directions on how to use cron to remove automatic execution, see "How to Stop Running ASET Periodically".

• After a brief period of experimenting with ASET, to restore the original system state.

• When some major system functionality is not working properly and you suspect that ASET is causing the problem.

Network Operation Using the NFS System

Generally, ASET is used in standalone mode, even on a system that is part of a network. As system administrator for your standalone system, you are responsible for the security of your system and for running and managing ASET to protect your system.

You can also use ASET in the NFS distributed environment. As a network administrator, you are responsible for installing, running, and managing various administrative tasks for all of your clients. To facilitate ASET management across several client systems, you can make configuration changes that are applied globally to all clients, eliminating the need for you to log in to each system to repeat the process.

When deciding how to set up ASET on your networked systems, you should consider how much you want users to control security on their own systems, and how much you want to centralize responsibility for security control.

Providing a Global Configuration for Each Security Level

A case might arise where you want to set up more than one network configuration. For example, you may want to set up one configuration for clients that are designated with low security level, another configuration for those with medium level, and yet another one with high level.

If you need to create a separate ASET network configuration for each security level, you can create three ASET configurations on the server--one for each level. You would export each configuration to the clients with the appropriate security level. Some ASET components that are common to all three configurations could be shared using links.

Collecting ASET Reports

Not only can you centralize the ASET components on a server to be accessed by clients with or without superuser privilege, but you can also set up a central directory on a server to collect all reports produced by tasks running on various clients. For instructions on setting up a collection mechanism, see "How to Collect Reports on a Server".

Setting up the collection of reports on a server allows you to review reports for all clients from one location. You can use this method whether a client has superuser privilege or not. Alternatively, you can leave the reports directory on the local system when you want users to monitor their own ASET reports.

Environment Variables

Table 54-2 lists the ASET environment variables and the values that they specify.

The environment variables listed below are found in the /usr/aset/asetenv file. The ASETDIR and ASETSECLEVEL variables are optional and can be set only through the shell by using the aset command. The other environment variables can be set by editing the file. The variables are described below.

ASETDIR Variable

ASETDIR specifies an ASET working directory.

From the C shell, type:

% setenv ASETDIR pathname 

From the Bourne shell or the Korn shell, type:

$ ASETDIR=pathname
$ export ASETDIR

Set pathname to the full path name of the ASET working directory.

ASETSECLEVEL Variable

The ASETSECLEVEL variable specifies a security level at which ASET tasks are executed.

From the C shell, type:

% setenv ASETSECLEVEL  level

From the Bourne shell or the Korn shell, type:

$ ASETSECLEVEL=level 
export ASETSECLEVEL

In the above commands, level can be set to one of the following:

PERIODIC_SCHEDULE Variable

The value of PERIODIC_SCHEDULE follows the same format as the crontab file. Specify the variable value as a string of five fields enclosed in double quotation marks, each field separated by a space:

"minutes hours day-of-month month day-of-week"

The following rules apply:

• You can specify a list of values, each delimited by a comma, for any field.

• You can specify a value as a number, or you can specify it as a range; that is, a pair of numbers joined by a hyphen. A range states that the ASET tasks should be executed for every time included in the range.

• You can specify an asterisk (*) as the value of any field. An asterisk specifies all possible values of the field, inclusive.

The default entry for PERIODIC_SCHEDULE variable causes ASET to execute at 12:00 midnight every day:

PERIODIC_SCHEDULE="0 0 * * *"    

TASKS Variable

The TASKS variable lists the tasks that ASET performs. The default is to list all seven tasks:

TASKS="env sysconfig usrgrp tune cklist eeprom firewall"

UID_ALIASES Variable

The UID_ALIASES variable specifies an aliases file. If present, ASET consults this file for a list of permitted multiple aliases. The format is UID_ALIASES=pathname. pathname is the full path name of the aliases file.

The default is:

UID_ALIASES=${ASETDIR}/masters/uid_aliases

YPCHECK Variable

The YPCHECK variable extends the task of checking system tables to include NIS or NIS+ tables. It is a Boolean variable, which can be set to either true or false.

The default is false, confining checking to local system tables:

YPCHECK=false

CKLISTPATH_level Variable

The three checklist path variables list the directories to be checked by the checklist task. The following definitions of the variables are set by default; they illustrate the relationship between the variables at different levels:

CKLISTPATH_LOW=${ASETDIR}/tasks:${ASETDIR}/util:${ASETDIR}/masters:
/etc
CKLISTPATH_MED=${CKLISTPATH_LOW}:/usr/bin:/usr/ucb
CKLISTPATH_HIGH=${CKLISTPATH_MED}:/usr/lib:/sbin:/usr/sbin:/usr/ucblib

The values for the checklist path environment variables are similar to those of the shell path variables, in that they are lists of directory names separated by colons ( : ). You use an equal sign ( =) to connect the variable name to its value.

ASET File Examples

This section has examples of some of the ASET files, including the tune files and the aliases file.

Tune Files

ASET maintains three tune files. The entry format in all three tune files are described in Table 54-4.

The following rules apply:

• You can use regular shell wildcard characters, such as an asterisk (*) and a question mark (?), in the path name for multiple references. See the reference page for the shell command sh(1).

• mode represents the least restrictive value. If the current setting is already more restrictive than the specified value, ASET does not loosen the permission settings. For example, if the specified value is 00777, the permission will remain unchanged, because 00777 is always less restrictive than whatever the current setting is.

  This is how ASET handles mode setting, unless the security level is being downgraded or you are removing ASET. When you decrease the security level from what it was for the previous execution, or when you want to restore the system files to the state they were in before ASET was first executed, ASET recognizes what you are doing and decreases the protection level.

• You must use names for owner and group instead of numeric IDs.

• You can use a question mark (?) in place of owner, group, and type to prevent ASET from changing the existing values of these parameters.

• type can be symlink (symbolic link), directory, or file (everything else).

• Higher security level tune files reset file permissions to be at least as restrictive as they are at lower levels. Also, at higher levels, additional files are added to the list.

• A file can match more than one tune file entry. For example, etc/passwd matches etc/pass* and /etc/* entries.

• Where two entries have different permissions, the file permission is set to the most restrictive value. In the following example, the permission of /etc/passwd will be set to 00755, which is the more restrictive of 00755 and 00770.

  /etc/pass* 00755 ? ? file /etc/* 00770 ? ? file

• If two entries have different owner or group designations, the last entry takes precedence.The following example shows the first few lines of the tune.low file.

  / 02755 root root directory /bin 00777 root bin symlink /sbin 02775 root sys directory /usr/sbin 02775 root bin directory /etc 02755 root sys directory /etc/chroot 00777 bin bin symlink

Aliases File

An aliases file contains a list of aliases that share the same user ID.

Each entry is in this form:

uid=alias1=alias2=alias3=...

For example, the following entry lists the user ID 0 being shared by sysadm and root:

0=root=sysadm

Running ASET

This section describes how to run ASET either interactively or periodically.

How to Run ASET Interactively

1. Become superuser.

2. Run ASET interactively by using the aset command.

   # /usr/aset/aset -l level -d pathname

   level	Specifies the level of security. Valid values are low, medium, or high. The default setting is low. See "ASET Security Levels" for detailed information about security levels.
   pathname	Specifies the working directory for ASET. The default is /usr/aset.

3. Verify ASET is running by viewing the ASET execution log that is displayed on the screen.

   The execution log message identifies which tasks are being run.

Example--Running ASET Interactively

The following example runs ASET at low security with the default working directory.

# /usr/aset/aset -l low
======= ASET Execution Log =======
 
ASET running at security level low
 
Machine = jupiter; Current time = 0111_09:26
 
aset: Using /usr/aset as working directory
 
Executing task list ...
	firewall
	env
	sysconf
	usrgrp
	tune
	cklist
	eeprom
 
All tasks executed. Some background tasks may still be running.
 
Run /usr/aset/util/taskstat to check their status:
 /usr/aset/util/taskstat [aset_dir]
 
where aset_dir is ASET's operating
directory,currently=/usr/aset.
 
When the tasks complete, the reports can be found in:
 /usr/aset/reports/latest/*.rpt
 
You can view them by:
 more /usr/aset/reports/latest/*.rpt

How to Run ASET Periodically

1. Become superuser.

2. If necessary, set up the time when you want ASET to run periodically.

   You should have ASET run when system demand is light. The PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file is used to set up the time for ASET to run periodically. By default, the time is set for midnight every 24 hours.

   If you want to set up a different time, edit the PERIODIC_SCHEDULE variable in the /usr/aset/asetenv file. See "PERIODIC_SCHEDULE Variable" for detailed information about setting the PERIODIC_SCHEDULE variable.

3. Add an entry to the crontab file using the aset command.

   # /usr/aset/aset -p

   -p	Inserts a line in the crontab file that starts ASET running at the time determined by the PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file.

4. Display the crontab entry to verify when ASET will run.

   # crontab -l root

How to Stop Running ASET Periodically

1. Become superuser.

2. Edit the crontab file.

   # crontab -e root

3. Delete the ASET entry.

4. Save the changes and exit.

5. Display the crontab entry to verify the ASET entry is deleted.

   # crontab -l root

How to Collect Reports on a Server

1. Become superuser.

2. Set up a directory on the server:

   1. Change to the /usr/aset directory.

      mars# cd /usr/aset

   2. Create a rptdir directory.

      mars# mkdir rptdir

   3. Change to the rptdir directory and create a client_rpt directory.

      mars# cd rptdir mars# mkdir client_rpt

   4. This creates a subdirectory (client_rpt) for a client. Repeat this step for each client whose reports you need to collect.

      The following example creates the directory all_reports, and the subdirectories pluto_rpt and neptune_rpt.

      mars# cd /usr/aset mars# mkdir all_reports mars# cd all_reports mars# mkdir pluto_rpt mars# mkdir neptune_rpt

3. Add the client_rpt directories to the /etc/dfs/dfstab file.

   The directories should have read/write options.

   For example, the following entries in dfstab are shared with read/write permissions.

   share -F nfs -o rw=pluto /usr/aset/all_reports/pluto_rpt share -F nfs -o rw=neptune /usr/aset/all_reports/neptune_rpt

4. Make the resources in the dfstab file available to the clients.

   # shareall

5. On each client, mount the client subdirectory from the server at the mount point, /usr/aset/masters/reports

   # mount server:/usr/aset/client_rpt /usr/aset/masters/reports

6. Edit the /etc/vfstab file to mount the directory automatically at boot time.

   The following sample entry in /etc/vfstab on neptune lists the directory to be mounted from mars, /usr/aset/all_reports/neptune_rpt, and the mount point on neptune, /usr/aset/reports. At boot time, the directories listed in vfstab are automatically mounted.

   mars:/usr/aset/all_reports/neptune.rpt /usr/aset/reports nfs - yes hard

Troubleshooting ASET Problems

This section documents the error messages generated by ASET.

ASET Error Messages

ASET failed: no mail program found.

Usage: aset [-n user[@host]] in /bin/mail or /usr/ucb/mail.
Cannot decide current and previous security levels.

ASET working directory undefined.
To specify, set ASETDIR environment variable or use command line 
option -d.
ASET startup unsuccessful.

ASET working directory $ASETDIR missing.
ASET startup unsuccessful.

Cannot expand $ASETDIR to full pathname.

aset: invalid/undefined security level.
To specify, set ASETSECLEVEL environment variable or use command 
line option -l, with argument= low/med/high.

ASET environment file asetenv not found in $ASETDIR.
ASET startup unsuccessful.

filename doesn't exist or is not readable.

ASET task list TASKLIST undefined.

ASET task list $TASKLIST missing.
ASET startup unsuccessful.

Schedule undefined for periodic invocation.
No tasks executed or scheduled. Check asetenv file.

Warning! Duplicate ASET execution scheduled.
Check crontab file.