User and Security Administration

Use the Solaris Management Console (SMC) GUI or the command line to create and manage user accounts.

Table 10 describes field entries you'll need to know when setting up a new user account using SMC.

Table 10. Add User Fields

Item	Description
User Name	Enter a unique login name that will be entered at the Solaris login prompt.
User ID	Enter the unique user ID (UID). SMC automatically assigns the next available UID; however, in a networked environment, make sure this number is not duplicated by another user on another system.
Primary Group	Enter the primary group name or GID (group ID) number for the group to which the user will belong.
Full Name/Description	These two fields are comment fields and are optional. Enter any comments such as the full username or phone number.
Password	Click this button to specify the password status. Selectable options are as follows: User Must Set Password at First Login This is the default. The account does not have a password assigned. The user is prompted for a password on first login, unless passreq=no is set in /etc/default/login. User Must Use This Password at First Login The account will have a password that you set in advance.
Path	This will be the location of the user's home directory and where his or her personal files will be stored.

Another way to manage user accounts is from the command line. Although using the command line is more complex than using the SMC GUI, the command line provides a little more flexibility. Solaris supplies the user administration commands described in Table 11 for setting up and managing user accounts.

Table 11. Account Administration Commands

Command	Description
useradd	Adds a new user account
userdel	Deletes a user account
usermod	Modifies a user account
groupadd	Adds a new group
groupmod	Modifies a group (for example, changes the group ID or name)
groupdel	Deletes a group
smuser	The command line equivalent of the SMC GUI tool that manages one or more user entries in the local /etc files, NIS, or NIS+ name service
smgroup	The command line equivalent of the SMC GUI tool that manages one or more group definitions in the group database for the local /etc files, NIS, or NIS+ name service

Shells and Initialization Files

The Solaris 10 operating environment offers five commonly used shells:

• The Bourne shell (/sbin/sh) The default shell. It is a command programming language that executes commands read from a terminal or a file.

• The C shell (/bin/csh) A command interpreter with a C-like syntax. The C-shell provides a number of convenient features for interactive use that are not available with the Bourne shell, including filename completion, command aliasing, and history substitution.

• The TENEX C shell (/bin/tcsh) An enhanced version of the C shell with complete backward compatibility. The enhancements are mostly related to interactive use, including the ability to use arrow keys for command history retrieval and command-line editing.

• The Korn shell (/bin/ksh) A command programming language that executes commands read from a terminal or a file.

• The Bourne Again shell (/bin/bash) Bash is a sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh).

The login shell is the command interpreter that runs when you log in. The Solaris 10 operating environment offers the three most commonly used shells, as described in Table 12.

Table 12. Basic Features of the Bourne, C, and Korn Shells

Feature	sh	csh	tcsh	ksh	bash
Syntax compatible with sh	Yes	No	No	Yes	Yes
Job control	Yes	Yes	Yes	Yes	Yes
History list	No	Yes	Yes	Yes	Yes
Command-line editing	No	Yes	Yes	Yes	Yes
Aliases	No	Yes	Yes	Yes	Yes
Protect files from overwriting	No	Yes	Yes	Yes	Yes
Ignore Ctrl+D (ignoreeof)	No	Yes	Yes	Yes	Yes
Enhanced cd	No	Yes	Yes	Yes	Yes
Initialization file separate	No	Yes	Yes	Yes	Yes
Logout file	No	Yes	Yes	No	Yes
Functions	Yes	No	No	Yes	Yes
Arrow keys for command edits	No	No	Yes	No	Yes

The logout file functionality can be implemented with the use of a trap statement in /etc/profile:

trap 'test -f $HOME/.shlogout && . $HOME/.shlogout' EXIT

A shell initialization file is a shell script that runs automatically each time the user logs in. The initialization file will set up the work environment and customize the shell environment for the user.

C shell initialization files run in a particular sequence after the user logs in to the system. For the C shell and tcsh, initialization files are run in the following sequence:

Bourne shell initialization files run in a particular sequence after the user logs in to the system. For the Bourne shell, initialization files are run in the following sequence:

Korn shell initialization files run in a particular sequence after the user logs in to the system. For the Korn shell, initialization files are run in the following sequence:

Bash initialization files run in a particular sequence after the user logs in to the system. For the Bash shell, initialization files are run in the following sequence:

The Solaris 10 system software provides default user initialization files for each shell in the /etc/skel directory on each system. These files are listed in Table 13.

Table 13. Default Initialization Files

Name	Description
local.cshrc	The default .cshrc file for the C shell
local.login	The default .login file for the C shell
local.profile	The default .profile file for the Bourne and Korn shells

System Security

Protecting your system against unauthorized access or modification begins with controlling access to your system. Several files that control default system access are stored in the /etc/default directory. Table 14 summarizes the files in the /etc/default directory.

Table 14. Files in the /etc/default Directory

Filename	Description
/etc/default/passwd	Controls default policy on password aging.
/etc/default/login	Controls system login policies, including root access. The default is to limit root access to the console.
/etc/default/su	Specifies where attempts to su to root are logged and where these log files are located. The file also specifies whether attempts to su to root are displayed on a named device (such as a system console).

Controlling access to systems also involves using passwords and appropriate file permissions. Enforce the following guidelines on passwords:

• Passwords should contain a combination of six to eight letters, numbers, or special characters. Don't use fewer than six characters.

• Mix upper- and lowercase characters.

• Use a password with nonalphabetic characters, such as numerals or punctuation.

• Do not use words from a dictionary or easy-to-guess words.

Most of the user account information is stored in the /etc/passwd file; however, password encryption and password aging details are stored in the /etc/shadow file. Group information is stored in the /etc/group file.

Protecting Data

System security also involves protecting your data using standard Unix file permissions. File access permissions are shown by the ls -la command. The first column returned describes the type of file and its access permissions for the user, group, and others using letters. The r, w, and x are described in Table 15.

Table 15. File Access Permissions

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

When listing the permissions on a directory, all columns of information are the same as for a file, with one exception. The r, w, and x found in the first column are treated slightly differently than for a file. These are described in Table 16.

Table 16. Directory Access Permissions

Symbol	Permission	Means That Designated Users...
r	Read	Can list files in the directory.
w	Write	Can add or remove files or links in the directory.
x	Execute	Can open or execute files in the directory. Also can make the directory and the directories beneath it current.
-	Denied	Do not have read, write, or execute privileges.

Use the commands listed in Table 17 to modify file access permissions and ownership, but remember that only the owner of the file or root can assign or modify these values.

Table 17. File Access Commands

Command	Description
chmod	Changes access permissions on a file. You can use either symbolic mode (letters and symbols) or absolute mode (octal numbers) to change permissions on a file.
chown	Changes the ownership of a file.
chgrp	Changes the group ownership of a file.

When a user creates a file or directory, the user mask controls the default file permissions assigned to the file or directory and is set using the umask command.

Access Control Lists (ACLs)

ACLs (pronounced ackls) can provide greater control over file permissions when the traditional Unix file protection in the Solaris operating system is not enough. An ACL provides better file security by enabling you to define file permissions for the owner, owner's group, others, specific users and groups, and default permissions for each of these categories. The following are commands used to set and modify ACL entries:

• setfacl Set, modify, or delete ACL entries on a file

• getfacl Display or copy the ACL entry on a file

Monitoring Users

As the system administrator, you'll need to monitor system resources and watch for unusual activity. Having a method to monitor the system is useful when you suspect a breach in security. The following commands are used to monitor users and system activity:

logins	A command to monitor a particular user's activities.
loginlog	A file that contains one entry for each failed login attempt.
who	Shows who is logged into the system. who lists the login account name, terminal device, login date and time, and where the user logged in.
whodo	Displays each user logged in and the active processes owned by that user. The output shows the date, time, and machine name. For each user logged in, the system displays the device name, UID, and login time, followed by a list of active processes associated with the UID.
last	Displays the sessions of the specified users and terminals in chronological order. For each user, last displays the time when the session began, the duration of the session, and the terminal where the session took place.

Network Security

It is critical to turn off all unneeded network services because many of the services run by inetd, such as rexd, pose serious security threats. rexd is the daemon responsible for remote program execution. On a system connected to the rest of the world via the Internet or other public network, this could create a potential entry point for a hacker. TFTP should absolutely be disabled if you don't have diskless clients using it. Most sites will also disable Finger so that external users can't figure out the usernames of your internal users. Everything else depends on the needs of your site.

Solaris 10's File Transfer Protocol (FTP) is a common tool for transferring files across the network. Although most sites leave FTP enabled, you need to limit who can use it. Solaris 10 contains a file named /etc/ftpd/ftpusers that is used to restrict access via FTP. The /etc/ftpd/ftpusers file contains a list of login names that are prohibited from running an FTP login on the system.

The /etc/hosts.equiv file contains a list of trusted hosts for a remote system and can present a potential security risk. When an entry for a host is made in /etc/hosts.equiv, such as the sample entry for system1, this means that the host is trusted and so is any user at that machine. If the username is also mentioned, as in the second entry in the same file, the host is trusted only if the specified user is attempting access. A single line of + in the /etc/hosts.equiv file indicates that every known host is trustedthis should never be used.

The $HOME/.rhosts file is the user equivalent of the /etc/hosts.equiv file, except any user can create an $HOME/.rhosts file granting access to whomever the user chooseswithout the system administrator's knowledge. The system administrator should disallow the use of .rhosts filesor even better, disable all R services.

It is recommended that you use the secure shell (ssh) when establishing communication between two hosts over insecure networks such as the Internet. The secure shell is much safer than previous methods used to access remote systems such as rlogin, rsh, and rcp. The secure shell daemon (sshd) listens for connections and handles the encrypted authentication exchange between two hosts. When authentication is complete, the user can execute commands and copy files remotely and securely.

Restricting Root Access

Root access needs to be safeguarded against unauthorized use. You should assume that any intruder is looking for root access. You can protect the superuser account on a system by restricting access to a specific device through the /etc/default/login file. In the /etc/default/login file, you can control where root is able to log in by assigning one of the following values to the variable named CONSOLE:

CONSOLE=/dev/console	Root is only allowed to login from the console device.
CONSOLE=	With no value defined, root cannot log in from anywhere, not even from the console.

Users can still log in using a non-root login and issue the su command to switch from being a user to being root, but this activity is logged in the file /var/adm/sulog. The sulog file lists all uses of the su commandnot only those used to switch from being a user to being superuser.