|
|
System SecurityObjective: 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:
The following sections describe these facets of security. Controlling Physical SecurityPhysical 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 AccessControlling 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.
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. Additional controls have been added to Solaris 10 that can be set in the /etc/default/passwd file and are as follows:
Complexity of the password can be controlled using the following parameters:
Note 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:
Note 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:
Where User Account Information Is StoredWhen 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: <username>:<password>:<uid>:<gid>:<comment>:<home-directory>:<login-shell>Table 4.14 defines the fields in the /etc/passwd file.
Each line in the /etc/shadow file contains several fields, separated by colons (:). The lines in the /etc/shadow file have the following syntax: <username>:<password>:<lastchg>:<min>:<max>:<warn>:<inactive>:<expire>Table 4.15 defines the fields in the /etc/shadow file.
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:
Each line in the /etc/group file contains several fields, separated by colons (:). The lines in the /etc/group file have the following syntax: <group-name>:<group-password>:<gid>:<user-list>Table 4.16 defines the fields in the /etc/group file.
Note 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:
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: #groups 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 ShellsSystem 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:
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. Note 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 AccessObjective: 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.
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.
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.
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 GIDsThe 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 MaskWhen 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 BitsThe 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.
|
|
|