Granting Access to a Computer System

The first line of defense is to control access to your system. You can control 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 root login
• Installing a firewall

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 root 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 58, "Securing Files," 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, rather than just mistyped your password.

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

Tracking Root Login

Your system requires a root password to boot into 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 root privileges on your system.

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 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. This section describes how to secure the files and directories in a file system.

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 57-1 lists and describes the file permissions.

Table 57-1

Symbol	Permission	Means Designated Users ...
r	Read	Can open and read the contents of a file.
w	Write	Can write to the file (modify its contents), add to it, or delete it.
x	Execute	Can execute the file (if it is a program or shell script), or run it with one of the exec(1) system calls.
-	Denied	Cannot read, write, or execute the file.

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 57-2 lists and describes the directory permissions.

Table 57-2

Symbol	Permission	Means Designated Users Can ...
r	Read	List files in the directory.
w	Write	Add or remove files or links in the directory.
x	Execute	Open or execute files in the directory. Also can make the directory and to the directories beneath it current.

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

File Types

A file can be one of six types. Table 57-3 lists the possible file types.

Table 57-3

Symbol	Type
-	Text or program
d	Directory
b	Block special file
c	Character special file
p	Named pipe (FIFO)
l	Symbolic link

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 root permission by executing a program that sets the user ID to root. See "How to Set Special Permissions in Absolute Mode" on page 1209 for detailed instructions on setting special permissions.

You should monitor your system to stay aware of any unauthorized use of the setuid and setgid permissions to gain root privileges. See "How to Find Files With setuid Permissions Set" on page 1210 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 root 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.

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.

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.

File Administration Commands

Table 57-4 lists the file administration commands that you can use on files or directories.

Table 57-4

Command	Description
ls(1)	Lists the files in a directory and information about them.
chown(1)	Changes the ownership of a file.
chgrp(1)	Changes the group ownership of a file.
chmod(1)	Changes permissions on a file. You can use either symbolic mode (letters and symbols) or absolute mode (octal numbers) to change permissions on a file.

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.

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 57-5 shows some typical umask settings, and the effect on an executable file.

Table 57-5 umask

Level of Security	umask	Disallows
Permissive (744)	022	w for group and others
Moderate (740)	027	w for group, rwx for others
Moderate (741)	026	w for group, rw for others
Severe (700)	077	rwx for group and others

File Encryption

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

Fortunately, an additional layer of security is available to all SunOS system software users in the United States--the optional file encryption kit. The encryption kit includes the crypt 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.

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 57-6 lists the ACL commands that you can use on files or directories.

Table 57-6

Command	Description
setfacl(1)	Sets, adds, modifies, and deletes ACL entries
getfacl(1)	Displays ACL entries

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 root 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 root only. A would-be root 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.

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" on page 1226 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).

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 57-7 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, and these passwords should be distributed on a need-to-know basis.

Table 57-7

Login Account	GID	Use
root	0	Has almost no restrictions and overrides all other logins, protections, and permissions. The root account has access to the entire system. The password for the root login should be very carefully protected.
daemon	1	Controls background processing.
bin	2	Owns most of the commands.
sys	3	Owns many system files.
adm	4	Owns certain administrative files.
lp	71	Owns the object and spooled data files for the printer.
uucp	5	Owns the object and spooled data files for UUCP, the UNIX- to-UNIX copy program.
nuucp	9	Is used by remote systems to log in to the system and start file transfers.

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

Passwords

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 "Managing User Accounts and Groups" in the System Administration Guide, Volume I 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 User Account Manager or the nispasswd(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 User Account Manager or the yppasswd(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 root can read the /etc/shadow file. You can use User Account Manager or the passwd(1) command to change a user's password on a local system.

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 root 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, for example:

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

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.

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

.

Figure 57-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:*:

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 directory /usr/lib. (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 up 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.

Root Access Restrictions

The root 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 root.

You can protect the root account on a system by restricting root access to a specific device through the /etc/default/login file. For example, if root access is restricted to the console, you can log in to a system as root 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 root. See "How to Restrict Root Login to the Console" on page 1229 for detailed instructions.

---

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

---

Monitoring Who Is Using the su Command

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

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" on page 1229 for detailed instructions.

The sulog file lists all uses of the su command, not only those used to switch user to root. 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 root access from a remote system. This is a good way to immediately detect someone trying to gain root access on the system you are currently working on. See "How to Display Root Access Attempts to the Console" on page 1230 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 57-2 describes the security restrictions you can impose on remote operations.

Figure 57-2

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.

---

Caution - A firewall prevents unauthorized users from accessing hosts on your network. You must maintain strict and rigidly enforced security on the firewall, but since the other hosts on the network are protected, security on those systems 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.

The Automated Security Enhancement Tool (ASET) can be used to make a system into a firewall, and to enforce high security on a firewall system, which is described on page 1177.

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 57-8 lists the types of authentications and authorizations that can help protect your systems on the network against unauthorized use.

Table 57-8

Type	Description	Where to Find Information
NIS+	The NIS+ name service can provide both authentication and authorization at the network level.	NIS+ and FNS Administration Guide
Remote Login Programs	The remote login programs (rlogin, rcp, ftp) enable users to log in to a remote system over the network and use its resources. If you are a "trusted host," authentication is automatic; otherwise, you are asked to authenticate yourself.	System Administration Guide, Volume II
Secure RPC	Secure RPC improves the security of network environments by authenticating users who make requests on remote systems. You can use either the UNIX, DES, or Kerberos authentication system for Secure RPC. Secure RPC can also be used to provide additional security to the NFS(TM) environment, called Secure NFS.	NFS Administration Guide

Table 57-8

Type	Description	Where to Find Information
Solstice AdminSuite(TM)	The Solstice AdminSuite product provides authentication and authorization mechanisms to remotely manage systems with the AdminSuite tools.	Solstice AdminSuite 2.1 User's Guide

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 Root Access

In general, root is not allowed root access to file systems shared across the network. Unless the server specifically grants root privileges, a user who is logged in as root on a client cannot gain root access to files that are remotely mounted on the client. The NFS^(TM) 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 root privileges on a shared file system on a per-host basis, using the root=hostname option to the share command.

Alternative to Secure RPC

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 root 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"

Automated Security Enhancement Tool (ASET)

SunOS 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 directory /usr/aset. 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 typing the following command in a command shell:

$ aset

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.

---

Note - 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 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" on page 1196 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
• An account nobody
• 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" on page 1174. 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 the aset(1M) man page.

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" on page 1179. 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 directory /usr/aset/reports. 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 57-3 shows an example of the reports directory structure.

Figure 57-3 reports

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 57-9 for a list of tasks and their reports.

Table 57-9

Tasks	Report
System files permissions Tuning (tune)	tune.rpt
System files checklist (cklist)	cklist.rpt
User/group checks (usrgrp)	usrgrp.rpt
System configuration files check (sysconf)	sysconf.rpt
Environment check (env)	env.rpt
eeprom check (eeprom)	eeprom.rpt
Firewall setup (firewall)	firewall.rpt

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 begins 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 environment variables: CKLISTPATH_LOW, CKLISTPATH_MED, and 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" on page 1234.

The format of PERIODIC_SCHEDULE follows the format of crontab entries. See the 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.

---

Note - 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" on page 1196.

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.

---

Note - 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 the ASET operating directory, /usr/aset.

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" on page 1235.
• 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 root 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" on page 1235.

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 root 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 57-10 lists the ASET environment variables and the values that they specify.

Table 57-10

Environment Variable	Specifies
ASETDIR (See below)	ASET working directory
ASETSECLEVEL (See below)	Security level
PERIOD_SCHEDULE	Periodic schedule
TASKS	Tasks to run
UID_ALIAS	Aliases file
YPCHECK	Extends check to NIS and NIS+
CKLISTPATH_LOW	Directory lists for low security
CKLISTPATH_MED	Directory list for medium security
CKLISTPATH_HIGH	Directory list for high security

The environment variables listed below are found in the file /usr/aset/asetenv. The ASETDIR and ASETSECLEVEL variables are optional and can be set only through the shell 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

ASETSECLEVEL 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:

• low low security level
• med medium security level
• high high security level

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"

• minutes hours Specifies start time in number of minutes after the hour (0-59) and the hour (0-23)
• day-of-month Specifies the day of the month when ASET should be run, using values from 1 through 31
• month....Specifies the month of the year when ASET should be run, using values from 1 through 12
• day-of-week..Specifies the day of the week when ASET should be run, using values from 0 through 6; Sunday is day 0 in this scheme

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. Entries in all three tune files have the following format:

pathname	The full path name of the file
mode	A five-digit number that represents the permission setting
owner	The owner of the file
group	The group of the file
type	The type of the file

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 staff directory /bin 00777 root staff symlink /etc 02755 root staff directory /etc/chroot 00777 root staff symlink /etc/clri 00777 root staff 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=...

Where:

uid is the shared user ID.

aliasn is the user account sharing the user ID.

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

0=root=sysadm