
sun.com \| docs.sun.com	How To Buy \| My Sun \| Worldwide Sites

Previous Contents Index Next Next

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.

Initial Password Algorithm	Changed Password Algorithm	Explanation
`crypt_bsdmd5`	`crypt_bsdmd5`	The identifier of `crypt_bsdmd5` is `1`, the value of `CRYPT_DEFAULT`. The user's password continues to be encrypted with the `crypt_bsdmd5` algorithm.
`crypt_bsdbf`	`crypt_bsdbf`	The identifier of `crypt_bsdbf` is `2a`. Because `2a` is in the `CRYPT_ALGORITHMS_ALLOW` list, the new password is encrypted with the `crypt_bsbdf` algorithm.
`crypt_md5`	`crypt_md5`	The identifier of `crypt_md5` is `md5`. Because `md5` is in the `CRYPT_ALGORITHMS_ALLOW` list, the new password is encrypted with the `crypt_md5` algorithm.
`crypt_unix`	`crypt_bsdmd5`	The identifier of `crypt_unix` is `__unix__`. The `__unix__` identifier is not in the `CRYPT_ALGORITHMS_ALLOW` list. Therefore, the `crypt_unix` algorithm cannot be used. The new password is encrypted with the `CRYPT_DEFAULT` algorithm.

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.

Table 2-2 System Logins

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

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.