This chapter describes the process of planning the implementation of your Trusted IRIX/CMW security policy. Because it is very important to have a comprehensive plan when implementing a trusted environment, this chapter describes in detail the features that are usually customized.
The following sections are included in this chapter:
Before installing the Trusted IRIX/CMW system, spend some time defining your needs and examining and classifying the various types of information and applications that will reside on your system. Although it is always possible to reconfigure and change your system resources and practices, it is inconvenient to have to search through your system and fix existing files and user accounts. Planning helps to ensure a trouble-free and efficient trusted system implementation. A trial run of your trusted system is often beneficial before classified data and users are allowed access.
Administering a Trusted IRIX/CMW system involves many tasks that are performed by the system administrator or are divided between the system administrator and the auditor. On a Trusted IRIX/CMW system, these tasks include:
Planning your security administration
Defining and maintaining security policies
Configuring Trusted IRIX/CMW
Auditing security events
Maintaining Trusted IRIX/CMW data files
Controlling access of accounts and groups
Maintaining password functionality
Supporting networking with the Trusted IRIX/CMW system
Maintaining an evaluated configuration
This section explains the privilege environments (augmented superuser and no superuser) in which the administrator works and the privilege mechanisms (superuser-based and capability-based) used, and provides information on the administrator and auditor logins plus tasks they perform on a trusted system.
The IRIX system allows many users to work on the same system without interfering with each other or obtaining unauthorized access to each other's work. To accomplish this, the IRIX system defines certain restrictions on the actions of users. These restrictions create an environment in which users can confidently do their work without concern about the safety of sensitive data or loss of system availability.
The restrictions that prevent users from interfering with or inappropriately obtaining the work of others, however, must sometimes be overridden by administrators or system software. The ability to override restrictions is called privilege . The means by which the system determines, grants, propagates, and controls privilege is called a privilege mechanism , and the set of privilege mechanisms configured for a given system is called that system's privilege environment .
The IRIX system provides two privilege mechanisms:
You use these two privilege mechanisms to configure your IRIX system for one of two privilege environments:
The system administrator defines and maintains the security policy on the Trusted IRIX/CMW system. Policy-related system administration tasks include the following:
Establishing and implementing a site security policy
Designing a Mandatory Access Control environment that protects sensitive information without impeding legitimate system use
Creating and assigning security attributes to new user accounts
Deleting or restricting access to inactive user accounts
Protecting the integrity of system databases and executable files
Managing access to user data
Monitoring and maintaining the password generation and change system
Managing network security configurations
Monitoring system activity
Checking all new programs and files for security violations before they enter the Target of Evaluation (TOE)
Determining whether adding a program to the TOE is worth the risk involved with having a system that no longer matches the evaluated configuration
Maintaining the configuration database files for security purposes involves the following files. (For more information on the Trusted IRIX/CMW system data files see Chapter 8.)
/etc/aliases—the configuration file for e-mail groups
/etc/capability— the configuration file of user-allowed capabilities
/etc/clearance—the configuration file of user clearances
/etc/exports—the configuration file for directories exported using NFS
/etc/fstab—the configuration file for filesystems mounted both locally and via NFS
/etc/group—the configuration file for group name-to-group ID mapping
/etc/hosts—the configuration file for system-to-Internet address mapping
/etc/inetd.conf—the configuration file that holds the Internet server configuration database
/etc/motd—the login message file
/etc/networks—the configuration file for network to Internet address mapping
/etc/passwd—the configuration file for user name-to-user ID mapping
/etc/rhost.conf—the configuration file that contains a list of possible remote session hosts
/etc/sendmail.cf—the configuration file for the e-mail environment on this system
/etc/shadow— the configuration file of encrypted passwords
/etc/sys_id—the file that holds the name of this system
In addition to defining and maintaining policy, the system administrator also performs day-to-day maintenance tasks that do not require special privilege, ensures system availability, and manages the resources and services provided to the user community.
The system administrator is root, regardless of the privilege environment on your system. In the no-superuser privilege environment, the system administrator derives privilege from the /etc/capability file, specifically the capability setting for root:
root:all=:all+eip |
This allows a user who can log in as root to specify any set of capabilities at login, as follows:
Login: root CAP=all+eip |
Unless the capabilities are specified at login, root has no privilege in a no-superuser privilege environment.
In an augmented superuser privilege environment, root may also log in and specify capabilities, but this is not necessary because the root user ID automatically confers superuser privilege.
If MAC is installed, the system administrator must pay careful attention to MAC labels. The administrator can log in at any user MAC label and several system MAC labels. The reasons for choosing a given MAC label and the risks associated with operation at each MAC label are described as follows.
The system administrator usually logs in at a user label to manipulate data at that label without concern about accidentally creating an incorrectly labeled file. While this reduces the risk of accidental declassification, it does not eliminate this risk unless the system administrator also avoids MAC related capabilities at login. In the augmented superuser privilege environment, the system administrator cannot use capabilities to limit privilege, so the administrator must still be careful.
Certain system databases and log files are protected from modification and observation using the dbadmin MAC label . To view these databases and log files without accidentally disclosing their contents, the system administrator is encouraged to log in at dbadmin. In the no-superuser privileged environment, the system administrator can further protect against accidental disclosure by avoiding MAC related capabilities. This is not possible in the augmented superuser privilege environment.
Another reason for logging in at dbadmin is to modify private databases . Because the label on a private database is designed to protect it from disclosure, using privilege to edit such a database at a different label creates the risk of accidentally compromising security either by relabeling the database or creating an unprotected temporary file. By editing private databases at dbadmin the system administrator avoids this risk.
The final major reason for logging in at dbadmin is to review the system audit trail. The audit trail is kept at dbadmin to prevent users from determining when they are being audited. To avoid breaching this protection, the system administrator should always review audit data at dbadmin. This way any files created while reviewing audit data are protected like the audit trail itself.
Except for the ever-present risk of corrupting system databases, there are few risks specifically presented by using the dbadmin MAC label.
Databases like /etc/passwd and most commands are meant to be read or executed by any user, but modified only by the system administrator. To allow global read access while protecting against modification, these databases and commands have the dblow MAC label . The system administrator should log in at the dblow MAC label when editing these databases. This ensures that users retain access to the databases and that the databases are never assigned a user label.
Unlike with the dbadmin label, there are significant risks to sensitive data when the system administrator logs in at dblow. If superuser privilege or MAC related capabilities are present at this label, the system administrator may accidentally copy data from dbadmin or a user label into a file at dblow. Such a file is universally readable.
If possible, the system administrator should avoid MAC related capabilities when logged in at dblow. This is not possible in the augmented superuser privilege environment, and it may not always be reasonable in the no-superuser privilege environment. When superuser privilege or MAC related capabilities are present, the system administrator must take special care to avoid declassifying data.
To import unlabeled data into the system and assign it a label, the system administrator logs in at the High Clearance label (msenhigh/mintequal). This label allows the administrator to read data at any MAC label regardless of integrity. Data stored at this MAC label are unreadable by nonadministrators. The combination of these two factors allows an administrator at this label to read unlabeled data, store it temporarily at High Clearance, examine it to determine its correct MAC label, and then assign that label without fear of accidental disclosure.
While this is a useful label, the system administrator should always remember that this label confers the authority to ignore the mandatory integrity (MINT) policy of the Trusted IRIX/CMW system. This authority carries the risk of accidentally executing a Trojan Horse program. Also, the administrator should be aware that this label allows private databases to be modified without privilege and, potentially, be created with a label that does not carry MINT protections.
The system administrator is strongly cautioned against functioning at this label. It should be used only for importing unlabeled data.
The auditor monitors system activity looking for suspicious events and reports any suspicions to the system administrator for further analysis and possible corrective action. To perform this function correctly, the auditor requires access to the system audit trail and sufficient privilege to control the audit mechanism. The auditor does not need access to user data.
The auditor logs in as auditor in the IRIX system . This account has the following attributes, listed in the /etc/capability file:
Capabilities:CAP_AUDIT_WRITE,CAP_AUDIT_CONTROL,CAP_KILL |
The dbadmin MAC label, along with DAC permissions on the audit log files, allows the auditor to read the audit trail without privilege. Furthermore, the dbadmin label restricts the auditor to reading files at dbadmin and dblow. User files cannot be accessed because of their mandatory integrity (MINT) labeling. Because the auditor can log in only at this label and has no MAC related capabilities, the auditor is constrained to performing only the auditing function.
Auditing tasks include the following:
Working with the system administrator to determine the basic set of activities that need to be monitored
Establishing an auditing environment that effectively monitors these activities
Reviewing and analyzing the audit logs
Adjusting the audit environment as needed to obtain specific information to clarify possible suspicious activity
Reporting possible security breaches to the system administrator
Working with the system administrator to assess damage resulting from a security breach and design site policy changes to prevent future breaches
Processing audit data for long-term storage as dictated by the site security policy
Determining the basic set of monitored activities can be difficult. The auditor must balance the desire for detailed information against constraints of storage space and the limited human ability to analyze and assimilate the implications of potentially vast amounts of data. Aggressive auditing can produce large amounts of data about benign user activities. Insufficient auditing, however, may cause the auditor to miss crucial details that are the key to discovering or analyzing an attempt to abuse access to the system.
Some types of activities to be flagged for auditing are as follows:
Attempts at unauthorized entry
System usage at unusual hours or from unusual locations
Attempts at access control violations
Unexpected use of privilege
Connections with systems outside of the local network
Any activity by particularly interesting subjects
Any accesses of particularly interesting objects
Modifications of system data files
Manipulation of the audit trail itself
Once the system is set up, the auditor is responsible for storing the audit files and periodically viewing and editing the files to produce a record of the system usage. A number of tools are available for use with the system audit trail. Each tool is fully described in its own reference page. Among these are the following:
sat_select(1M)
sat_echo(1M)
sat_interpret(1M)
sat_reduce(1M)
sat_summarize(1M)
For a complete discussion of auditing under the IRIX system, please refer to the guide titled IRIX Admin: Backup, Security, and Accounting.
You must establish an overall security policy for your site, called a Site Security Policy. A security policy is a series of official statements regarding the rules for the use of the system. The purpose of the policy is to create a clear code to ensure the safe use of the system. This policy should be clearly articulated in a written document available to all users. Each person involved with the secure system should know his or her own security guidelines and responsibilities. At some sites, the security policy itself may be classified.
In 1987, the U.S. Computer Security Act mandated that secure computing sites are responsible for the integrity and confidentiality of their resources and information. Computer systems with sensitive information have long been a favorite attack point for malicious and mischievous intruders. Because of the nature of computers, intruders can do much of their work without direct contact with a human being. Damage done to computers and the information they store can come in many forms. Sometimes the damage is severe, when irreplaceable information is lost or corrupted. Sometimes the damage is a case of theft, when a business competitor seeks advance knowledge of product development. Occasionally, users themselves damage the system, either accidentally or with malice.
A total security policy has a number of segments. Among these are the physical security policy, the procedural security policy, and the system security policy. Take care to ensure that your security policies are concordant and similar in approach to one another. If possible, for consistency, the same person or group should draft all security policies. Avoid complexity in your policies; it can cause users to become confused or to circumvent policy.
A physical security policy is simply the security measures that protect the computer hardware from damage or unauthorized access. Damage in this sense can come from intruders or from aspects of the location, such as water damage or electrical power fluctuations. All physical components of your system, such as the central processing unit (CPU), any storage media, wiring, and remote terminals need to be governed by the physical security policy. Guidelines for effective physical security are:
Set the PROM password on your system. Instructions for this can be found in your Owner's Guide or in the IRIX Admin: System Configuration and Operation guide.
Keep the system physically secure at all times, such as in a locked or guarded room.
Restrict access to the room to those with immediate need to use the system.
Request that all users clear the video screen upon finishing work.
Maintain reasonable security against unauthorized and unrecorded entrance to the entire building or site where a trusted system is used. Such security can be in the form of keyed entry or other clear identification for authorized users.
Shield and protect all wiring and cables, especially network connections and terminal lines. The lines should be physically covered and unavailable. In no case should any part of the wiring be connected to unsecure systems or any area outside the secure site.
Keep physically secure all archive media and other data stored on magnetic media. Store it in a locked or guarded media library room. Segregate all media according to the classification of the information contained.
Restrict access to the media library or libraries to the system administrator.
Remove, erase, or destroy obsolete data as soon as possible.
Shred or otherwise destroy paper output when it is no longer needed.
The most secure software is of no use if your physical hardware is vulnerable. Therefore, when you are planning your system, take note of the location of the hardware. The computer itself should be located behind locked doors, and the number of people with access to the room should be strictly limited. Only users, system administrators, and other responsible people should be allowed in the room at any time. This security should never be relaxed. The power source for the computer should always be protected so that the computer is not subject to power surges or momentary power outages. The location of the computer should have a limited number of windows or be totally enclosed.
Beyond this, any coaxial cable connections to other computers on the secure system should be within the same restricted area. If it is necessary to connect to another computer outside the restricted area, the coaxial cable should be routed in such a manner as to avoid convenient points where the cable may be tapped by an intruder.
Peripheral hardware you attach to your system must likewise be protected from intruders. If you use a storage media device such as a cartridge tape drive, you must store the cartridge tapes after use with as much attention, if not more, to security as any other portion of the system. If a cartridge tape falls into the hands of an intruder, it is a simple matter to extract all the information onto a different system. Printers must also be closely monitored, because once information has been printed, it is available to anyone who can read it. Information import and export devices are the weakest link in your trusted system.
SGI workstations and servers support system passwords. These are also often called PROM passwords, because the firmware that supports the passwording is stored in PROM chips on the system's CPU board. It is strongly recommended that all Trusted IRIX/CMW systems make use of PROM passwords.
These passwords are demanded of the user attempting to access any part of the system while the operating system is not running. For example, with most computers, if you press the hardware reset button, the computer offers you a chance to perform system maintenance before the system reboots. Or in some cases, if you load an installation tape or floppy disk, the system boots from that media instead of booting the usual operating system. Once this has been accomplished, it is a trivial matter for the intruder to mount the disk or disks and gain access to all your files. Because the system password is required before the system does anything but boot the usual operating system, overall security is increased.
The methods for setting the PROM password differ from system to system. To set the system password, see your system's Owner's Guide, or the IRIX Admin: System Configuration and Operation guide. The owner's guide can also instruct you on procedures to follow to remove the password if you forget it.
The procedural policy is the segment of the security policy that dictates how the system is used. It should cover the responsibilities of each administrative user, such as the system administrator (root account) and auditor (auditor account), and the responsibilities of ordinary users. Guidelines for procedural policy should list decisions concerning these issues:
Who may use the trusted system and what operations each person is allowed to perform. Keep the number of users as small as possible.
What system information is available, and through what mechanisms it is available. For example, it is wise to limit the amount of sensitive data that may be printed on paper.
How information is to be handled at all times.
How to dispose of old information. Bear in mind that technology exists to read “erased” information from magnetic media. All physical copies of sensitive information should be destroyed rather than simply erased.
How the system-provided security features are used. For example, you should decide how thorough the auditing of user activities must be, and how often the auditor reviews the audit logs. The responsibilities of the auditor are described later in this chapter.
How often the Mandatory Sensitivity clearances and classifications are to be reviewed. Also, choose the same schedule for review of the Mandatory Integrity divisions and grades.
How often and at what level system backups are to occur.
A procedure and schedule for storage, archiving, retrieval, and disposal of system data.
A procedure for retiring user accounts for discontinued users.
Procedures used at your site for day-to-day activities can make or break your system security. If procedures are followed, your system security policy is much more likely to succeed than if procedures are lax.
The system security policy is closely related to both the physical security policy and the procedural security policy. It draws on both the physical and procedural policies to create a total policy for the system. Some guidelines for an effective system security policy are as follows:
Uniquely identify all users. In no instance should a user be allowed to share an account or any identification with any other person.
Authenticate each login attempt with a password. Each user account must have a unique password. This password is required for every login.
Change each user's password frequently. Facilities exist within Trusted IRIX/CMW to generate sound passwords that are difficult for a potential intruder to guess or discover through systematic trial and error.
Authorize each user to perform only those tasks and to view only the information that he or she needs to complete his or her work, and no more. By reducing the scope of each user account, you reduce the possibility of general damage by an intruder who gains access to a single account.
Adequately audit each user during every login session. Determine the amount of audit recording necessary to ensure a reasonable knowledge of system activity at all times. Events such as login time; logout time; the creation, modification, and deletion of files; and the invocation of TOE programs should always be audited. If possible, avoid simply auditing everything, because it can result in unnecessary information.
Educate your users, system administrators, and those who are present at your site but who are not users of the trusted system. Everyone, not only the managers and system administrators, can take responsibility for security.
Publish the security policies if possible, and make everyone at the site aware of security issues.
Review the security policies regularly and make necessary changes. As your system works and changes, modifications to the policy may become necessary. A breach of security may necessitate tighter controls and changes to the policy. However, excessively tight controls may deny access and encourage misuse of the system.
If possible, publish each change to the security policy clearly to all persons at the secure site.
To ensure compliance, make certain that all levels of management understand and approve each policy.
Keep the security policy consistent with the goals and standards of your company.
Do not make the security policies more rigid than necessary. A policy that is unrealistic is likely to be ignored or circumvented by unhappy users.
System security provides for the entire trusted system. The trusted system includes not only the hardware and software but each individual and the group as a whole. All of these combine to form a secure system for the safe development and storage of your sensitive information.
During preinstallation planning, determine how many user accounts will be necessary for the people who will work on your system. You need to know how many users to expect and how much disk and memory space they require in order to make informed decision regarding hardware resources.
Plan each user's clearance and the specific categories for which the user will be approved. The following list shows some options for setting clearances:
A user may be granted a single clearance such as Secret.
A user may be cleared for a set of labels such as Secret,A and Secret,B.
A user may be cleared for a range of labels such as Secret through Secret,A,B.
A user may be cleared for a set of ranges of labels such as Secret,A through Secret,A,B and Secret,B through Secret,A,B.
For more information on security label structure, see Chapter 5, “Administering Access Control”.
Similarly, plan the capabilities required to access key system files, and determine which users can access and manipulate those files. The users with these capabilities are those who have been selected to perform the system administration tasks described in “Planning Your Security Administration ”. Plan Access Control Lists in working and home directories at this time as well. Information on Access Control Lists can be found in the section titled “Access Control Lists” in Chapter 5.
Examine your hardware at this time to determine how much disk space the users and the information are likely to need. Planning adequate disk allocation at the beginning saves having to reinstall later if your system needs to grow. Include provisions for system audit requirements in system planning. The audit trail requires disk space. The specific amount of disk space required depends on the level of auditing configured and the amount of system activity. Audit trail requirements are discussed in detail in Chapter 6, “Administering the System Audit Trail”.
Before you install your system, you must define your classification scheme for Mandatory Sensitivity (MSEN). You must decide how many levels of sensitivity you need for adequate protection of your data. Bear in mind that some classifications are defined for you and cannot be changed. Among these are msenlow , which always represents the lowest sensitivity level on your system; msenhigh , which always defines the highest level of sensitivity on your system; and msenadmin , for MSEN administration files only. The predefined labels and files are discussed in more detail later in this chapter and in Chapter 5, “Administering Access Control”, in this guide. Assigning security classifications and clearances is the responsibility of the system administrator.
Beyond these labels, the system administrator is free to choose and name the clearances and classifications on your system as needed. Remember, however, to use a system that is readily understandable to your users. Familiar terms, such as public, confidential, classified, secret, top secret, and so on are very useful. If your system of classifications is too complex, users may find it difficult to perform their work.
At this time, you should also choose the categories of information that your system will recognize. This process should be straightforward, because most secure systems deal with only a limited range of information. Also, because a file or resource can be in as many categories as needed, it is easy to make the categories fit the information. Planning the makeup of the files and resources on your system before you begin the installation process is a key step.
Usually, sites converting to Trusted IRIX/CMW move a full complement of existing files to the new system. Each file should be examined to ensure the ongoing security of the system, once the files are installed. You must be certain that no threats to your system are hidden in the bank of files with which you begin.
Mandatory Integrity (MINT) works in concert with MSEN to ensure that each user accesses only the parts of the system that he or she specifically needs. While MSEN addresses which files and programs a user may see and invoke, MINT assures that the programs and files are free from threats and trusted by the system for that user. When you plan the clearances and classifications for MSEN, the system administrator should also plan the divisions and grades for MINT. Not all sites find it necessary to use the MINT facilities. MINT can be used to protect your system, but it is not required for a trusted system by the LSPP (Labelled Security Protection Profile).
The MINT grades indicate the integrity level of a program or file. Specifically, the MINT grade indicates the quality of the information. Although MINT is a completely separate system from MSEN, the two operate on similar principles. MINT divisions are used to segregate programs by topic, similar to an MSEN category. For example, system administrators can have a MINT division for their utilities and tools, and software developers can have another MINT division for their programs and tools.
Each user has a MINT grade and zero or more divisions in their label. A file or program created by that user automatically inherits that user's MINT grade and divisions (if any). If a user's MINT label has no divisions, then that user's MINT grade must be met by any program that the user accesses. If a user's MINT label contains divisions, a user is constrained to access only programs and files within those divisions. Make certain that each user has appropriate access to files and resources, and plan your MINT system appropriately. Use MINT to keep your sensitive accounts safe from invoking suspect programs that may cause damage.
The primary function of MINT is to make it possible to limit access to programs based on the known quality of the program. MINT protects powerful user accounts, such as root and auditor, from being corrupted or deceived by dummy files of low integrity. A secondary MINT function is its use in tailoring the tool set available to each account so that every user has an appropriate tool set and does not have access to inappropriate tools.
Clearly, the known integrity of a user and the task of the user should be used as guidelines in assigning the integrity level of the user account. Because a file created by that user inherits the user's integrity level and will thereafter be available to other users of a similar label, it is important to trust each user at the assigned integrity level. MINT makes it possible to disallow high-grade users from viewing files and invoking programs created by less trusted users.
While you are planning your system, plan to use the system audit trail features effectively. Decide what kinds of events you wish to audit and how much information you wish to store. If disk space is limited, you may wish to restrict auditing to events such as file removal, attempts to access the system, and denial of service. You must also budget the time of the auditor (or system administrator) to review and reduce the audit log to evaluate the security status of your system. See Chapter 6, “Administering the System Audit Trail”, for more information about auditing.
If you plan to have more than one Trusted IRIX/CMW system at your site and you would like to connect them as one logical system, if you have a single Trusted IRIX/CMW system you would like to connect to your existing network, or if you have a totally heterogeneous network, you should plan a networking strategy. First, become familiar with standard IRIX networking software. Then, after reading Chapter 4, “Networking with Trusted IRIX/CMW”, map out your proposed network and plan your installations accordingly.
A cpuset is a named set of CPUs, which may be defined to be restricted or open. A restricted cpuset allows only processes that are members of the cpuset to run on the set of CPUs. An open cpuset allows any process to run on its CPUs, but a process that is a member of the cpuset can run only on the CPUs belonging to the cpuset. A cpuset is defined by a cpuset configuration file and a name.
The Cpuset System is primarily a workload manager tool permitting a system administrator to restrict the number of processors that a process or set of processes may use. Cpusets may optionally restrict both kernel and user memory.
For information on how to use cpusets in a Trusted IRIX environment, see “Cpuset System and Trusted IRIX”, in IRIX Admin: Resource Administration.
The following is a list of important items to keep in mind as you install and use your Trusted IRIX/CMW system:
The label of /etc/group is dblow.
The label of /etc/passwd is dblow.
The label of /etc/clearance is dblow.
The label of /etc/shadow is dblow.
The label name dblow translates to msenlow/minthigh.
The label name dbadmin translates to msenadmin/minthigh.
The integrity of all administrative databases is minthigh.
The sensitivity of administrative databases is either msenlow (publicly readable) or msenadmin (hidden from users).
If you are unsure whether Trusted IRIX/CMW has been installed on a system , use the sysconf command to list MAC, ACL, or capabilities status. The following example shows a sysconf query and the system response that MAC is installed:
sysconf mac 1 |
The following example shows a sysconf query and the system response that CAP is installed:
sysconf cap 2 |
The following uname command returns the name of the operating system currently in use on the system:
uname -s |
Note that uname will return only IRIX, or IRIX64 on a 64-bit IRIX machine, but not Trusted IRIX/CMW.
The uname system call will return the operating system name from within a program. Such a test can be useful when writing code that may or may not be run on a trusted system.
Installation of Trusted IRIX/CMW is substantially similar to that of standard IRIX. Installation instructions are found in the IRIX Admin: Software Installation and Licensing guide or in the release notes and errata.
Trusted IRIX/CMW is part of the TOE, that is, the hardware and software that have been determined to be trustworthy. Making any changes, including deletions, to the TOE results in a system that is less trustworthy than the original . If your site has been determined to require the evaluated configuration of Trusted IRIX/CMW, it is vital that nothing in the TOE be changed or removed, and that no additional hardware or software be added to the TOE.
If, at some point, you discover that new software with privilege has been added to your TOE, your system can no longer be assured to be trustworthy, and the evaluated configuration will have been altered. This does not mean that there has been a security breach or loss or disclosure of data, merely that the safeguards built into Trusted IRIX/CMW may have been weakened.
You can get back to the evaluated configuration by storing your data files on tape, removing the operating system, erasing the disks completely (reformatting the disks will generally suffice, unless you have specific requirements for reusing magnetic media), and reinstalling the operating system from the original distribution media. It is vitally important that you go back to the original distribution software to be sure that you are installing the evaluated configuration.
Once this is done, reinstall your configuration files and system environment, with the exception of the file or files that were added to, changed in, or removed from your TOE. Your TOE should then again be reliable.
The standard IRIX system administration tools are used to manage Trusted IRIX/CMW. For complete information on using these tools, consult your standard IRIX documentation.
When making administrative changes to files under the Revision Control System (RCS) , you can use a standard editing utility, such as vi, to be sure the correct audit events are generated. The editor (user account) privilege must match that of the file for editing to be allowed.
The following files hold information about your user accounts:
/etc/clearance
/etc/shadow
/etc/passwd
/etc/group
/etc/config/login.option
The /etc/mac file controls MAC labels on your system (labelnames, levelnames, gradenames, categorynames, divisionnames).
The following files hold information about hosts on your network and about your system.
Files installed by default:
/etc/hosts
/etc/networks
/etc/hosts.equiv
/etc/inetd.conf
/etc/services
/etc/sys_id
/etc/config/ifconfig-1.options
/etc/config/netif.options
/etc/rhosts.conf
Files installed manually:
/etc/resolv.conf
/etc/net_id
/etc/sys_owner
/etc/config/ifconfig-2.options
/etc/config/ifconfig-3.options
Note: The /etc/resolv.conf file typically is installed by copying an existing /etc/resolv.conf file from a neighboring system. If the copy is done over a network, the resulting label is likely to be userlow. For the network service daemon to work, the label must be changed (by using the chlabel(1) command) to dblow.
The following files contain important information about your filesystems:
/etc/config/automount.options
/etc/fstab
/etc/exports
/etc/lvtab
Mail Aliases Files:
The following files contain information used to send mail to users on your system:
/etc/aliases
/etc/sendmail.cf
/etc/config/sendmail.mac_label
The following files configure the ports through which users can log in and to which modems and other I/O devices may be connected:
/etc/gettydefs
/etc/ttytype
The following files control your system auditing environment:
/etc/config/sat_select.options
/etc/config/satd.options
When the time comes to deactivate a particular computer from your system, or perhaps deactivate your entire site, you must take certain steps to ensure that information is not inadvertently disclosed:
All magnetic media not being maintained in a secure manner must be thoroughly erased or destroyed. Except for project records and results that must be maintained, destroy all backup media and other records that might be salvaged if they were merely discarded.
All accounts on all systems must be thoroughly deactivated.
All disks on all systems must be reformatted or destroyed.