Part II Managing System Security

Chapter 2 Managing Machine Security (Overview)

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

The following is a list of the overview information in this chapter.

• Controlling Access to a Computer System

• Controlling Access to Machine Resources

• Controlling Access to Files

• Controlling Network Access

Controlling Access to a Computer System

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

At the file level, the Solaris operating environment provides some standard security features that you can use to protect files, directories, and devices. At the system and network levels, the security issues are mostly the same. The first line of security defense is to control access to your system. You can control and monitor system access by doing the following:

• Maintaining physical security

• Maintaining login control

• Monitoring and limiting resource use

• Protecting files

• Controlling network access

• Reporting security problems

Maintaining Physical Security

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

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

Maintaining Login Control

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

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

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

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

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

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

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

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

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

Managing Password Information

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

Passwords are initially created when you set up a user account. To maintain security on user accounts, you can set up password aging to force users to routinely change their passwords. You can also disable a user account by locking the password. For detailed information about administering passwords, see “Managing User Accounts and Groups (Overview)” in System Administration Guide: Basic Administration and the passwd(1) man page.

Local Passwords

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

NIS and NIS+ Passwords

If your network uses NIS+, the password information is kept in the NIS+ database. Information in the NIS+ database can be protected by restricting access to authorized users. You can use the passwd command to change a user's password that is stored in a NIS+ database.

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

LDAP Passwords

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

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

Password Encryption

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

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

Algorithms Configuration in the policy.conf File

The following shows the default policy.conf file:

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

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

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

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

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

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

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

Special System Logins

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

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

Remote Logins

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

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

Dial-up Logins

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

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

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

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

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

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

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

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

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

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

Controlling Access to Machine Resources

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

Limiting and Monitoring Superuser

Your system requires a root password for superuser mode. In the default configuration, a user cannot remotely log in to a system as root. When logging in remotely, a user must log in with the user's username and then use the su command to become root. For security reasons, you can monitor who has been using the su command, especially those users who are trying to gain superuser access. For procedures that monitor superuser and limit access to superuser, see Monitoring and Restricting Superuser.

Configuring Role-Based Access Control to Replace root

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

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

Preventing Unintentional Misuse of Machine Resources

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

Setting the Path Variable

You should take care to set the path variable correctly. Otherwise, you can accidentally run a program that was introduced by someone else. The intruding program can corrupt your data or harm your system. This kind of program, which creates a security hazard, is referred to as a “Trojan horse.” For example, a substitute su program could be placed in a public directory where you, as system administrator, might run the substitute program. Such a script would look just like the regular su command. Since the script removes itself after execution, you would have little evidence to show that you have actually run a Trojan horse.

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

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

Assigning a Restricted Shell

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

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

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

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

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

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

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

Restricting Access to Data in Files

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

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

Restricting setuid Executable Files

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

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

Using the Automated Security Enhancement Tool (ASET)

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

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

Using the Resource Manager

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

Monitoring Use of Machine Resources

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

• What is the normal load?

• Who has access to the system?

• When do individuals access the system?

• What programs normally run on the system?

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

Controlling Access to Files

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

Commands for File System Security

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

File Encryption

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

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

Access Control Lists (ACLs)

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

• Owner file permissions

• Owner's group file permissions

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

• File permissions for specific users

• File permissions for specific groups

• Default permissions for each of the previous categories

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

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

Sharing Files Across Machines

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

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

Restricting root Access to Shared Files

In general, superuser is not allowed root access to file systems that are shared across the network. The NFS system prevents root access to mounted file systems by changing the user of the requester to the user nobody with user ID 60001. The access rights of user nobody are the same as those access rights that are given to the public. The user nobody has the access rights of a user without credentials. For example, if the public has only execute permission for a file, then user nobody can only execute that file.

An NFS server can grant superuser privileges on a shared file system on a per-host basis. To grant these privileges, use the root=hostname option to the share command. You should use this option with care.

Controlling Network Access

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

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

Network Security Mechanisms

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

Figure 2–1 Security Restrictions for Remote Operations

Authentication and Authorization for Remote Access

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

Using Privileged Ports Between Solaris Systems

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

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

“Weak Authentication
NFS request from unprivileged port”

Firewall Systems

You can set up a firewall system to protect the resources in your network from outside access. A firewall system is a secure host that acts as a barrier between your internal network and outside networks. Each network approaches the other as untrusted. You should consider this setup as mandatory between your internal network and any external networks, such as the Internet, with which you want to communicate.

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

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

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

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

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

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

Packet Smashing

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

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

Reporting Security Problems

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

Chapter 3 Securing Machines (Tasks)

This chapter describes the procedures for securing machines in the Solaris environment. The procedures are introduced in the following section:

• Securing Machines (Task Map)

For overview information about machine security, see Chapter 2, Managing Machine Security (Overview).

Securing Machines (Task Map)

A computer is as secure as its weakest point of entry. The following task map shows the areas that you should monitor and secure.

Securing Logins and Passwords

This section describes how to control and monitor logins.

How to Display a User's Login Status

1. Become superuser or assume an equivalent role.

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 the login status for the specified user. username is a user's login name. Multiple login names must be specified in a comma-separated list.

   The logins command uses the appropriate password file to obtain a user's login status. The file can be the local /etc/passwd file , or a password database for the name service. For more information, see the logins(1M) man page.

Example—Displaying a User's Login Status

In the following example, the login status for the user rimmer is displayed.

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

How to Display Users Without Passwords

1. Become superuser or assume an equivalent role.

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

   # logins -p

   The -p option displays a list of users with no passwords. The logins command can use the password databases on the local machine and on the network. The command can use the local /etc/passwd file. The command can use the password databases for the name services to obtain a user's login status.

Example—Displaying Users Without Passwords

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

# logins -p
pmorph          501     other           1       Polly Morph
# 

How to Temporarily Disable User Logins

1. Become superuser or assume an equivalent role.

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

   # vi /etc/nologin

3. Include a message about system availability.

4. Close and save the file.

   Create this file to disallow user logins during system shutdown or routine maintenance. If a user attempts to log in to a system where the nologin file exists, the contents of this file are displayed. Then, the user login is terminated.

   Superuser logins are not affected. For more information, see the nologin(4) man page.

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

You can also bring the system to run level 0, single-user mode. For information on bringing the system to single-user mode, see “Shutting Down a System (Tasks)” in System Administration Guide: Basic Administration.

How to Save Failed Login Attempts

1. Become superuser or assume an equivalent role.

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 that the log works by attempting to log into the system five times with the wrong password. Then, display the /var/adm/loginlog file.

   # more /var/adm/loginlog rimmer:/dev/pts/1:Wed Jan 16 09:22:31 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:39 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:45 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:53 2002 rimmer:/dev/pts/1:Wed Jan 16 09:23:01 2002 #

   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, no failed attempts are logged.

   The loginlog file might grow quickly. To use this file in a timely manner, you should check and clear its contents occasionally. A loginlog file that shows a lot of activity can indicate an attempt to break into the computer system. For more information, see the loginlog(4) man page.

How to Create a Dial-up Password

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

1. Become superuser or assume an equivalent role.

2. Create an /etc/dialups file that contains a list of serial devices. Include all the ports that are being protected with dial-up passwords.

   The /etc/dialups file should look like the following:

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

3. Create an /etc/d_passwd file that contains the login programs that you are requiring to have a 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 the following:

   /usr/lib/uucp/uucico:encrypted-password: /usr/bin/csh:encrypted-password: /usr/bin/ksh:encrypted-password: /usr/bin/sh:encrypted-password:

   You are going to add the encrypted password for each login program later in the procedure.

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 username

   2. Create a password for the temporary user.

      # passwd username

   3. Capture the encrypted password.

      # grep username /etc/shadow > username.temp

   4. Edit the username.temp file.

      Delete all fields except the encrypted password. The second field holds the encrypted password.

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

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

   5. Delete the temporary user.

      # userdel username

8. Copy the encrypted password from username.temp file into the /etc/d_passwd file.

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

9. Inform your dial-up users of the password.

   You should ensure that your means of informing the users cannot be tampered with.

How to Temporarily Disable Dial-up Logins

1. Become superuser or assume an equivalent role.

2. Put the following single-line entry into the /etc/d_passwd file:

   /usr/bin/sh:*:

Changing the Default Algorithm for Password Encryption

By default, user passwords are encrypted with the crypt_unix algorithm. In the Solaris 9 12/02 release, you can use a stronger encryption algorithm, such as MD5 or Blowfish, by changing the default password encryption algorithm. The next time that your users change their password, the algorithm that you specified encrypts the password.

The following procedures do not work if you are running a Solaris environment from an earlier release. This functionality works only on machines that are running the Solaris 9 12/02 release and later releases of the Solaris operating environment.

How to Specify an Algorithm for Password Encryption

In this procedure, the BSD-Linux version of the MD5 algorithm is the default encryption algorithm that is used when users change their passwords. This algorithm is suitable for a mixed network of machines that run the Solaris, BSD, and Linux versions of UNIX. See Table 2–1 for a list of password encryption algorithms and algorithm identifiers.

1. Become superuser or assume an equivalent role.

2. Specify the identifier for the encryption algorithm as the value for the CRYPT_DEFAULT variable in the /etc/security/policy.conf file.

   You might want to comment the file to explain your choice.

   # vi /etc/security/policy.conf … CRYPT_ALGORITHMS_ALLOW=1,2a,md5 # # Use the version of MD5 that works with Linux and BSD systems. # Passwords previously encrypted with __unix__ will be encrypted with MD5 # when users change their passwords. # #CRYPT_DEFAULT=__unix__ CRYPT_DEFAULT=1

   In this example, the algorithms configuration ensures that the weakest algorithm, crypt_unix, is never used to encrypt a password. Users whose passwords were encrypted with the crypt_unix module get a crypt_bsdmd5–encrypted password when they change their passwords.

   For more information on the syntax for configuring the algorithm choices, see the policy.conf(4) man page.

Example—Using the Blowfish Algorithm for Password Encryption

In this example, the identifier for the Blowfish algorithm, 2a, is specified as the value for the CRYPT_DEFAULT variable. The policy.conf entries that control password encryption would look like the following:

CRYPT_ALGORITHMS_ALLOW=1,2a,md5
#CRYPT_ALGORITHMS_DEPRECATE=__unix__
CRYPT_DEFAULT=2a

This configuration is compatible with BSD systems that use the Blowfish algorithm.

How to Specify a New Password Algorithm for an NIS+ Domain

1. Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS+ master.

2. To minimize confusion, copy the NIS+ master's /etc/security/policy.conf file to every host in the NIS+ domain.

When users in a NIS+ domain change their passwords, the NIS+ name service consults the algorithms configuration in the /etc/security/policy.conf file on the NIS+ master. The NIS+ master, which is running the rpc.nispasswd daemon, creates the encrypted password.

How to Specify a New Password Algorithm for an NIS Domain

1. Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS client.

2. Copy the modified /etc/security/policy.conf file to every client machine in the NIS domain.

3. To minimize confusion, copy the modified /etc/security/policy.conf file to the NIS root server and to the slave servers.

When users in an NIS domain change their passwords, the NIS client consults its local algorithms configuration in the /etc/security/policy.conf file. The NIS client machine encrypts the password.

How to Specify a New Password Algorithm for an LDAP Domain

When the LDAP client is properly configured, the LDAP client can use the new password algorithms. The LDAP client behaves just as a NIS client behaves.

1. Specify a password encryption algorithm in the /etc/security/policy.conf file on the LDAP client.

2. Copy the modified policy.conf file to every client machine in the LDAP domain.

3. Ensure that the client's /etc/pam.conf file does not use a pam_ldap module.

   Ensure that a comment sign (#) precedes entries that include pam_ldap.so.1. Also, do not use the new server_policy option with the pam_authtok_store.so.1 module.

The PAM entries in the client's pam.conf file enable the password to be encrypted according to the local algorithms configuration, and enable the password to be authenticated.

When users in the LDAP domain change their passwords, the LDAP client consults its local algorithms configuration in the /etc/security/policy.conf file. The LDAP client machine encrypts the password. The client sends the encrypted password, with a {crypt} tag, to the server. The tag tells the server that the password is already encrypted. The password is then stored, as is, on the server. For authentication, the client retrieves the stored password from the server. The client then compares the stored password with the encrypted version that the client has just generated from the user's typed password.

To take advantage of password policy controls on the LDAP server, use the server_policy option with the pam_authtok_store entries in the pam.conf file. Passwords are then encrypted on the server by using the Sun ONE Directory Server's cryptographic mechanism. For the procedure, see “Setting Up Clients (Task)” in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

How to Install a Password Encryption Module From a Third Party

A third-party password encryption algorithm is typically delivered as part of a software package. When you run the pkgadd command, scripts from the vendor should modify the /etc/security/crypt.conf file. You then modify the /etc/security/policy.conf file to include the new module and its identifier.

1. Add the software by using the pkgadd command.

   For detailed instructions on how to add software, see “Adding or Removing a Software Package” in System Administration Guide: Basic Administration.

2. Read the /etc/security/crypt.conf file to confirm that the new module and module identifier are in the list of encryption algorithms.

   For example, the following lines show a crypt.conf file that was modified by a package that installed the crypt_rot13 algorithm.

   # crypt.conf # md5 /usr/lib/security/$ISA/crypt_md5.so rot13 /usr/lib/security/$ISA/crypt_rot13.so # For *BSD - Linux compatibility # 1 is MD5, 2a is Blowfish 1 /usr/lib/security/$ISA/crypt_bsdmd5.so 2a /usr/lib/security/$ISA/crypt_bsdbf.so

3. Modify the /etc/security/policy.conf file to add the identifier of the newly installed algorithm.

   The following lines show excerpts from the policy.conf file that would need to be modified to add the rot13 identifier.

   # Copyright 1999-2002 Sun Microsystems, Inc. All rights reserved. # ... #ident "@(#)policy.conf 1.6 02/06/07 SMI" # ... # crypt(3c) Algorithms Configuration CRYPT_ALGORITHMS_ALLOW=1,2a,md5,rot13 #CRYPT_ALGORITHMS_DEPRECATE=__unix__ CRYPT_DEFAULT=md5

In this example, the rot13 algorithm is used if the current password was encrypted with the crypt_rot13 algorithm. New user passwords are encrypted with the crypt_sunmd5 algorithm. This algorithms configuration works on Solaris-only networks.

Monitoring and Restricting Superuser

An alternative to using the superuser account is to set up role-based access control. Role-based access control is called RBAC. For overview information on RBAC, see Chapter 5, Role-Based Access Control (Overview). For how to set up RBAC, see Chapter 6, Role-Based Access Control (Tasks).

How to Monitor Who Is Using the su Command

The sulog file lists every use of the su command, not only the su attempts that are used to switch from user to superuser.

1. Become superuser or assume an equivalent role.

2. Monitor the contents of the /var/adm/sulog file on a regular basis.

   # 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-janedoe SU 01/12 14:56 + pts/0 pmorph-root SU 01/12 14:57 + pts/0 pmorph-root

   The entries display the following information:

   • The date and time that the command was entered

   • If the attempt was successful

     A + indicates a successful attempt. A - indicates an unsuccessful attempt.

   • The port from which the command was issued

   • The name of the user and the name of the switched identity

   The su logging in this file is enabled by default through the following entry in the /etc/default/su file:

   SULOG=/var/adm/sulog

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

1. Become superuser or assume an equivalent role.

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

3. Uncomment the following line:

   CONSOLE=/dev/console

4. Use the su command to become root.

   Verify that a message is printed on the system console.

   This method immediately detects someone who is trying to gain superuser access to the system that you are on.

How to Prevent Remote Login by Superuser (root)

Superuser login is restricted to the console by default when you install the Solaris release.

1. Become superuser or assume an equivalent role.

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

3. Uncomment the following line:

   CONSOLE=/dev/console

   When superuser access is restricted to the console, you can log in to a system as superuser only from the console. Any users who try to remotely log in to this system must first log in with their user login. After logging in with their user name, users 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.

Securing the Hardware

You can protect the physical machine by requiring a password to boot the machine. You can also protect the machine by preventing a user from using the abort sequence to leave the windowing system.

How to Require a Password for Hardware Access

1. Become superuser or assume an equivalent role.

2. In a terminal, enter the PROM security mode. Type the following:

   # eeprom security-mode=command Changing PROM password: New password: password Retype new password: password

   Choose the value command or full. See the eeprom(1M) man page for more details.

3. If you are not prompted to enter a PROM password, the system already has a PROM password. To change the PROM password, run the command:

   # eeprom security-password=<Type the Return key> Changing PROM password: New password: password Retype new password: password

   The new PROM security mode and password are in effect immediately, but are most likely to be noticed at the next boot.

   ---

   Caution –

   Do not forget the PROM password. The hardware is unusable without this password.

   ---

How to Disable or Enable a System's Abort Sequence

Use the following procedure to disable a machine's abort sequence. The default system behavior is that a system's abort sequence is enabled.

Some server systems have a key switch. When the switch is set in the secure position, the switch overrides the software keyboard abort settings. So, any changes that you make with the following procedure might not be implemented.

1. Become superuser or assume an equivalent role.

2. Change the value of KEYBOARD_ABORT to disable.

   Comment out the enable line in the /etc/default/kbd file. Then add a disable line:

   # vi /etc/default/kbd … # KEYBOARD_ABORT affects the default behavior of the keyboard abort # sequence, see kbd(1) for details. The default value is "enable". # The optional value is "disable". Any other value is ignored. … #KEYBOARD_ABORT=enable KEYBOARD_ABORT=disable

3. Update the keyboard defaults.

   # kbd -i

Chapter 4 Securing Files (Tasks)

This chapter describes the procedures for securing files in the Solaris environment.

The following 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 Special Permissions in Absolute Mode

• How to Change Permissions in Symbolic Mode

• How to Find Files With setuid Permissions

• How to Disable Programs From Using Executable Stacks

• How to Disable Executable Stack Message Logging

• How to Set an ACL on a File

• How to Copy an ACL

• How to Check If a File Has an ACL

• How to Modify ACL Entries on a File

• How to Delete ACL Entries From a File

• How to Display ACL Entries for a File

File Security Features

This section describes the features that constitute a file's security.

User Classes

For each file, there are three classes of users that specify the levels of security:

• user – The file or directory owner, which is 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.

• group – Members of a group.

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

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

File Permissions

The following table lists and describes the permissions that you can give to each user class for a 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 the permissions of the file that the link points to.

Directory Permissions

The following table lists and describes the permissions that you can give to each user class for a directory.

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

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 user ID of the owner (or group) of the executable file.

You must be extremely careful when you set special permissions, because special permissions constitute a security risk. For example, a user can gain superuser privileges by executing a program that sets the user ID (UID) to root. Also, all users can set special permissions for files they own, which constitutes another security concern.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. To search for and list all of the files that use these permissions, see How to Find Files With setuid Permissions. A suspicious listing grants ownership of such a program to a user rather than to root or bin.

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 is running the executable file. This special permission 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   3 root     sys       104580 Sep 16 12:02 /usr/bin/passwd

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

The use of setuid permissions with the reserved UIDs (0–100) from a program might 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 command has setgid permissions:

-r-x--s--x   1 root     mail       63628 Sep 16 12:01 /usr/bin/mail

When setgid permission is applied to a directory, files that were created in this directory belong to the group to which the directory belongs, not the group to which the creating process belongs. Any user who has write and execute permissions in the directory can create a file there. However, the file belongs to the group that owns the directory, not to the user's group ownership.

You should monitor your system for any unauthorized use of the setuid and setgid permissions to gain superuser privileges. To search for and list all of the files that use these permissions, see How to Find Files With setuid Permissions. A suspicious listing grants group ownership of such a program to a user rather than to root or bin.

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 special permission prevents a user from deleting other users' files from public directories such as /tmp:

drwxrwxrwt 7  root  sys   400 Sep  3 13:37 tmp

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

Default umask Setting

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

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

The following table shows some typical umask settings, and the effect on an executable file.

For more information on setting the umask value, see the umask(1) man page.

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.

1. Type the following command to get a long listing of all files in the current directory.

   % ls -la

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

• Type of file

  A file can be one of seven types. The following table lists the possible file types.

  Table 4–4 File Types

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

• Permissions; see Setting the Path Variable and Table 4–2 for descriptions

• 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 that the file 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 13456
drwxr-xr-x   2 root     sys          512 Sep  1 14:11 .
drwxr-xr-x  29 root     root        1024 Sep  1 15:40 ..
-r-xr-xr-x   1 root     bin       218188 Aug 18 15:17 autopush
lrwxrwxrwx   1 root     root          21 Sep  1 14:11 bpgetfile -> ...
-r-xr-xr-x   1 root     bin       505556 Aug 20 13:24 dhcpagent
-r-xr-xr-x   1 root     bin       456064 Aug 20 13:25 dhcpinfo
-r-xr-xr-x   1 root     bin       272360 Aug 18 15:19 fdisk
-r-xr-xr-x   1 root     bin       824728 Aug 20 13:29 hostconfig
-r-xr-xr-x   1 root     bin       603528 Aug 20 13:21 ifconfig
-r-xr-xr-x   1 root     sys       556008 Aug 20 13:21 init
-r-xr-xr-x   2 root     root      274020 Aug 18 15:28 jsh
-r-xr-xr-x   1 root     bin       238736 Aug 21 19:46 mount
-r-xr-xr-x   1 root     sys         7696 Aug 18 15:20 mountall
   .
   .
   .

Changing File Ownership

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

By default, the owner cannot use the chown command to change the owner of a file or directory. However, you can enable the owner to use the chown command by adding the following line to the system's /etc/system file and rebooting the system.

set rstchown = 0

For more information, see chown(1).

In addition, the owner can only use the chgrp command to change the group of a file to a group in which the owner belongs by default. For example, if the owner of a file only belongs to the staff and sysadm groups, the owner can only change the group of a file to staff or sysadm group.

However, you can enable the owner to change the group of a file to a group in which the owner doesn't belong by adding the following line to the system's /etc/system file and rebooting the system.

set rstchown = 0

For more information, see chgrp(1).

Also, be aware that there can be other restrictions on changing ownership and groups on NFS-mounted file systems.

How to Change the Owner of a File

Use the following procedure to change the ownership of a file.

1. Become superuser or assume an equivalent role.

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

   # chown new-owner filename

   new-owner	Specifies the user name or UID of the new owner of the file or directory.
   filename	Specifies the file or directory.

3. Verify that the owner of the file has changed.

   # ls -l filename

Example—Changing the Owner of a File

In the following example, the ownership on myfile is changed 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

Use the following procedure to change the group ownership of a file.

1. Become superuser or assume an equivalent role.

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

   $ chgrp group filename

   group	Specifies the group name or GID of the new group of the file or directory.
   filename	Specifies the file or directory.

   For information on setting up groups, see “Managing User Accounts and Groups (Overview)” in System Administration Guide: Basic Administration.

3. Verify that the group owner of the file has changed.

   $ ls -l filename

Example—Changing Group Ownership of a File

In the following example, the group ownership on myfile is changed 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, you represent permissions for each triplet by an octal mode number.

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

The following table lists the octal values for setting file permissions in absolute mode. You use these numbers in sets of three to set permissions for owner, group, and other (in that order). For example, the value 644 sets read and write permissions for owner, and read-only permissions for group and other.

You can set special permissions on a file in absolute or symbolic modes. However, you cannot set or remove setuid permissions on a directory by using absolute mode. You must use symbolic mode. In absolute mode, you set special permissions by adding a new octal value to the left of the permission triplet. The following table lists the octal values to set special permissions on a file.

The following table 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, and the permissions that are 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

Use the following procedure to change permissions in absolute mode.

1. If you are not the owner of the file or directory, become superuser or assume an equivalent role.

   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 represent the permissions for the file owner, file group, and others, in that order. See Table 4–5 for the list of valid octal values.
   filename	Specifies the file or directory.

   ---

   Note –

   If you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for additional users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.

   ---

3. Verify that the permissions of the file have changed.

   % ls -l filename

Example—Changing Permissions in Absolute Mode

In the following example, the permissions of a public directory are changed from 744 (read, write, execute; read-only; and read-only) to 755 (read, write, execute; read and execute; and read and execute).

# ls -ld public_dir
drwxr--r--  1 ignatz   staff    6023 Aug  5 12:06 public_dir
# chmod 755 public_dir
# ls -ld public_dir
drwxr-xr-x  1 ignatz   staff    6023 Aug  5 12:06 public_dir

In the following example, the permissions of an executable shell script are changed from read and write to read, write, and execute.

% ls -l my_script
-rw------- 1 ignatz   staff    6023 Aug  5 12:06 my_script
% chmod 700 my_script
% ls -l my_script
-rwx------ 1 ignatz   staff    6023 Aug  5 12:06 my_script

How to Change Special Permissions in Absolute Mode

Use the following procedure to change special permissions in absolute mode.

1. If you are not the owner of the file or directory, become superuser or assume an equivalent role.

   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. For the list of valid octal values for the special permissions, see Table 4–6.
   filename	Specifies the file or directory.

   ---

   Note –

   If you use the chmod command to change the file group permissions on a file with ACL entries, both the file group permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the permissions for additional users and groups who have ACL entries on the file. Use the getfacl command to make sure that the appropriate permissions are set for all ACL entries. For more information, see the getfacl(1) man page.

   ---

3. Verify that the permissions of the file have changed.

   % ls -l filename

Examples—Setting Special Permissions in Absolute Mode

In the following example, the setuid permission is set on the dbprog file.

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

In the following example, the setgid permission is set on the dbprog2 file.

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

In the following example, the sticky bit permission is set on the public_dir directory.

# chmod 1777 public_dir
# ls -ld public_dir
drwxrwxrwt   2 ignatz   staff          512 May 15 15:27 public_dir

How to Change Permissions in Symbolic Mode

Use the following procedure 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 to be changed, operator specifies the operation to be performed, and permission specifies what permissions are to be changed. For the list of valid symbols, see Table 4–7.
   filename	Specifies the file or directory.

3. Verify that the permissions of the file have changed.

   % ls -l filename

Examples—Changing Permissions in Symbolic Mode

In the following example, read permission are taken away from others.

% chmod o-r filea

In the following example, read and execute permissions are added for user, group, and others.

$ chmod a+rx fileb

In the following example, read, write, and execute permissions are assigned to group.

$ chmod g=rwx filec

Searching for Special Permissions

You should monitor your system for any unauthorized use of the setuid and setgid permissions on programs to gain superuser privileges. A suspicious listing grants ownership of such a program to a user rather than to root or bin.

How to Find Files With setuid Permissions

Use the following procedure to find files with setuid permissions.

1. Become superuser or assume an equivalent role.

2. Find files with setuid permissions 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 owned only 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.

   # more /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

This output shows that a user named rar has made a personal copy of /usr/bin/sh, and has set the permissions as setuid to root. As a result, 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.

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 are allowed, most programs can function correctly without using executable stacks.

The noexec_user_stack variable enables you to specify whether stack mappings are executable. The variable is available as of the Solaris 2.6 release. By default, the variable is set to zero, except on 64-bit applications, which provides ABI-compliant behavior. If the variable is set to non-zero, the system marks 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 are 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 the 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 syslog daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf file, which means that the message is sent to both the console and the /var/adm/messages file. For more information, see the syslogd(1M) and syslog.conf(4) man pages.

The syslog message is useful for observing potential security problems. The message also identifies valid programs that depend upon executable stacks that 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 in the /etc/system file. Even though messages are not being logged, the SIGSEGV signal can continue to cause the executing program to core dump.

You can use the mprotect() function if you want programs to explicitly mark their stack as executable. For more information, see the mprotect(2) man page.

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

How to Disable Programs From Using Executable Stacks

1. Become superuser or assume an equivalent role.

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 or assume an equivalent role.

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

   set noexec_user_stack_log=0

3. Reboot the system.

   # init 6

Using Access Control Lists (ACLs)

Traditional UNIX file protection provides read, write, and execute permissions for the three user classes: file owner, file group, and other. An ACL provides better file security by enabling you to define file permissions for the file owner, file group, other, specific users and groups, and default permissions for each of those categories.

For example, if you wanted everyone in a group to be able to read a file, you would simply 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 provide that level of file security. However, this dilemma is perfect for ACLs.

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

entry-type:[uid|gid]:perms

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

user:nathan:rw-

UFS file system attributes such as ACLs are supported in UFS file systems only. Thus, 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

The following table lists the valid ACL entries that you might use when setting file ACLs. The first three ACL entries provide the basic UNIX file protection.

ACL Entries for Directories

In addition to the ACL entries that are described in Table 4–8, you can set default ACL entries on a directory. Files or directories created in a directory that has default ACL entries will have the same ACL entries as the default ACL entries. Table 4–9 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 file owner, file group, others, and the ACL mask. These entries are required and are the first four default ACL entries in the following table.

How to Set an ACL on a File

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

   % setfacl -s user::perms,group::perms,other:perms,mask:perms,acl-entry-list filename ...

   -s	Sets an ACL on the file. If a file already has an ACL, it is replaced. This option requires at least the file owner, file group, and other entries.
   user::perms	Specifies the file owner permissions.
   group::perms	Specifies the file group permissions.
   other:perms	Specifies the permissions for users other than the file owner or members of the file group.
   mask:perms	Specifies the permissions for the ACL mask. The mask indicates the maximum permissions that are allowed for users (other than the owner) and for groups.
   acl-entry-list	Specifies 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 4–8 and Table 4–9 show the valid ACL entries.
   filename ...	Specifies one or more files or directories on which to set the ACL, separated by a space.

   ---

   Caution –

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

   ---

   For more information, see the setfacl(1) man page.

2. Verify that an ACL was set on the file or verify which ACL entries were set on the file.

   % getfacl filename

   For more information, see How to Check If a File Has an ACL.

Examples—Setting an ACL on a File

In the following example, the file owner permissions are set to read and write, file group permissions are set to read only, and other permissions are set to none on the ch1.doc file. In addition, the user george is given read and write permissions on the file, and the ACL mask permissions are set to read and write, which means that 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:---

In the following example, the file owner permissions are set to read, write, and execute, file group permissions are set to read only, other permissions are set to none, and the ACL mask permissions are set to read on the ch2.doc file. In addition, the user george is given read and write permissions. However, due to the ACL mask, the permissions for george are read only.

% setfacl -s u::7,g::4,o:0,m:4,u:george:7 ch2.doc
% getfacl ch2.doc
# file: ch2.doc
# owner: nathan
# group: sysadmin
user::rwx
user:george:rwx         #effective:r--
group::r--              #effective:r--
mask:r--
other:---

How to Copy an ACL

Copy a file's ACL to another file by redirecting the getfacl output.

% getfacl filename1 | setfacl -f -filename2

Example—Copying an ACL

In the following example, the ACL on ch2.doc is copied to ch3.doc.

% getfacl ch2.doc | setfacl -f - ch3.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

filename specifies the file or directory.

In the output, a plus sign (+) to the right of the mode field indicates that the file has an ACL.

Unless you have added ACL entries for additional users or groups on a file, a file is considered to be a “trivial” ACL and the plus sign (+) will not display.

Example—Checking If a File Has an ACL

The following example shows that the ch1.doc file has an ACL, because the listing has a plus sign (+) to the right of the mode field.

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

How to Modify ACL Entries on a File

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

   % setfacl -m acl-entry-list filename ...

   -m	Modifies the existing ACL entry.
   acl-entry-list	Specifies the list of one or more ACL entries to modify on the file or directory. You can also modify default ACL entries on a directory. Table 4–8 and Table 4–9 show the valid ACL entries.
   filename ...	Specifies one or more files or directories, separated by a space.

2. Verify that the ACL entries were modified on the file by using the getfacl command.

   % getfacl filename

Examples—Modifying ACL Entries on a File

In the following example, the permissions for the user george are modified to read and write.

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

In the following example, the default permissions for the group staff are modified to read and the default ACL mask permissions are modified to read and write on the book directory.

% setfacl -m default:group:staff:4,default:mask:6 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 filename ...

   -d	Deletes the specified ACL entries.
   acl-entry-list	Specifies the 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 4–8 and Table 4–9 show the valid ACL entries.
   filename ...	Specifies one or more files or directories, separated by a space.

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

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

   % getfacl filename

Example—Deleting ACL Entries on a File

In the following example, the user george is deleted from the ch4.doc file.

% setfacl -d user:george ch4.doc

How to Display ACL Entries for a File

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

% getfacl [-a | -d] filename ...

If you specify multiple file names on the command line, the ACL entries are displayed with a blank line between each entry.

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:r--         #effective:r--
group::rw-              #effective:rw-
mask:rw-
other:---

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

% getfacl -d book

# file: book
# owner: nathan
# group: sysadmin
user::rwx
user:george:r-x         #effective:r-x
group::rwx              #effective:rwx
mask:rwx
other:---
default:user::rw-
default:user:george:r--
default:group::rw-
default:mask:rw-
default:other:---

Chapter 5 Role-Based Access Control (Overview)

This chapter describes role-based access control (RBAC), a security feature for controlling access to tasks that would normally be restricted to superuser. The following is a list of the overview information in this chapter.

• RBAC: Replacing the Superuser Model

• Solaris RBAC Elements

• Privileged Applications

• RBAC Roles

• RBAC Authorizations

• RBAC Rights Profiles

• Name Service Scope

For information on RBAC tasks, see Chapter 6, Role-Based Access Control (Tasks). For reference information on the RBAC elements and tools, see Chapter 7, Role-Based Access Control (Reference).

RBAC: Replacing the Superuser Model

In conventional UNIX systems, the root user (also referred to as superuser) is all-powerful, with the ability to read and write to any file, run all programs, and send kill signals to any process. Effectively, anyone who can become superuser can modify a site's firewall, alter the audit trail, read payroll and other confidential records, and shut down the entire network.

Role-based access control (RBAC) is an alternative to the all-or-nothing superuser model. RBAC uses the security principle of least privilege, which is that no user should be given more privilege than necessary for performing his or her job. RBAC allows an organization to separate superuser's capabilities and assign them to special user accounts that are called roles. Roles can be assigned to specific individuals, according to their job needs.

The flexibility in setting up roles enables a variety of security policies. Three recommended roles that can be easily configured are available:

• Primary Administrator – A powerful role that is equivalent to root.

• System Administrator – A less strong role for administration that is not related to security. This role does not allow the user to set passwords.

• Operator – A junior administrator role for operations such as backups and restores, and printer management.

There is no requirement that these specific roles be implemented. Roles are a function of an organization's security needs. Roles can be set up for special-purpose administrators in areas such as security, networking, or firewall administration. Another strategy is to create a single strong administrator role along with an advanced user role for those users who are permitted to fix portions of their own systems.

Solaris RBAC Elements

In the RBAC model in the Solaris operating environment, users log in as themselves and assume roles that enable them to run restricted administration graphical tools and commands. The RBAC model introduces these elements to the Solaris operating environment:

• Privileged Application – An application that can override system controls and check for specific user IDs (UIDs), group IDs (GIDs), or authorizations (see Privileged Applications).

• Role – A special identity for running privileged applications that can be assumed by assigned users only.

• Authorization – A permission that can be assigned to a role or user (or embedded in a rights profile) for performing a class of actions that are otherwise prohibited by security policy.

• Rights Profile – A collection of overrides that can be assigned to a role or user. A rights profile can consist of authorizations, commands with setuid or setgid permissions (referred to as security attributes), and other rights profiles.

The following figure shows how the RBAC elements work together.

Figure 5–1 Solaris RBAC Element Relationships

In RBAC, users are assigned to roles. Roles get their capabilities from rights profiles and authorizations. Authorizations are generally assigned to the rights profiles with which they are logically associated but can be assigned directly to roles.

Rights profiles and authorizations can also be assigned directly to users. This practice is discouraged because it enables users to make mistakes through inadvertent use of their privileges.

Commands with security attributes, that is, real or effective UIDs or GIDs, can be assigned to rights profiles.

The following figure uses the Operator role and the Printer Management rights profiles as examples to demonstrate RBAC relationships.

Figure 5–2 How Solaris RBAC Elements Relate

The Operator role is used to maintain printers and perform media backup. The user johnDoe is assigned to the Operator role and can assume it by supplying the Operator password.

The Operator rights profile has been assigned to the Operator role. The Operator rights profile has two supplementary profiles assigned to it, Printer Management and Media Backup, which reflect the Operator role's primary tasks.

The Printer Management rights profile is for managing printers, print daemons, and spoolers. Three authorizations are assigned to the Printer Management rights profile: solaris.admin.printer.read, solaris.admin.printer.delete, and solaris.admin.printer.modify. These authorizations allows users to manipulate information in the printer queue. The Printer Management profile also has a number of commands with security attributes that are assigned to it, such as /usr/sbin/accept with euid=0 and /usr/ucb/lpq with euid=lp.

Privileged Applications

Applications that can override system controls are considered privileged applications.

Applications That Check UIDs and GIDs

Privileged applications that check for root or some other special UID or GID have long existed in UNIX. The RBAC rights profile mechanism enables you to specify the UID or GID for specific commands. Instead of changing the ID on a command that anyone can access, you can isolate the command with execution security attributes in the rights profile. A user or role with that rights profile can then run the program without having to become root.

IDs can be specified as real or effective. Assigning effective IDs is preferred over assigning real IDs. Effective IDs are equivalent to the setuid feature in the file permission bits and identify the UID for auditing. However, because some shell scripts and programs require a real UID of root, real IDs can be set as well. For example, the pkgadd command requires a real rather than an effective UID. If you encounter a command where the effective UID is not sufficient to run the command, you need to change the privilege to a real UID by using the Set Security Attributes option in the SMC Right Properties dialog boxes as described in Creating or Changing a Rights Profile.

Applications That Check Authorizations

RBAC additionally provides commands that check authorizations. By definition, root has all authorizations and thus can run any application. Currently, the applications that check for authorizations include the following:

• The entire Solaris Management Console suite of tools

• The batch job-related commands – at, atq, batch, and crontab

• Device-oriented commands – allocate, deallocate, list_devices, and cdrw.

Profile Shell

Authorized users can obtain privileged applications from the Solaris Management Console launcher or on the command line from a profile shell. A profile shell is a special kind of shell that enables access to the privileged applications that are assigned to the profile. Profile shells are launched when the user runs su to assume a role. The profile shells are pfsh, pfcsh, and pfksh. They correspond to Bourne shell (sh), C shell (csh), and Korn shell (ksh), respectively.

RBAC Roles

A role is a special type of user account from which you can run privileged applications. Roles are created in the same general manner as user accounts, with a home directory, groups, password, and so on. The capabilities of a role are a function of the rights profiles and authorizations that are assigned to it. Roles do not have inheritance.

When a user assumes a role, the role's attributes replace all user attributes. Role information is stored in the passwd, shadow, user_attr, and audit_user databases. For detailed information on setting up roles, see Configuring Recommended Roles, Creating Roles, and Changing Role Properties.

All users who can assume the same role have the same role home directory, operate in the same environment, and have access to the same files. Users can assume roles from the command line by running su and supplying the role name and password. Users can also assume a role when they open a Solaris Management Console tool.

Users cannot log in directly to a role. For this reason, it is useful to make root a role to prevent anonymous root login. See Making Root a Role. Users must log in to their user account first. A user cannot assume a role directly from another role. A user's real UID can always be audited.

No predefined roles are shipped with the Solaris 9 software. As stated earlier in this chapter, you can easily configure the three recommended roles.

RBAC Authorizations

An authorization is a discrete right that can be granted to a role or user. RBAC-compliant applications can check a user's authorizations prior to granting access to the application or specific operations within it. This check replaces the check in conventional UNIX applications for UID=0. For more information on authorizations, see Authorizations, The auth_attr Database, and Commands That Require Authorizations.

RBAC Rights Profiles

A rights profile is a collection of system overrides that can be assigned to a role or user. A rights profile can contain commands with effective or real UIDs or GIDs defined, authorizations, and other rights profiles. Rights profile information is split between the prof_attr and exec_attr databases. For more information on rights profiles, see Contents of Rights Profiles, The prof_attr Database, and The exec_attr Database.

Name Service Scope

Name service scope is an important concept for understanding RBAC. The scope in which a role can operate might apply to an individual host or to all hosts that are served by a name service such as NIS, NIS+, or LDAP. The precedence of local configuration files versus distributed databases is specified in the file /etc/nsswitch.conf. A lookup stops at the first match. For example, if a profile exists in two scopes, only the entries in the first scope are used.

Chapter 6 Role-Based Access Control (Tasks)

This chapter covers tasks that you can use to manage RBAC elements. The following is a list of the task maps in this chapter. To find the tasks for the initial setup of RBAC, see Configuring RBAC (Task Map). For general management of the RBAC elements, see Chapter 5, Role-Based Access Control (Overview).

The following is a list of information in this chapter:

• Planning for RBAC

• First-Time Use of the User Tool Collection

• Setting Up Initial Users

• Setting Up Initial Roles

• Making Root a Role

• Using Privileged Applications

• Creating Roles

• Changing Role Properties

• Creating or Changing a Rights Profile

• Modifying a User's RBAC Properties

• Securing Legacy Applications

The preferred method for performing RBAC-related tasks is through the Solaris Management Console. The console tools for managing the RBAC elements are contained in the User Tool Collection.

You can also operate on local files with the Solaris Management Console command-line interface and other command-line interfaces. The Solaris Management Console commands require authentication to connect to the server. As a result, they are not practical in scripts. The other commands require superuser or a role, and cannot be applied to databases in a name service.

Another drawback to using the command line to manage RBAC information is that the edit may not take effect immediately. To enable the edit, you need to stop and restart the name service cache daemon, nscd(1M).

Configuring RBAC (Task Map)

Planning for RBAC

RBAC can be an integral part of how an organization manages its information resources. Planning requires a thorough knowledge of the RBAC capabilities as well as the security requirements of the organization.

How to Plan Your RBAC Implementation

1. Learn the basic RBAC concepts.

   Read Chapter 5, Role-Based Access Control (Overview). Using RBAC to administer a system is very different from using conventional UNIX. You should be familiar with the RBAC concepts before you start your implementation. For greater detail, see Chapter 7, Role-Based Access Control (Reference).

2. Examine your security policy.

   Your organization's security policy should detail the potential threats to your system, measure the risk of each threat, and have a strategy to counter these threats. Isolating the security-relevant tasks through RBAC can be a part of the strategy. Although you can install the suggested roles and their configurations as is, you might need to customize your RBAC configuration to adhere to your security policy.

3. Decide how much RBAC your organization needs.

   Depending on your security needs, you can use varying degrees of RBAC, as follows:

   • No RBAC – You can perform all tasks as root user. In this instance, you log in as yourself and when you select a console tool, you type root as the user.

   • Root as a Role – This method eliminates anonymous root logins by preventing all users from logging in as root. Instead, they must log in as normal users prior to assuming the root role. See Making Root a Role.

   • Single Role Only – This method adds the Primary Administrator role only and is similar to the superuser model.

   • Suggested Roles – Three suggested roles that can be easily configured are available: Primary Administrator, System Administrator, and Operator. These roles are suitable for organizations with administrators at different levels of responsibility whose job capabilities fit the suggested roles.

   • Custom Roles – You can create your own roles to meet the security requirements of your organization. The new roles can be based on existing or customized rights profiles.

4. Decide which suggested roles are appropriate for your organization.

   Review the capabilities of the suggested roles and default rights profiles. Three rights profiles are available for configuring the suggested roles:

   • Primary Administrator rights profile – For creating a role that can perform all administrative tasks, granting rights to others, and editing rights that are associated with administrative roles. A user in this role can assign the Primary Administrator role and the ability to grant rights to other users.

   • System Administrator rights profile – For creating a role that can perform most nonsecurity administrative tasks. For example, the System Administrator can add new user accounts, but cannot set passwords or grant rights to other users.

   • Operator rights profile – For creating a role that can perform simple administrative tasks, such as backup and restore, and printer maintenance.

   These rights profiles enable administrators to configure the suggested roles by using a single rights profile instead of having to mix and match rights profiles.

   To further examine rights profiles, use the Rights tool to display the contents. You can also refer to Contents of Rights Profiles for a summary of some typical rights profiles. With the console tools, you can customize the roles and rights profiles that are provided to meet the needs of your organization.

5. Decide if any additional roles or rights profiles are appropriate for your organization.

   Look for other applications or families of applications at your site that might benefit from restricted access. Applications that affect security, that can cause denial-of-service problems, or that require special administrator training are good candidates for RBAC.

   1. Determine which commands are needed for the new task.

   2. Decide which rights profile is appropriate for this task.

      Check if an existing rights profile can handle this task or if a separate rights profile needs to be created.

   3. Determine which role is appropriate for this rights profile.

      Decide if the rights profile for this task should be assigned to an existing role or if a new role should be created. If you use an existing role, check that the other rights profiles are appropriate for users who are assigned to this role.

6. Decide which users should be assigned to the available roles.

   According to the principle of least privilege, you should assign users to roles that are appropriate to their level of trust. Keeping users away from tasks that they do not need to use reduces potential problems.

First-Time Use of the User Tool Collection

To install the initial users to their assigned roles, you first log in as yourself. When you authenticate yourself to the Solaris Management Console, specify root user.

How to Run the User Tool Collection

1. Log in as a normal user and start the Solaris Management Console.

   % whoami johnDoe % /usr/sadm/bin/smc&

2. Navigate to the User Tool Collection and click the icon, as follows:

   1. Find the icon that is labeled This Computer under Management Tools in the navigation pane.

   2. Click the turner icon to its left.

      The turner icon is shaped like a lever. When the lever is horizontal, the contents of the folder are hidden. When the lever is vertical, the contents are displayed. Clicking the turner icon toggles the folder between the hidden and displayed states.

   3. Click the turner icon next to the System Configuration folder to display its contents.

   4. Click the User icon to open the User Tool Collection.

      The user login dialog box is displayed.

3. Type root and the root password in the Login: User Name dialog box. Click OK.

   Generally, you should type your user name here and then assume a role. However, for the first time, you need to be root user because no roles exist yet. This step opens the User Tool Collection (see the following figure).

   Figure 6–1 The User Tool Collection

   
   

Setting Up Initial Users

If all users who are assigned to roles are already installed on this system, you can skip this task and go to Setting Up Initial Roles.

How to Create Initial Users by Using the User Accounts Tool

1. Click the User Accounts tool icon in either the navigation pane or the view pane of the User Tool Collection.

   The User Accounts tool is started. The Action menu now provides options for this tool.

2. Select Add User->With Wizard from the Action menu.

   This step starts the Add User wizard, a series of dialog boxes that request information that is necessary for configuring a user. Use the Next and Back buttons to navigate between dialog boxes. Note that the Next button does not become active until all required fields have been filled in. The last dialog box is for reviewing the entered data, at which point you can go back to change entries or click Finish to save the new role.

   The following figure shows the first dialog box, Step 1: Enter a user name.

   Figure 6–2 Add User Wizard

   
   

3. Type the name of the first user and the other identification information.

4. In the Step 2: Enter a User Identification Number dialog box, type the UID.

   This entry should match the existing UID for the user.

5. In the Step 3: Enter the User's Password dialog box, indicate whether you or the user will be setting the password.

   If you are setting up this account for yourself, click the second option. Then, type and confirm your password.

6. In the Step 4: Select the User's Primary Group dialog box, select the appropriate group.

7. In the Step 5: Create the User's Home Directory dialog box, specify the path for the home directory.

8. In the Step 6: Specify the Mail Server dialog box, check out the default mail server and mailbox.

   You can change these settings later in the User Properties dialog box.

9. Check the information in the Review dialog box. Click Finish to save, or click Back to reenter information.

   If you discover missing or incorrect information, click the Back button repeatedly to display the dialog box where the incorrect information is displayed. Then, click Next repeatedly to return to the Review dialog box.

Setting Up Initial Roles

The first role to create is the role that is responsible for managing users and roles, typically the Primary Administrator. First, you should install the users and the roles on your local host. After you have set up a toolbox for the name service scope, you need to create the same users and roles in the name service. See “Using the Solaris Management Tools in a Name Service Environment (Task Map)” in System Administration Guide: Basic Administration. After the first role is established and assigned to you, then you can run the console tools by assuming a role instead of becoming root.

How to Create the First Role (Primary Administrator) by Using the Administrative Roles Tool

To install the first role, you should log in as yourself. When you authenticate yourself to the Solaris Management Console, specify root user. You should first install the role on your local host. After the first role is established and assigned to you, you can run the console tools by assuming a role instead of as root user.

1. Type root and the root password in the Login: User Name dialog box. Click OK.

2. Click the Administrative Roles icon in either the navigation pane or the view pane of the User Tool Collection.

   The Administrative Roles tool is started. The Action menu now provides options for this tool.

3. Select Add Administrative Role from the Action menu.

   This step starts the Add Administrative Role wizard, a series of dialog boxes that request information that is necessary for configuring a role. Use the Next and Back buttons to navigate between dialog boxes. Note that the Next button does not become active until all required fields have been filled in. The last dialog box is for reviewing the entered data, at which point you can go back to change entries or click Finish to save the new role.

   The following figure shows the first dialog box, Step 1: Enter a Role Name.

   Figure 6–3 Add Administrative Role Wizard

   
   

4. Type primaryadmin, or whatever role name you are using, and the other identification information.

   If you select the role mailing list option, you can create an alias of users who can assume this role.

5. In the Step 2: Enter a Role Password dialog box, type the password for the new role in the Role Password field and again in the Confirm Password field.

   Confirmation helps prevent a misspelled password from being saved.

6. In the Step 3: Enter Role Rights dialog box, select the Primary Administrator rights profile.

   Double-click the Primary Administrator rights profile in the Available Rights column (on the left). The rights profiles in the Granted Rights column (on the right) are the rights profiles that are assigned to this role. In this instance, only the Primary Administrator rights profile is needed.

7. In the Step 4: Select a Home Directory dialog box, specify the server and path for the home directory.

8. In the Step 5: Assign Users to This Role dialog box, type the login names for any users to be assigned to the Primary Administrator role.

   Any users that you add must be defined in the same name service scope in which you are working. If you selected the role mailing list option in the Step 1: Enter a Role Name dialog box, these users will receive email that is addressed to the Primary Administrator role.

9. Check the information in the Review dialog box. Click Finish to save, or click Back to reenter information.

   If you discover missing or incorrect information, click the Back button repeatedly to display the dialog box where the incorrect information is displayed. Then, click Next repeatedly to return to the Review dialog box.

10. Open a terminal window, become root, and start and stop the name service cache daemon.

    The new role does not take effect until the name service cache daemon is restarted. After becoming root, type as follows:

    # /etc/init.d/nscd stop # /etc/init.d/nscd start

Making Root a Role

This procedure shows how to change root from a user to a role within a local scope. Changing root to a role prevents users from logging in to that server directly as root. Users must first log in as themselves so their UIDs are available for auditing.

If you make root a role without assigning it to a valid user or without a currently existing role equivalent to root, no one can become root.

How to Make Root a Role

1. Log in to the target server.

2. Become superuser.

3. Edit the /etc/user_attr file.

   Here is an excerpt from a typical user_attr file.

   root::::type=normal;auths=solaris.*,solaris.grant;profiles=All johnDoe::::type=normal

4. Check that your name is in the file.

5. Add root to the roles that are assigned to your record.

   Assign the root role to any applicable users. If you intend to use primaryadmin as your most powerful role, you do not have to assign root to any users.

   johnDoe::::type=normal;roles=root

6. Go to the root record in the file and change type=normal to type=root.

   root::::type=role;auths=solaris.*,solaris.grant;profiles=All

7. Save the file.

Managing RBAC Information (Task Map)

The following task map shows where to obtain information for performing specific RBAC tasks.

These procedures manage the elements that are used in role-based access control (RBAC). For user management procedures, refer to “Managing User Accounts and Groups (Tasks)” in System Administration Guide: Basic Administration.

Using Privileged Applications

To run privileged applications, you must first become superuser or assume a role. Although running privileged applications as a normal user is possible, it is discouraged to avoid errors that are caused by users who inadvertently exercise this privilege.

How to Assume a Role at the Command Line

1. Use the su command as follows:

   % su my-role Password: my-role-password #

   Typing su by itself lets you become superuser. Typing su with a role name lets you assume that role (if it has been assigned to you). You must supply the appropriate password. Assuming a role switches the command line to the profile shell for that role. The profile shell has been modified to run commands with the security attributes that are assigned in the role's rights profiles.

2. Type a command in the shell.

   The command is executed with any assigned security attributes and setuid or setgid permissions.

How to Assume a Role in the Console Tools

1. Start the Solaris Management Console.

   Use one of the following methods:

   • Type smc at the command line.

   • Click the Solaris Management Console icon in the Tools subpanel.

   • Double-click the Solaris Management Console icon in the Application Manager.

   All Solaris Management Console tools have extensive context-sensitive help that document each field. In addition, you can access various help topics from the Help menu. Note that it does not matter whether you are logged in as root or as a normal user when you start the console.

2. Select the toolbox for your task.

   Navigate to the toolbox that contains the tool or collection in the appropriate scope and click the icon. The scopes are files (local), NIS, NIS+, and LDAP. If the appropriate toolbox is not displayed in the navigation pane, choose Open Toolbox from the Console menu and load the relevant toolbox.

3. Select the tool.

   Navigate to the tool or collection to be used and click the icon. The tools for managing the RBAC elements are all part of the User Tool Collection.

4. Authenticate yourself in the Login: User Name dialog box.

   Your choices are the following:

   • Type your user name and password to assume a role or to operate as a normal user.

   • Type root and the root password to operate as superuser.

   Note that if you have not yet set up any roles or if the roles that are set up cannot perform the appropriate tasks, you need to log in as root. If you authenticate yourself as root (or as a user with no roles assigned), the tools are loaded into the console and you can proceed to Step 6.

5. Authenticate yourself in the Login: Role dialog box.

   The Role option menu in the dialog box displays the roles that are assigned to you. Choose a role and type the role password. If you are to operate as a normal user, type your user name and password.

6. Navigate to the tool to be run and click the icon.

Creating Roles

To create a role, you must either assume a role that has the Primary Administrator rights profile assigned to it or run as root user. See RBAC Roles and Configuring Recommended Roles to learn more about roles.

How to Create a Role by Using the Administrative Roles Tool

1. Start the Administrative Roles tool.

   Run the Administrative Roles tool, start the Solaris Management Console, as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the Administrative Roles icon.

2. Start the Add Administrative Role wizard.

   Select Add Administrative Role from the Action menu to start the Add Administrative Role wizard for configuring roles.

3. Fill in the fields in the series of dialog boxes. Click Finish when done.

   Use the Next and Back buttons to navigate between dialog boxes. Note that the Next button does not become active until all required fields have been filled in. The last dialog box is for reviewing the entered data, at which point you can go back to change entries or click Finish to save the new role. Table 6–1 summarizes the dialog boxes.

4. Open a terminal window, become root, and start and stop the name service cache daemon.

   The new role does not take effect until the name service cache daemon is restarted. After becoming root, type as follows:

   # /etc/init.d/nscd stop # /etc/init.d/nscd start

How to Create a Role From the Command Line

1. Become superuser or assume a role that is capable of creating other roles.

2. Select a method for creating a role:

   • For roles in the local scope, use the roleadd command to specify a new local role and its attributes.

   • Alternatively, for roles in the local scope, edit the user_attr file to add a user with type=role.

     This method is recommended for emergencies only, as it is easy to make mistakes while you are typing.

   • For roles in a name service, use the smrole command to specify the new role and its attributes.

     This command requires authentication by superuser or a role that is capable of creating other roles. You can apply the smrole to all name services. This command runs as a client of the Solaris Management Console server.

3. Start and stop the name service cache daemon.

   New roles do not take effect until the name service cache daemon is restarted. As root, type as follows:

   # /etc/init.d/nscd stop # /etc/init.d/nscd start

Example 6–1 Creating a Custom Operator Role by Using the smrole Command

The following sequence demonstrates how a role is created with the smrole command. In this example, a new version of the Operator role is created that has assigned to it the standard Operator rights profile and the Media Restore rights profile.

% su primaryadmin 
# /usr/sadm/bin/smrole add -H myHost -- -c "Custom Operator" -n oper2 -a johnDoe \
-d /export/home/oper2 -F "Backup/Restore Operator" -p "Operator" -p "Media Restore"
Authenticating as user: primaryadmin

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <type primaryadmin password>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadmin was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password ::<type oper2 password>

# /etc/init.d/nscd stop
# /etc/init.d/nscd start

To view the newly created role (and any other roles), use smrole with the list subcommand, as follows:

# /usr/sadm/bin/smrole list --
Authenticating as user: primaryadmin

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <type  primaryadmin password>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadmin was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.
root                    0               Super-User
primaryadmin            100             Most powerful role
sysadmin                101             Performs non-security admin tasks
oper2                   102             Backup/Restore Operator

Changing Role Properties

To change a role, you must either assume a role that has the Primary Administrator rights profile assigned to it, or run the User Tool Collection as root user if roles have not yet been set up.

How to Change a Role by Using the Administrative Roles Tool

1. Start the Administrative Roles tool.

   To run the Administrative Roles tool, you need to start the Solaris Management Console, as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the Administrative Roles icon.

   After the Administrative Roles tool starts, the icons for the existing roles are displayed in the view pane.

2. Click the role to be changed and select the appropriate item from the Action menu, as follows:

   • To change users who are assigned to a role, select Assign Administrative Role.

     The Assign Administrative Role dialog box is displayed. The Assign Administrative Role dialog box is a modified version of the Role Properties dialog box and has a Users tab only. Use the Add field to assign a user in the current scope to this role. Use the Delete field to remove a user's role assignment. Click OK to save.

   • To change rights that are assigned to a role, select Assign Rights to Role.

     The Assign Rights to Role dialog box is displayed. The Assign Rights to Role dialog box is a modified version of the Role Properties dialog box and has a Rights tab only. Use the Available Rights and Granted Rights columns to add or remove rights profiles for the selected role. Click OK to save.

   • To change any of the role's properties, select Properties (or simply double-click the role icon).

     The Role Properties dialog box is displayed, which provides access to all role properties (see the following figure and table). Use the tabs to navigate to any information to be changed, make your changes, and click OK to save.

     Figure 6–4 Role Properties Dialog Box

     
     
     Table 6–2 Role Properties Summary

     Tab	Tab Description
     General	Specifies the role identification information and the default login shell.
     Password	Specifies the role password.
     Users	Specifies the users who are assigned to the role.
     Group	Sets the role's primary groups and secondary groups for the purpose of accessing and creating files and directories.
     Home Directory	Specifies the role's home directory, home directory server, automounting, and directory access.
     Rights	Allows rights profiles to be assigned to the role. The precedence of the assigned rights profiles can be changed here.

How to Change a Role From the Command Line

1. Become superuser or assume a role that is capable of changing other roles.

2. Use the command that is appropriate for the task:

   • Use the rolemod command to modify the attributes of a role that are defined locally.

   • Use the roledel command to delete a role that is defined locally.

   • Edit the user_attr file to change the authorizations or rights profiles that are assigned to a local role.

     This method is recommended for emergencies only, as it is easy to make a mistake while you are typing.

   • Use the smrole command to modify the attributes of a role in a name service.

     This command requires authentication as superuser or as a role that is capable of changing other roles. The smrole command runs as a client of the Solaris Management Console server.

Creating or Changing a Rights Profile

To create or change a rights profile, you must either assume a role that has the Primary Administrator rights profile assigned to it, or run the User Tool Collection as root user if roles have not yet been set up. To learn more about rights profiles, see RBAC Roles and Configuring Recommended Roles.

How to Create or Change a Rights Profile by Using the Rights Tool

1. Start the Rights tool.

   To run the Rights tool, you need to start the Solaris Management Console as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the Rights icon.

   After the Rights tool starts, the icons for the existing rights profiles are displayed in the view pane.

2. Take the appropriate action for creating or changing a rights profile:

   • To create a new rights profile, select Add Right from the Action menu.

   • To change an existing rights profile, click the rights profile icon and select Properties from the Action menu (or simply double-click the rights profile icon).

   Both actions display a version of the Rights Properties dialog box. The Add Right version (which follows) has a writable Name field. The standard Rights Properties dialog box has a read-only Name field because the name of a rights profile cannot be changed after it has been defined.

   Figure 6–5 Add Right Dialog Box

   
   

3. Type the new information. Click OK to save the rights profile.

   The following table lists the tabs and fields in the Right Properties dialog box.

   Tab	Field	Field Description
   General	Name	Name of the new rights profile.
   	Description	Description of the new rights profile.
   	Help File Name	Name of the HTML help file for the new rights profile.
   Commands	Add Directory	Opens a dialog box for adding directories that are not already in the Commands Denied or Commands Permitted columns.
   	Commands Denied / Commands Permitted	Assigns or removes a rights profile's commands.
   	Set Security Attributes	Opens a dialog box for assigning or removing a command's security attributes, that is, real or effective UIDs or GIDs (see Figure 6–6). Note – Assigning effective IDs is preferred over assigning real IDs. Use real IDs only when they are required by the command, such as pkgadd.
   	Find (command)	Searches the two command lists for the specified string.
   Authorizations	Authorizations Excluded / Authorizations Included	Assigns or removes a rights profile's authorizations.
   Supplementary Rights	Rights Excluded / Rights Included	Assigns or removes a rights profile's supplementary rights profiles.

   Figure 6–6 Adding Security Attributes to Commands

   
   

Example 6–2 Creating a New Rights Profile With the Rights Tool

The data in the following table shows sample data for a hypothetical rights profile that is called “Restart” could be created. The example rights profile, Restart, has the commands in the subdirectory /etc/init.d assigned to it. These commands have an effective UID of 0. This rights profile would be useful for administrators who are permitted to stop and start the daemons in /etc/init.d.

How to Change Rights Profiles From the Command Line

1. Become superuser or assume a role with the PrimaryAdministration rights profile.

2. Use the subcommand of smprofile that is appropriate for the task.

   This command requires authentication. You can apply the command to all name services. smprofile runs as a client of the Solaris Management Console server.

   • To add a new profile, use smprofile with the add subcommand.

   • To change an existing profile, use smprofile with the modify subcommand.

Modifying a User's RBAC Properties

To modify a user's properties, you must either be running the User Tool Collection as root user or assume a role that has the Primary Administrator rights profile assigned to it.

How to Modify a User's RBAC Properties by Using the User Accounts Tool

1. Start the User Accounts tool.

   To run the User Accounts tool, you need to start the Solaris Management Console, as described in How to Assume a Role in the Console Tools. Then, open the User Tool Collection, and click the User Accounts icon.

   After the User Accounts tool starts, the icons for the existing user accounts are displayed in the view pane.

2. Click the user account icon to be changed and select Properties from the Action menu (or simply double-click the user account icon).

3. Click the appropriate tab in the dialog box for the property to be changed, as follows:

   • To change the roles that are assigned to the user, click the Roles tab and move the role assignment to be changed to the appropriate column: Available Roles or Assigned Roles.

   • To change the rights profiles that are assigned to the user, click the Rights tab and move it to the appropriate column: Available Rights or Assigned Rights.

     ---

     Note –

     It is not good practice to assign rights profiles directly to users. The preferred approach is to force users to assume roles in order to perform privileged applications. This strategy avoids the possibility of normal users abusing privileges.

     ---

How to Modify a User's RBAC Properties From the Command Line

1. Become superuser or assume a role that can modify user files.

2. Use the appropriate command:

   • To change the authorizations, roles, or rights profiles that are assigned to a user who is defined in the local scope, use the usermod command.

   • Alternatively, to change the authorizations, roles, or rights profiles that are assigned to a user who is defined in the local scope, edit the user_attr file.

     This method is recommended for emergencies only, as it is easy to make a mistake while you are typing.

   • To change the authorizations, roles, or rights profiles that are assigned to a user who is defined in a name service, use the smuser command.

     This command requires authentication as superuser or as a role that is capable of changing user files. You can apply smuser to all name services. smuser runs as a client of the Solaris Management Console server.

Securing Legacy Applications

This section discusses how to make legacy applications more secure. To add legacy applications to the Solaris Management Console, see “Adding Tools to the Solaris Management Console” in System Administration Guide: Basic Administration.

How to Add Security Attributes to a Legacy Application

You add security attributes to a legacy application in the same way as you would for any command. You need to add the command (or its directory) to the Commands Denied column in the Commands tab of the Rights property dialog box. Then move the command to the Commands Permitted column.

How to Add Security Attributes to Commands in a Script

If a command in a script needs to have the setUID bit set to run, simply add the security attributes to that command in the same rights profile. See How to Create or Change a Rights Profile by Using the Rights Tool.

How to Check for Authorizations in a Script or Program

To have a script for authorizations, you need to add a test that is based on the auths command (see the auths(1) man page). For example, the following line would test if the user has the authorization entered as the $1 argument:

if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then
        echo Auth granted
else
        echo Auth denied
fi

To be more complete, the test should include logic that checks for other authorizations that use wildcards. For example, to test if the user has the solaris.admin.usermgr.write authorization, you need to check for the strings: solaris.admin.usermgr.write, solaris.admin.usermgr.*, solaris.admin.*, and solaris.*.

If you are writing a program, use the getauthattr() function to test for the authorization.

Chapter 7 Role-Based Access Control (Reference)

This chapter provides additional information that supplements Chapter 5, Role-Based Access Control (Overview).

The following is a list of the reference information in this chapter:

• Configuring Recommended Roles

• Contents of Rights Profiles

• Authorizations

• RBAC Database Relationships

• The user_attr Database

• The auth_attr Database

• The prof_attr Database

• The exec_attr Database

• Command-Line Applications for Managing RBAC

• Commands That Require Authorizations

For information on RBAC tasks, see Chapter 6, Role-Based Access Control (Tasks).

RBAC Elements: Reference Information

This section describes the role-based access control (RBAC) elements in detail.

Configuring Recommended Roles

No predefined roles are shipped with the Solaris 9 software. Management at a customer site must decide what types of roles should be set up. However, three recommended roles can be readily configured by assigning the appropriate predefined rights profile to the corresponding roles:

• Primary Administrator rights profile – For creating a role that can perform all administrative tasks, granting rights to others, and editing rights that are associated with administrative roles. A user in this role can assign the Primary Administrator role and the ability to grant rights to other users.

• System Administrator rights profile – For creating a role that can perform most nonsecurity administrative tasks. For example, the System Administrator can add new user accounts, but cannot set passwords or grant rights to other users.

• Operator rights profile – For creating a role that can perform simple administrative tasks, such as backup and restore, and printer maintenance.

These rights profiles enable administrators to configure the suggested roles by using a single rights profile instead of having to mix and match rights profiles.

Those sites that customize roles should closely check the order of the rights profiles that are assigned to the role. The system does not prevent someone from typing multiple occurrences of the same command. The attributes that are assigned to the first occurrence of a command in a rights profile take precedence and all subsequent occurrences are ignored.

You can also set up root as a role through a manual process. This method prevents users from logging in directly as root, forcing them to log in as themselves first. See Making Root a Role.

Contents of Rights Profiles

This section describes some typical rights profiles.

• The All rights profile provides role access to commands without security attributes.

• The Primary Administrator rights profile is designed specifically for the Primary Administrator role. The Primary Administrator rights profile allows the use of wildcards.

• The System Administrator rights profile is designed specifically for the System Administrator role. The System Administrator rights profile uses discrete supplementary profiles to create a powerful role.

• The Operator rights profile is designed specifically for the Operator role. The Operator rights profile uses a few discrete supplementary profiles to create a simple role.

• The Basic Solaris User rights profile shows how the policy.conf file can be used to assign tasks to users that are not related to security.

• The Printer Management rights profile exemplifies a profile that is dedicated to a single area of administration.

The tables in the following sections show the purpose and the contents of these rights profiles, including the commands, authorizations, supplementary rights, rights profiles, and associated help files.

Help files are in HTML and can be readily customized, if required. These files reside in the /usr/lib/help/auths/locale/C directory.

The Solaris Management Console Rights tool provides another way of inspecting the contents of the rights profiles.

All Rights Profile

The All rights profile uses the wildcard to include all commands, except for those commands without security attributes. This rights profile provides a role with access to all commands that are not explicitly assigned in other rights profiles. Without the All rights profile or some other rights profiles that use wildcards, a role has access to explicitly assigned commands only, which is not very practical.

Because commands in rights profiles are interpreted in the order in which they occur, any wildcard settings should be positioned last so that explicit attribute assignments are not inadvertently overridden. The All rights profile, if used, should be the final rights profile that is assigned.

Primary Administrator Rights Profile

The Primary Administrator rights profile is assigned the most powerful role on the system, effectively providing that role with superuser capabilities.

• The solaris.* authorization effectively assigns all of the authorizations that are provided by the Solaris software.

• The solaris.grant authorization lets a role assign any authorization to any rights profile, role, or user.

• The command assignment *:uid=0;gid=0 provides the ability to run any command with UID=0 and GID=0.

The help file RtPriAdmin.html is identified so that a site can modify it if necessary. Help files are stored in the /usr/lib/help/auths/locale/C directory.

Note also that if the Primary Administrator rights profile is not consistent with a site's security policy, it can be modified or not assigned at all. However, the security capabilities in the Primary Administrator rights profile would need to be handled in one or more other rights profiles.

System Administrator Rights Profile

The System Administrator rights profile is intended for the System Administrator role. Because the System Administrator does not have the broad powers of the Primary Administrator, no wildcards are used. Instead, discrete administrative rights profiles that do not deal with security are assigned. The commands that are assigned to the supplementary rights profiles are not shown in the following table.

Notice that the All rights profile is assigned at the end of the list of supplementary rights profiles.

Operator Rights Profile

The Operator rights profile is a less powerful administrative rights profile that provides the ability to do backups and printer maintenance. The ability to restore files has more security consequences, and the default is not to assign it to this rights profile.

Basic Solaris User Rights Profile for User

By default, the Basic Solaris User rights profile is assigned automatically to all users through the policy.conf file. This rights profile provides basic authorizations that are useful in normal operations. Note that the convenience that is offered by the Basic Solaris User rights profile must be balanced against site security requirements. Those sites that need stricter security might prefer to remove this rights profile from the policy.conf file.

Printer Management Rights Profile

Printer Management is a typical rights profile that is intended for a specific task area. Both authorizations and commands are assigned to the Printer Management rights profile. The following table shows a partial list of commands.

Authorizations

An authorization is a discrete right that can be granted to a role or user. Authorizations are checked by RBAC-compliant applications before a user gets access to the application or specific operations within it. This check replaces the tests in conventional UNIX applications for UID=0.

Authorization Naming Convention

An authorization has a name that is used internally and in files (for example, solaris.admin.usermgr.pswd), and a short description, which appears in the graphical user interfaces (for example, Change Passwords).

By convention, authorization names consist of the reverse order of the Internet name of the supplier, the subject area, any subareas, and the function, which are all separated by dots. An example would be com.xyzcorp.device.access. Exceptions to this convention are the authorizations from Sun Microsystems, Inc., which use the prefix solaris instead of an Internet name. Sun's convention enables administrators to apply authorizations in a hierarchical fashion by using a wildcard (*) to represent any strings to the right of a dot.

Example of Authorization Granularity

As an example of how authorizations are used, consider the following. A user in the Operator role might be limited to the solaris.admin.usermgr.read authorization, which provides read but not write access to users' configuration files. The System Administrator role naturally has the solaris.admin.usermgr.read and also the solaris.admin.usermgr.write authorization for making changes to users' files. However, without the solaris.admin.usermgr.pswd authorization, the System Administrator cannot change passwords. The Primary Administrator has all three of these authorizations.

The solaris.admin.usermgr.pswd authorization is required to make password changes in the Solaris Management Console User Tool. This authorization is also required for using the password modification options in the smuser, smmultiuser, and smrole commands.

Delegating Authorizations

An authorization that ends with the suffix grant permits a user or role to delegate to other users any assigned authorizations that begin with the same prefix.

For example, a role with the authorizations solaris.admin.usermgr.grant and solaris.admin.usermgr.read can delegate the solaris.admin.usermgr.read authorization to another user. A role with the solaris.admin.usermgr.grant and solaris.admin.usermgr.* can delegate any of the authorizations with the solaris.admin.usermgr prefix to other users.

Databases That Support RBAC

The following four databases store the data for the RBAC elements:

• user_attr (extended user attributes database) – Associates users and roles with authorizations and rights

• auth_attr (authorization attributes database) – Defines authorizations and their attributes, and identifies the associated help file

• prof_attr (rights profile attributes database) – Defines rights profiles, lists the rights profile's assigned authorizations, and identifies the associated help file

• exec_attr (execution attributes database) – Identifies the commands with security attributes that are assigned to specific rights profiles

The commands can also indicate a security policy. Currently, the only security policy that is available for the Solaris operating environment is suser (short for superuser). The suser policy is the default and it accommodates both the ID attributes and authorizations. The Trusted Solaris environment, which can interoperate with the Solaris environment, uses a policy called tsol. Additional policies might be available in future releases.

The policy.conf database is also important to the RBAC implementation. This database can contain authorizations and rights profiles that are to be applied by default to all users.

RBAC Database Relationships

The following figure illustrates how the RBAC databases work together.

Figure 7–1 RBAC Database Relations

The user_attr database stores the basic definitions for both users and roles, which are differentiated by the type field. The user_attr database contains the attributes that are shown in the figure, which includes a comma-separated list of rights profile names. The definitions of the rights profiles are split between two databases. The prof_attr database contains rights profile identification information, authorizations that are assigned to the profile, and supplementary profiles. The exec_attr database identifies the security policy and contains commands with their associated security attributes. The auth_attr database supplies authorization information to the Sun Management Console tools. The policy.conf database supplies default authorizations and rights profiles that are to be applied to all users.

Each database uses a key=value syntax for storing attributes. This method accommodates future expansion of the databases and enables a system to continue if it encounters a key that is unknown to its policy.

The scope of the RBAC databases can apply to individual hosts or to all hosts that are served by a name service such as NIS, NIS+, or LDAP. The precedence of local configuration files versus distributed databases for the user_attr database is set by the precedence that is specified for the passwd entry in the file /etc/nsswitch.conf. The precedence for the prof_attr and auth_attr databases are individually set in /etc/nsswitch.conf. The exec_attr database uses the same precedence as prof_attr. For example, if a command with security attributes is assigned to a profile that exists in two scopes, only the entry in the first scope is used.

The databases can reside on a local system or can be administered by the NIS, NIS+, or LDAP name service.

You can edit the databases manually or manipulate them with the commands that are described in Command-Line Applications for Managing RBAC.

The user_attr Database

The user_attr database contains user and role information that supplements the passwd and shadow databases. The user_attr database contains extended user attributes such as authorizations, rights profiles, and assigned roles. The fields in the user_attr database are separated by colons, as follows:

user:qualifier:res1:res2:attr

The following table describes these fields.

The following example demonstrates how the Operator role is defined in a typical user_attr database and how it is assigned to user johnDoe. Roles and users are differentiated by the type keyword.

% grep operator /etc/user_attr 
johnDoe::::type=normal;roles=sysadmin,operator
operator::::profiles=Operator;type=role

The auth_attr Database

All authorizations are stored in the auth_attr database. Authorizations can be assigned directly to users (or roles) in the user_attr database. Authorizations can also be assigned to rights profiles, which are assigned to users.

The fields in the auth_attr database are separated by colons, as follows:

authname:res1:res2:short_desc:long_desc:attr

The following table describes these fields.

The following example shows an auth_attr database with some typical values.

% grep printer /etc/security/auth_attr 
solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html
solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html
solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html
solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html

Note that solaris.admin.printer. is defined to be a heading, because it ends in a dot (.). Headings are used by the GUIs to organize families of authorizations.

The prof_attr Database

The prof_attr database stores the name, description, help file location, and authorizations that are assigned to rights profiles. The commands and security attributes that are assigned to rights profiles are stored in the exec_attr database (see The exec_attr Database). The fields in the prof_attr database are separated by colons:

profname:res1:res2:desc:attr

The following table describes these fields.

The following example shows a typical prof_attr database. Note that the Printer Management rights profile is a supplementary rights profile that is assigned to the Operator rights profile.

% grep 'Printer Management' /etc/security/prof_attr 
Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.html; \ 
auths=solaris.admin.printer.read,solaris.admin.printer.modify,solaris.admin.printer.delete \
Operator:::Can perform simple administrative tasks:profiles=Printer Management,\
Media Backup,All;help=RtOperator.html
...

The exec_attr Database

An execution attribute is a command that is associated with a specific UID or GID and that is assigned to a rights profile. The command with its security attributes can be run by users or roles to whom the rights profile is assigned.

The exec_attr database stores the definitions of the execution attributes.

The fields in the exec_attr database are separated by colons:

name:policy:type:res1:res2:id:attr

The following table describes these fields.

The following example shows some typical values from an exec_attr database.

% grep 'Printer Management' /etc/security/exec_attr
Printer Management:suser:cmd:::/usr/sbin/accept:euid=lp
Printer Management:suser:cmd:::/usr/ucb/lpq:euid=0
Printer Management:suser:cmd:::/etc/init.d/lp:euid=0
.
.
.

The policy.conf File

The policy.conf file provides a way of granting specific rights profiles and authorizations to all users. The two types of entries in the file consist of key-value pairs. They are the following:

• AUTHS_GRANTED=authorizations – Refers to one or more authorizations

• PROFS_GRANTED=right profiles – Refers to one or more rights profiles

The following example shows some typical values from a policy.conf database.

# grep AUTHS /etc/security/policy
AUTHS_GRANTED=solaris.device.cdrw

# grep PROFS /etc/security/policy
PROFS_GRANTED=Basic Solaris User

RBAC Commands

This section lists commands that are used to administer RBAC. Also provided is a table of commands whose access can be controlled by authorizations.

Command-Line Applications for Managing RBAC

In addition to editing the RBAC databases directly, the following commands are available for managing access to tasks with RBAC.

Commands That Require Authorizations

The following table provides examples of how authorizations are used to limit command options in the Solaris environment. See also Authorizations.

Chapter 8 Using the 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.

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

• Automated Security Enhancement Tool (ASET)

• Running ASET

• Troubleshooting ASET Problems

Automated Security Enhancement Tool (ASET)

The Solaris 9 release 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 task performs 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 also safeguard a network by applying the basic requirements of a firewall system to a system that serves as a gateway system. (See Firewall Setup.)

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 that notes detected security weaknesses and any 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 ASET cannot correct a potential security problem, it reports the existence of the problem.

You can initiate an ASET session by using the /usr/aset command interactively. Or, you can 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 following table outlines these three levels of security.

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 that were 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 novice administrator, you can refer to other Solaris 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 tasks 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 Tuning

This task sets the permissions on system files to the security level you designate. This task 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. For example of the files that ASET consults when it sets permissions, see Tune Files.

System Files Checks

This task examines system files and compares each file with a description of that file as it is 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 that are 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 and Group Checks

This task checks the consistency and integrity of user accounts and groups as they are defined in the passwd and group files. This task 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 the following:

• /etc/default/login

• /etc/hosts.equiv

• /etc/inetd.conf

• /etc/aliases

• /var/adm/utmpx

• /.rhosts

• /etc/vfstab

• /etc/dfs/dfstab

• /etc/ftpd/ftpusers

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

Environment Variables 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. This task 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. In this situation, each network approaches the other network 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 that are 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 aset -n 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 ASET 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 execution log first shows the system and time that ASET was run. Then, the execution log 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 listing does not indicate that it has been completed. To check the status of the background tasks, use the taskstat command.

ASET Reports

All report files that are generated from ASET tasks are stored 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 convention enables you to keep an orderly trail of records that document 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.

The following figure shows an example of the reports directory structure.

Figure 8–1 Structure of the ASET reports Directory

This example shows two report subdirectories.

• 0124_01:00

• 0125_01:00

The subdirectory names indicate the date and time that 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 that are generated from one execution of ASET.

The latest directory 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 ASET Report Files

Each report file is named after the task that generates it. See the following table 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 accidentally removed or damaged. In such cases, the report file usually contains a message near the end that indicates the reason for the premature termination.

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 ASET Report Files

After you initially run or reconfigure 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 that were introduced when you reconfigured ASET. By watching the reports closely, you can react to, and solve, problems as they arise.

Comparing ASET Report Files

After you monitor the report files for a period during which there are no configuration changes or system updates, you might 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 that share the same user ID (UID). 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 UIDs if these entries are specified in the uid_aliases file.

Avoid having multiple user accounts (password entries) share the same UID. 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. The sharing of UIDs 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 file is /usr/aset/masters/uid_aliases.

The Checklist Files

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

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

• CKLISTPATH_LOW

• CKLISTPATH_MED

• CKLISTPATH_HIGH

ASET Environment File (asetenv)

The environment file, asetenv, contains a list of environment variables that affect ASET tasks. Some of 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 you change 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 the 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 environment variables 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 section to do the following:

• Choose which tasks to run

• Specify the directories for the system files checks task

• Schedule ASET execution

• Specify a UID aliases file

• Extend checks to NIS+ tables

Choose Which Tasks to Run: TASKS

Each task that 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 might decide to eliminate one or more tasks.

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

You can set up ASET to run at the high security 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. To delete a task, remove the task-related environment variable 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.

The following example shows the TASKS list with all of the ASET tasks.

TASKS=”env sysconfig usrgrp tune cklist eeprom firewall”

Specify Directories for System Files Checks Task: CKLISTPATH

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

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 that is defined by an environment variable at a lower security level should be a subset of the directory list that is defined at the next higher level. For example, all directories that are specified for CKLISTPATH_LOW should be included in CKLISTPATH_MED, and all the directories that are specified for CKLISTPATH_MED should be included in CKLISTPATH_HIGH.

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

You can edit these environment 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. 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 UIDs. The default file 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, which disables NIS+ table checking.

To understand how this environment variable works, consider its effect on the passwd file. When set to false, ASET checks the local passwd file. When 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. ASET does not change them.

Modifying the Tune Files

ASET uses the three master tune files, tune.low, tune.med, and tune.high, 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 that are appropriate for default system settings. The tune.med file further restricts these permissions and includes entries that are not present in tune.low. The tune.high file restricts permissions even further.

Modify settings in the tune files 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. This utility also deschedules ASET, if it is currently scheduled for periodic execution. The aset.restore command is located in /usr/aset, the ASET operating directory.

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

You should use the aset.restore command in the following instances:

• 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 previously been added to root's crontab. For instructions 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 feature is not working properly, and you suspect that ASET is causing the problem.

Network Operation With 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 your clients. To facilitate ASET management across several client systems, you can make configuration changes that are applied globally to all clients, which eliminates the need for you to log in to each system to repeat the process.

When you are 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 situation might arise where you want to set up more than one network configuration. For example, you might want to set up one configuration for clients that are designated with low security level, another configuration for those clients with medium level, and yet another configuration 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 configuration 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 by 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 that are produced by tasks that run on various clients. For instructions on setting up a collection mechanism, see How to Collect ASET 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 or not a client has superuser privilege. Alternatively, you can leave the reports directory on the local system when you want users to monitor their own ASET reports.

ASET Environment Variables

The following table lists the ASET environment variables and the values that they specify.

The environment variables that are listed in the following sections 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.

ASETDIR Environment 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 Environment 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 these commands, level can be set to one of the following:

PERIODIC_SCHEDULE Environment 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, with 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 that are joined by a hyphen. A range states that the ASET tasks should be executed for every time that is included in the range.

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

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

PERIODIC_SCHEDULE=”0 0 * * *”    

TASKS Environment 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 Environment 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, where pathname is the full path name of the aliases file.

The default is as follows:

UID_ALIASES=${ASETDIR}/masters/uid_aliases

YPCHECK Environment Variable

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

The default is false, which confines the checking to local system tables:

YPCHECK=false

CKLISTPATH_level Environment Variable

The three checklist path variables list the directories to be checked by the system files checks 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 values of the shell path variables, in that they are lists of directory names that are 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 ASET files, including the tune files and the aliases file.

Tune Files

ASET maintains three tune files. The following table describes the format of entries in all three tune files.

The following rules apply when you edit the tune files:

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

• 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 remains unchanged, because 00777 is always less restrictive than whatever the current setting is.

  This process 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 security levels, additional files are added to the list.

• A file can match more than one tune file entry. For example, etc/passwd matches the 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 the /etc/passwd file 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. In the following example, the owner of /usr/sbin/chroot will be set to root.

  /usr/sbin/chroot 00555 bin bin file /usr/sbin/chroot 00555 root bin file