Previous Page
Next Page

System Security


Restrict access to data in files through the use of group membership, ownership, and special file permissions.

In addition to setting up user accounts, keeping the system's information secure is one of a system administrator's primary tasks. System security involves protecting data against loss due to a disaster or system failure. In addition, the system administrator must protect systems from the threat of unauthorized access and protect data on the system from unauthorized users. Bad disasters often come from authorized personneleven system administratorsdestroying data unintentionally. Therefore, the system administrator is presented with two levels of security: protecting data from accidental loss and securing the system against intrusion or unauthorized access.

The first scenarioprotecting data from accidental lossis easy to achieve with a full system backup scheme that you run regularly. Regular backups provide protection in the event of a disaster. If a user accidentally destroys data, if the hardware malfunctions, or if a computer program simply corrupts data, you can restore files from the backup media. (Backup and recovery techniques are covered in Chapter 7, "Performing System Backups and Restorations.")

The second form of securitysecuring the system against intrusion or unauthorized accessis more complex. This book cannot cover every security hole or threat, but it does discuss Unix security fundamentals. Protection against intruders involves the following:

  • Controlling physical security You need to limit physical access to the computer equipment.

  • Controlling system access You need to limit user access via passwords and permissions.

  • Controlling file access You need to limit access to data by assigning file access permissions.

  • Auditing users You need to monitor user activities to detect a threat before damage occurs.

  • Controlling network security You need to protect against access through phone lines, serial lines, or the network.

  • Securing superuser access You need to reserve superuser access for system administrator use only.

The following sections describe these facets of security.

Controlling Physical Security

Physical security is simple: You need to lock the door. You should limit who has physical access to the computer equipment to prevent theft or vandalism. In addition, you should limit access to the system console. Anyone who has access to the console ultimately has access to the data. If the computer contains sensitive data, you need to keep it locked in a controlled environment with filtered power and adequate protection against fire, lightning, flood, and other disasters. You should restrict access to protect against tampering with the system and its backups. Anyone with access to the backup media could steal it and access the data. Furthermore, if a system is logged in and left unattended, anyone who can use that system can gain access to the operating system and the network. You need to make sure your users log out or lock their screens before walking away. In summary, you need to be aware of your users' computer surroundings, and you need to physically protect them from unauthorized access.

Controlling System Access

Controlling access to systems involves using passwords and appropriate file permissions. To control access, all logins must have passwords, and those passwords must be changed frequently. Password aging is a system parameter that you set to require users to change their passwords after a certain number of days. Password aging lets you force users to change their passwords periodically or prevent users from changing their passwords before a specified interval. You can set an expiration date for a user account to prevent an intruder from gaining undetected access to the system through an old and inactive account. For a high level of security, you should require users to change their passwords periodically (for example, every six weeks or every three months for lower levels of security). You should change system administration passwords (such as root and any other user who has administrative privileges through an RBAC account) monthly or whenever a person who knows the root password leaves the company or is reassigned. Each user should have his or her own account, and no user should disclose his or her password to anyone else.

Several files that control default system access are stored in the /etc/default directory. Table 4.12 describes a few of the files in the /etc/default directory.

Table 4.12. Files in the /etc/default Directory




Controls the default policy on password aging.


Controls system login policies, including the policy on root access. The default is to limit root access to the console.


Specifies where attempts to use su to become root are logged and where those log files are located. This file also specifies whether attempts to use su to become root are displayed on a named device (such as a system console).

You can set default values in the /etc/default/passwd file to control user passwords. Table 4.13 lists the options that can be controlled through the /etc/default/passwd file.

Table 4.13. Flags in /etc/default/passwd




Specifies the maximum time period for which a password is valid.

The MAXWEEKS value can be overridden by entries in the /etc/shadow file.


Specifies the minimum time period before the password can be changed.

The MINWEEKS value can be overridden by entries in the /etc/shadow file.


Specifies a minimum password length for all regular users. The value can be 6, 7, or 8.


Specifies a time period after which the system warns of the password's expiration date. This entry does not exist in the file by default, but it can be added.

The WARNWEEKS value can be overridden by entries in the /etc/shadow file.

Additional controls have been added to Solaris 10 that can be set in the /etc/default/passwd file and are as follows:


Sets the password controls to verify that the user is not using the login name as a component of the password.


HISTORY can have a value from 026. Setting a value higher than 0 forces the passwd program to log up to 26 changes to the user's password. The value entered specifies the number of changes to log preventing a user from reusing the same password for up to 26 changes. When the HISTORY value is set to zero (0), the password log for all users will be removed the next time a user changes his password. No password history will be checked if the flag is not present or has zero value.


Causes the passwd program to perform dictionary word lookups.


The location of the dictionary where the generated dictionary databases reside. This directory must be created manually.

Complexity of the password can be controlled using the following parameters:


The old and new passwords must differ by at least the MINDIFF value.


Password must contain at least this number of alpha characters.


Password must contain at least this number of uppercase characters.


Password must contain at least this number of lowercase characters.


The password must not contain more consecutively repeating characters than specified by the MAXREPEATS value.


Password must contain at least this number of special characters.


Password must contain at least this number of digits.


Describes the same character classes as MINDIGIT and MINSPECIAL combined; therefore you cannot specify both MINNONALPHA and MINSPECIAL (or MINDIGIT). You must choose which of the two options to use.


Determines whether whitespace characters are allowed.


Privileged users, such as root, are not forced to comply with password aging and password construction requirements. A privileged user can create a null password by entering a carriage return in response to the prompt for a new password. Therefore privileged users should be extra vigilant not to use bad (that is, easy to guess) passwords.

As a system administrator, your job is to ensure that all users have secure passwords. A system cracker can break weak passwords and put an entire system at risk. You should 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.

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

  • Mix upper- and lowercase characters.

  • The password must not contain any sequences of four or more letters (regardless of how you capitalize them) that can be found in a dictionary. Also, reversing the order of the letters doesn't do any good because a standard way of cracking a password is to try all the words in a dictionary, in all possible upper-/lowercase combinations, both forward and backward. Prefixing and/or appending a numeral or punctuation character to a dictionary word doesn't help either; on a modern computer, it doesn't take too long to try all those possible combinations, and programs exist (and are easy to get) to do exactly that.

  • Use a password that is easy to remember, so you don't have to write it down. Never write down a password or email or give your password to anyone! You should be able to type it quickly, without having to look at the keyboard. This makes it harder for someone to steal your password by watching over your shoulder.

  • Nonsense words made up of the first letter of every syllable in a phrase, such as swotrb for "Somewhere Over the Rainbow," work well for a password. Choose two short words and concatenate them together with a punctuation character between them (for example, dog;rain, book+mug, kid?goat).


Dictionaries and Password Cracking Be aware that in addition to the standard American or English dictionaries, there are also crackers' dictionaries. These are collections of common computer terms and phrases, names, slang and jargon, easily typed key sequences (such as asdfg and 123456), and commonly used phrases that one might be tempted to use for a password. These crackers' dictionaries are frequently updated and shared; programs to crack passwords are distributed with copies of these dictionaries.

The following are poor choices for passwords:

  • Proper nouns, names, login names, and other passwords that a person might guess just by knowing something about the user.

  • The user's nameforward, backward, or jumbled.

  • Names of the user's family members or pets.

  • Information that is easily obtained about you, such as the following:

    Car license plate numbers

    Telephone numbers

    Social Security numbers

    Employee numbers

  • Names related to a hobby or an interest.

  • Seasonal themes, such as Santa in December.

  • Any word in the dictionary (English or foreign language).

  • Simple keyboard patterns (such as asdfgh).

  • Passwords the user has used previously.

  • A password with fewer than six characters.

  • A password of all digits, or all the same letter. This significantly decreases the search time for a cracker.

Where User Account Information Is Stored

When no network name service is used, user account and group information is stored in files located in the /etc directory. Even when you're using a name service, these local files still exist in the /etc directory, but most of the account information is stored in the name server's database. Refer to Chapter 12 for more information.

Most user account information is stored in the /etc/passwd file; however, password encryption and password aging details are stored in the /etc/shadow file. Only root can view the /etc/shadow file. Group information is stored in the /etc/group file. Users are put together into groups based on their file access needs; for example, the acctng group might be users in the Accounting Department.

Each line in the /etc/passwd file contains several fields separated by colons (:), and each line is formatted as follows:


Table 4.14 defines the fields in the /etc/passwd file.

Table 4.14. Fields in the /etc/passwd File




Contains the user or login name. A username should be unique and should consist of one to eight letters (AZ, az) and numerals (09), but no underscores or spaces. The first character must be a letter, and at least one character must be a lowercase letter.


Contains an x, which is a placeholder for the encrypted password that is stored in the /etc/shadow file and that is used by the pwconv command, which is described later in this section.


Contains a UID number that identifies the user to the system. UID numbers for regular users should range from 100 to 60,000, but they can be as high as 2,147,483,647.

All UID numbers should be unique. UIDs lower than 100 are reserved. To minimize security risks, you should avoid reusing UIDs from deleted accounts.


Contains a GID number that identifies the user's primary group. Each GID number must be a whole number between 0 and 60,000 (60,001 and 60,002 are assigned to nobody and noaccess, respectively). GIDs can go as high as 2,147,483,647, but GIDs higher than 60,002 might not be supported across other Unix platforms. GID numbers lower than 100 are reserved for system default group accounts.


Usually contains the user's full name.


Contains the user's home directory pathname.


Contains the user's default login shell.

Each line in the /etc/shadow file contains several fields, separated by colons (:). The lines in the /etc/shadow file have the following syntax:


Table 4.15 defines the fields in the /etc/shadow file.

Table 4.15. Fields in the /etc/shadow File




Specifies the user or login name.


Might ontain one of the following entries: a 13-character encrypted user password; the string *LK*, which indicates an inaccessible (locked) account; or the string NP, which indicates no valid password on the account and you cannot login directly to this account.


Indicates the number of days between January 1, 1970, and the last password modification date.


Specifies the minimum number of days required between password changes.


Specifies the maximum number of days the password is valid before the user is prompted to specify a new password.


Specifies the number of days that a user account can be inactive before it is locked.


Specifies the absolute date when the user account expires. Past this date, the user cannot log in to the system.

You should refrain from editing the /etc/passwd file directly, and you should never edit the /etc/shadow file directly. Any incorrect entry can prevent you from logging in to the system. These files are updated automatically, using one of the Solaris account administration commands or the SMC, as described earlier in this chapter.

If you must edit the /etc/passwd file manually, you should use the pwck command to check the file. The pwck command scans the password file and notes any inconsistencies. The checks include validation of the number of fields, login name, UID, GID, and whether the login directory and the program to use as shell exist.

Some experienced system administrators edit the /etc/passwd file directly for various reasons, but only after creating a backup copy of the original /etc/passwd file. (Chapter 12 describes this procedure.) For example, you might want to restore an /etc/passwd file from backupperhaps because the original was corrupted or was incorrectly modified.

Use the /usr/ucb/vipw command to edit the /etc/passwd file. /usr/ucb/vipw edits the password file while setting the appropriate locks, and does any necessary processing after the password file is unlocked. If the password file is already being edited, you will be told to try again later. /usr/ucb/vipw also performs a number of consistency checks on the password entry for root and will not allow a password file with a "mangled" root entry to be installed. It also checks the /etc/shells file to verify that a valid login shell for root has been defined.

After modifying the /etc/passwd file, you run the pwconv command. This command updates the /etc/shadow file with information from the /etc/passwd file.

The pwconv command relies on the special value of x in the password field of the /etc/passwd file. The x indicates that the password for the user already exists in the /etc/shadow file. If the /etc/shadow file does not exist, pwconv re-creates everything in it from information found in the /etc/passwd file. If the /etc/shadow file does exist, the following is performed:

  • Entries that are in the /etc/passwd file and not in the /etc/shadow file are added to the shadow file.

  • Entries that are in the /etc/shadow file and not in the /etc/passwd file are removed from the shadow file.

Each line in the /etc/group file contains several fields, separated by colons (:). The lines in the /etc/group file have the following syntax:


Table 4.16 defines the fields in the /etc/group file.

Table 4.16. Fields in the /etc/group File




Contains the name assigned to the group. For example, members of the Accounting Department group might be called acct. A group name can have a maximum of nine characters.


Usually contains an asterisk or is empty. See the information on the newgrp command in the section "Effective UIDs and GIDs," later in this chapter.


Contains the group's GID number, which must be unique on the local system and should be unique across the entire organization. Each GID number must be a whole number between 0 and 60,002, but it can be as high as 2,147,483,647. However, GIDs above 60,002 might not be supported on some Unix platforms. Numbers lower than 100 are reserved for system default group accounts, so don't use them. User-defined groups can range from 100 to 60,000 (60,001 and 60,002 are reserved and assigned to nobody and noaccess, respectively).


Contains a list of groups and a comma-separated list of usernames that represent the user's secondary group memberships. Each user can belong to a maximum of 16 secondary groups.


UID Values Earlier Solaris software releases use 32-bit data types to contain the GIDs, but GIDs are constrained to a maximum useful value of 60,000. Starting with Solaris 2.5.1 and compatible versions, the limit on GID values has been raised to the maximum value of a signed integer, or 2,147,483,647. GIDs greater than 60,000 do not have full functionality and are incompatible with many Solaris features, so you should avoid using them.

By default, all Solaris 10 systems have default groups already defined in the /etc/group file. Those entries are outlined in Table 4.17:

Table 4.17. Default Group File Entries




Super user group


Optional group


Administrative group associated with running system binaries


Administrative group associated with system logging or temporary directories


Administrative group associated with system logging


Group associated with uucp functions


Electronic mail group


Group associated with tty devices


Line printer group


Group associated with uucp functions


General administrative group


Group associated with routine system tasks


Administrative group associated with legacy Admintool and Solstice AdminSuite tools


Daemon for Sendmail message submission program


Group reserved for the GNOME Display Manager daemon


Group reserved for WebServer access


Group assigned for anonymous NFS access


Group assigned to a user or a process that needs access to a system through some application but without actually logging in


Group assigned to a user who is not a member of a known group

Other than the staff group, you should not use these groups for users. Also, some system processes and applications might rely on these groups, so you should not change the GIDs or remove these groups from the /etc/group file unless you are absolutely sure of the effect on the system.

If you edit the /etc/group file manually, you should use the grpck command to verify all entries in the group file. This verification includes a check of the number of fields, the group name, and the GID, as well as a check to ensure that all login names appear in the password file.

A user can display the list of groups that they belong to by typing the groups command as follows:


Their primary and secondary groups are listed as follows:

root other bin sys adm uucp mail tty lp nuucp daemon

A user can change their primary group using the newgrp command as follows:

# newgrp other

The root user has changed his or her primary group from root to other as displayed by the id command:

# id
uid=0(root) gid=1(other)

Restricted Shells

System administrators can use restricted versions of the Korn shell (rksh) and the Bourne shell (rsh) to limit the operations allowed for a particular user account. Restricted shells are especially useful for ensuring that time-sharing users and users' guests on a system have restricted permissions during login sessions. When an account is set up with a restricted shell, users cannot do the following:

  • Change directories to a directory above their home directory

  • Set the $PATH variable

  • Specify path or command names that begin with /

  • Redirect output

You can also provide users with shell procedures that have access to the full power of the standard shell but that impose a limited menu of commands.


Don't Confuse rsh You should not confuse the restricted shell /usr/lib/rsh with the remote shell /usr/bin/rsh. When you specify a restricted shell, you should not include the following directories in the user's path/bin, /sbin, or /usr/bin. Doing so allows the user to start another shell (a nonrestricted shell).

Controlling File Access


Restrict access to data in files through the use of group membership, ownership, and special file permissions.

After you have established login restrictions, you need to control access to the data on the system. Some users only need to look at files; others need the ability to change or delete files. You might have data that you do not want anyone else to see. You control data access by assigning permission levels to a file or directory.

Three levels of access permission are assigned to a Unix file to control access by the owner, the group, and all others. You display permissions by using the ls -la command. The following example shows the use of the ls -la command to display permissions on files in the /users directory:

ls -la    /users

The system responds with this:

drwxr-xr-x   2  bill   staff   512     Sep 23 07:02          .
drwxr-xr-x   3  root   other   512     Sep 23 07:02          ..
-rw-r--r--   1  bill   staff   124     Sep 23 07:02          .cshrc
-rw-r--r--   1  bill   staff   575     Sep 23 07:02          .login

The first column of information displays the type of file and its access permissions for the user, group, and others. The r, w, x, and - symbols are described in Table 4.18. The third column displays the owner of the fileusually the user who created the file. The owner of a file (and the superuser) can decide who has the right to read it, to write to it, andif it is a commandto execute it. The fourth column displays the group to which this file belongsnormally the owner's primary group.

Table 4.18. File Access Permissions



Means That Designated Users...



Can open and read the contents of a file.



Can write to the file (that is, modify its contents), add to it, or delete it.



Can execute the file (if it is a program or shell script).



Cannot read, write to, or execute the file.

When you list the permissions on a directory, all columns of information are the same as for a file, with one exception. The r, w, x, and - found in the first column are treated slightly different for a directory than for a file, as described in Table 4.19.

Table 4.19. Directory Access Permissions



Means That Designated Users...



Can list files in the directory.



Can add files or links to or remove files or links from the directory.



Can open or execute files in the directory and can make the directory and the directories beneath it current.



Cannot read, write, or execute.

You use the commands listed in Table 4.20 to modify file access permissions and ownership, but you need to remember that only the owner of the file or root can assign or modify these values.

Table 4.20. File Access Commands




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.


Changes the ownership and optionally the group ownership of a file.


Changes the group ownership of a file.

Use the chmod command to change the permissions on a file to rwxrwxrwx as follows:

chmod rwxrwxrwx <filename>

Use the chown command to change the ownership on a file to bcalkins as follows:

chown bcalkins <filename>

Use the chgrp command to change group ownership of a file to engrg as follows:

chgrp engrg <filename>

The chown command can be used to change both the user and group ownership of a file as follows:

chown bcalkins:engrg <filename>

Sometimes you don't have access to a file or directory if you use your current login and you want to switch from one login ID to another. As long as you know the login name and password, you can quickly switch to that login by using the su command, which is described in the following section.

Effective UIDs and GIDs

The su (switch user) command enables a user to become another user without logging off the system. To use the su command, you must supply the password for the user you are attempting to log in as. The root user can run su to any account without being prompted for passwords.

System administrators often use the su command. For example, as a safety precaution, rather than using the root account as a regular login, you might use a regular, nonroot login whenever you are not performing administration functions. When root access is required, you can quickly become the superuser by using the su command. When you are finished performing the task, you can exit the superuser account and continue working using your normal, nonroot account.

If the user enters the correct password, su creates a new shell process, as specified in the shell field of the /etc/passwd file for that particular user. In the following example, user1 runs the su command to become user2:

su user2

An option to the su command is -. This option specifies a complete login. The specified user's .profile file is run, and the environment is changed to what would be expected if the user actually logged in as the specified user.

Without the - option, the environment is passed along from the original login, with the exception of $PATH, which is controlled by PATH and SUPATH in the /etc/default/su file (which is described later in this chapter). When the administrator uses su to access the root account from an untrusted user's account, the - option should always be used. If it is not used, the administrator is logged in as root, using a PATH variable defined for a nonroot user. This could result in the administrator inadvertently running commands specified in the user's shell initialization files.

A user can also switch his or her primary group by using the newgrp command. The newgrp command logs a user in to a new group by changing a user's real and effective GIDs. The user remains logged in, and the current directory is unchanged. The execution of su and newgrp always replaces the current shell with a new shell. The execution of newgrp always replaces the current shell with a new shell, even if the command terminates with an error (unknown group). Any variable that is not exported is reset to null or its default value. Exported variables retain their values.

With no operands and options, newgrp changes the user's real and effective GIDs back to the primary group specified in the user's password file entry.

A password is demanded if the group has a password (in the second field of the /etc/group file), the user is not listed in /etc/group as being a member of that group, and the group is not the user's primary group. The only way to create a password for a group is to use the passwd command and then cut and paste the password from /etc/shadow to /etc/group. Group passwords are antiquated and not often used.

The Default User Mask

When a user creates a file or directory, the user mask controls the default file permissions assigned to the file or directory. The umask command should set the user mask in the /etc/default/login file or a user initialization file, such as /etc/profile or .cshrc. You can display the current value of the user mask by typing umask and pressing Enter.

The user mask is set with a three-digit octal value, such as 022. The first digit of this value sets permissions for the user, the second sets permissions for the group, and the third sets permissions for others. To set the user mask to 022, you type the following:

umask 022

By default, the system sets the permissions on a file to 666, granting read and write permission to the user, group, and others. The system sets the default permissions on a directory or executable file to 777, or rwxrwxrwx. The value assigned by umask is subtracted from the default. To determine what umask value you want to set, you subtract the value of the permissions you want from 666 (for a file) or 777 (for a directory). The remainder is the value to use with the umask command. For example, suppose you want to change the default mode for files to 644 (rw-r--r--). The difference between 666 and 644 is 022, so you would use this value as an argument to the umask command.

Setting the umask value has the effect of granting or denying permissions in the same way that chmod grants them. For example, the command chmod 644 denies write permission to the group, while others, such as umask 022, deny write permission to the group and others.

Sticky Bits

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 root. This prevents a user from deleting other users' files from public directories. A t or T in the access permissions column of a directory listing indicates that the sticky bit has been set, as shown here:

drwxrwxrwt   5 root     sys          458 Oct 17 23:04 /tmp

You use the chmod command to set the sticky bit. The symbols for setting the sticky bit by using the chmod command in symbolic mode are listed in Table 4.21.

Table 4.21. Sticky Bit Modes




Sticky bit is on; execution bit for others is on.

Previous Page
Next Page