System users should safeguard their data by using appropriate file and directory permissions in addition to using and guarding their account passwords.
Site administrators, and to some extent system users, should be aware of the following:
- Anyone with physical access to a computer can simply take it or take its disk drives(s).
- The same caveat applies to backups of the system: keep backups in a secure place. Anyone with physical access to backup tapes can gain access to any information stored on them.
- Permissions for directories and files should be set to allow only the necessary access for owner, group, and others. This minimizes the damage that one compromised account can cause.
- There are several ways accounts and passwords protect the system:
- By requiring users to log in with specific accounts, you can determine who is responsible for specific actions on the system.
- Using the IRIX system of file permissions, users can keep data reasonably secure. Other users on the system are less likely to accidentally view confidential material.
- If all accounts have passwords, the chance of an unauthorized person accessing the system is greatly reduced. However, the possibility of unauthorized access increases if users are lax about changing their passwords regularly and choosing good passwords. The next section describes how to choose good passwords.
- All active accounts need passwords, which should be changed regularly. Do not use obvious passwords, and do not store them online in "plain-text" format. If you must write them down on paper, store them in a safe place.
For information about choosing passwords, see "Choosing Passwords".
- Common-use accounts are a potential security hole. An example of a common-use account is one that is shared by all members of a department or work group. Another example is a standard "guest" account on all the workstations at a site. This allows all users at the site access to different workstations without requiring specific accounts on each workstation.
A pitfall of common-use accounts is that you cannot tell exactly who is responsible for the actions of the account on any given workstation. Another risk is that anyone trying to break into workstations at your site will try obvious account names such as guest.
Common-use accounts can be helpful, but be aware that they can pose serious security problems. Needless to say, common-use accounts that do not have passwords are especially risky.
- Accounts that are no longer used should be either locked or backed up and removed, since unused accounts can be compromised as easily as current accounts.
Also, change critical passwords, including dialup passwords, whenever anyone leaves the organization. Former employees should not have access to workstations at the site.
- Systems with dialup ports should have special dialup accounts and passwords. This is very important for sites that have common-use accounts, as discussed above. Refer to the discussion on /etc/d_passwd in "Second (Dialup) Passwords".
However, even with this added precaution, do not store sensitive data on workstations that have dial-up access.
- If your site allows access to the Internet network (for example, using ftp(1C)), take precautions to isolate access to a specific gateway workstation. Refer to "Network Security and Firewalls" for details on connecting to external networks.
- Discourage use of the su(1) command unless absolutely necessary. The su command allows a user to change his or her user ID to that of another user. It is sometimes legitimately necessary to use su to access information owned by another user, but this presents an obvious temptation: the person using su to switch user IDs must know another person's password and therefore has full access to his or her account.
Note: The file /var/adm/sulog contains a log of all successful and unsuccessful attempts to use the su command (if it is enabled in /etc/default su).
- Make sure that each user's home account, and especially the shell-startup files .profile, or .login and .cshrc, are writable only by that user. This ensures that "trojan horse" programs are not inserted in a user's login files. (A trojan horse program is a file that appears to be a normal file, but in fact causes damage when invoked by a legitimate user.)
- Be sure that system directories such as / (root), /bin, /usr/bin, and /etc and the files in them are not writable except by the owner. This also prevents trojan horse attacks.
- If you must leave your console, workstation, or terminal unattended, log off the system. This is especially important if you are logged in as root. Also, refer to the xlock(1) reference page for information on locking your local X display.
- Sensitive data files should be encrypted. The crypt(1) command, together with the encryption capabilities of the editors (ed and vi), provides some protection for sensitive information.
- Use only that software that is provided by reputable manufacturers. Be wary of programs that are distributed "publicly," especially already-compiled binaries. Programs that are available on public bulletin board systems (as opposed to BBSs run and sponsored by vendors) and on public computer networks could contain malicious "worm" routines that can violate system security and cause data loss.
Public-domain source code is safer than already-compiled programs, but only if you examine the code thoroughly before compiling it. Be suspicious of programs that must be installed with set-UID root in order to run.
- Safeguard and regularly check your network hardware. One possible way to break into computer systems is to eavesdrop on network traffic using physical taps on the network cable. Taps can be physical connections (such as a vampire tap) or inductive taps.
Run networking cable through secure areas and make sure it is easy to examine regularly. Create and maintain a hard copy map of the network to make it easier to spot unauthorized taps. Another way to make this sort of attack less likely is to use fiber-optic (FDDI) network hardware, which is much more difficult to tap. For details on configuring network software securely, refer to Chapter 5.
System security under IRIX is primarily dependent on system login accounts and passwords. Proper administration, user education, and use of the facilities provided yield adequate security for most sites. Most security breaches are the result of human error and improper use of the provided security features.