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. No extra measures yield more security if the basic features are not used or are compromised by user actions. Also, periodically log in with anonymous FTP to sgigate.sgi.com and look in the directory ~ftp/security for any security patches for your system.
This chapter deals with maintaining security in a work group environment. Security is up to both administrators and users — it starts with your own local system. Once you have initially established the security of a system, you can expand your secure area to include the network. But until you have local security, there is no point in trying to establish security over a larger area.
The most important concept in security is that security is a dynamic process, requiring that you understand the issues, keep up to date on them, and continually monitor your system and work group. Each individual in the work group must be aware of security and take steps to maintain it. Your responsibility as an administrator is to establish a security policy and begin its implementation.
A great strength of the IRIX system is the ease with which users can share files and data. However, some of the security guidelines presented in this chapter are at odds with easy system access. It is up to the system administrator to balance the needs and concerns of the user community.
There are three levels at which security must be established: individual systems, the local network, and a site connected to external networks such as the Internet. This chapter deals primarily with taking steps to secure an isolated system, but many of these same steps must also be taken before undertaking the more ambitious job of securing a network.
The components of security include physical security of systems, passwords protecting access to systems and resources, and permissions protecting files and directories.
The physical security of the systems in a work group is usually only partially the administrator's responsibility. The administrator's primary role is to educate other work group members in physical security. For the most part, this consists of limiting access to physical systems, peripherals, and storage media. It can also include providing individual systems and the network with protection against power surges, outages, and fluctuations.
Managing passwords is also described in IRIX Admin: System Configuration and Operation.
A system is most secure if nobody can access the system without an account and password, and if all the passwords on the system are difficult to guess and obtain. Surprisingly, many users choose passwords that are easy for potential intruders to guess, or write their passwords down on paper and leave them near their workstations and terminals.
Some site administrators use the same password for multiple administrative accounts. This is not a good practice. Do not deliberately use the same password for more than one account.
More secure passwords have all of these features:
They are long (the first eight characters are recognized).
They use multiple words that are combined or arranged in an unusual manner.
They contain words from multiple languages, combined in a unique way.
They are composed of different kinds of characters, such as digits and punctuation
Easily guessed passwords have these characteristics:
They are short.
They consist of single words that are in a dictionary.
They are the same as the account name, or the account name spelled backward.
They contain the name of the user's department or project.
They consist of the user's name or initials.
They contain the license number of the user's car, a spouse or friend's name, the user's home address, phone number, age, or other obvious information.
They are obvious—for example, “top secret,” “secret,” “private,” “password,” “friend,” “key,” “god,” “me,” and so on
Your system has a facility that allows you to require a password from users who attempt to gain access to the Command (PROM) Monitor. This gives greater control over who may perform system administration tasks.
Traditionally, if an intruder gains access to your system hardware, there is little you can do to maintain system security. In the simplest case, the intruder switches off the system, then turns it on again, and instructs the system from the console to boot a program other than your usual operating system. Alternatively, the intruder could simply remove the hard disk from your system and install it on another system and read your files. While there is nothing you can do with system software to prevent physical theft of the hardware, you can limit the ability of intruders to boot their programs or to otherwise damage your system at its lowest levels with a PROM password.
You can reset the PROM password on most systems as long as you have the root password. If you cannot successfully reset the PROM password, you must remove the PROM or a jumper from your CPU board. See the Owner's Guide for the system for information on this procedure.
If a system requires additional protection, you can establish a system password. If you do this, users who log in on specific ports (ttys) are prompted for a system password in addition to their account passwords.
System passwords are normally used only on dialup lines and are often referred to as dialup passwords. You can use them on standard lines, but this is usually not necessary.
Password files are generally accessible to any user of a system. Although the file is encrypted, if a copy of the file can be made, someone could attempt to decrypt it. You can prevent this type of attack by using a “shadow” password file. A shadow password file is a copy of the standard password file that is not accessible by non-privileged users.
The shadow password file is called /etc/shadow. Once shadow passwords have been initialized, the password field in each /etc/passwd entry is replaced by an “x” character.
 | Note: Shadow passwords work differently with NIS. See the shadow(4) reference page for details on the use of shadow passwords with NIS. |
You can use the password aging mechanism to force users to change their passwords periodically. It also prevents a user from changing a new password before a specified time interval. You can also force a user to change his or her password immediately.
Password aging does not provide as strong protection as it might seem; most users simply choose two passwords instead of one. This is because, when password aging is enforced, most users alternate between two passwords that they find easy to remember rather than inventing new passwords every time their old ones expire.
You can set passwords to expire after any length of time, from a day to several months or longer.
| Note: Password aging is not supported for NIS entries. |
From time to time, you should scan the password file on your system (and optionally, perform this procedure on users' systems as well). You can check the password file for completeness and consistency of information. If unauthorized access has been attempted, this type of checking may detect it. You can validate
the number of fields in each entry
the login name
the user ID number
the group ID number
the login directory
the executed program
To check a password file, you typically use the pwck command.
Be conservative when establishing or changing permission bit settings on all files and directories. The safest settings do not allow write access, but where this is not possible, it may be possible to limit write access to the owner of the file or directory, or at least just to the owner and the group.
The following files and directories are universally available for read and write access on IRIX as shipped. Depending on your site requirements, you may wish to change the permissions on these files to be more restrictive.
 | Caution: Restricting permissions on historically open directories, such as /tmp, /usr/tmp.O, and /var/tmp (linked to /usr/tmp), can cause serious malfunctions in many programs, applications, and system utilities that write temporary files on behalf of users in these directories. Below is a partial list of such directories: |
/tmp
/usr/demos/.xsession
/usr/Insight/tmp
/usr/Insight/tmp/ebtpriv
/usr/Insight/tmp/ebtpub
/usr/Insight/tmp/install.insight.log
/usr/lib/emacs/maclib
/usr/lib/showcase/fonts
/usr/lib/showcase/images
/usr/lib/showcase/models
/usr/lib/showcase/templates
/usr/tmp.O
/var/spool/locks
/var/spool/uucppublic
/var/tmp
For additional information about security, see IRIX Admin: Backup, Security, and Accounting. In attending to security of systems, networks, and information, both administrators and 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; anyone with physical access to backup tapes can gain access to any information stored on them.
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.
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), take precautions to isolate access to a specific gateway workstation.
Discourage use of the su 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). 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.
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 reference page for information on locking your local X display.
Sensitive data files should be encrypted. The crypt command, together with the encryption capabilities of text editors (for example, ed and vi), provides some protection for sensitive information.
Site administrators should be aware of the following:
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 view confidential material accidentally.
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 section “Passwords” 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.
Make sure that each user's home account, and especially the shell-startup files .profile, .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.)
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.
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.