Chapter 1. Introduction to the Commercial Security Pak

This guide introduces you to working with the security features in the Commercial Security Pak. This product has been designed to provide the usual security features necessary in a commercial environment. It provides features and assurance at the C2 level, according to the Department of Defense “Orange Book.” The Orange Book is a common name for the 5200.28-STD Department of Defense Trusted Computer Systems Evaluation Criteria.

Commercial Security Pack Product Overview

This chapter provides a helping hand in learning how to use the system for day-to-day tasks. To this end, some explanation of security procedures and mechanisms must be provided.

Definition of a Trusted System

Operating systems that attempt to provide a secure environment for the development and storage of sensitive information are known as trusted systems. In an abstract sense, no system is ever perfectly secure from harm, so we use the term trusted rather than secure. A trusted system can be thought of as any system that fits the following criteria:

  • The system allows all users to do their ordinary and necessary work without difficulty.

  • The system enforces the security policy deemed by the management to be appropriate to the site.

The first criterion is the most important. If users are unable to do their ordinary and necessary work, they either will circumvent the security measures or they will not use the system at all. In either case, the trusted system is rendered useless. Many users are concerned that they will not be able to do their work in a trusted environment. A good site administration plan will structure a trusted system so that the user is relatively unaffected by its functioning. Ideally, users should be able to perform all their tasks and never see the trusted features of the operating system.

The second criterion requires that the system have adequate security features to enforce the site security policy set forth by the management. IRIX, with the Commercial Security Pak, offers a variety of security measures that are sufficient to satisfy most sites. These measures are:

Access Control Lists 

An Access Control List allows the owner of a file or directory to make a specific list of users and user groups and the specific permissions each one is allowed to the file or directory.


The IRIX Audit subsystem allows your Site Security Officer to keep a precise log of all system activity.


Capabilities allows your Site Security Officer to specify specific individuals to be given the privilege to perform one or more of the tasks formerly reserved to the Superuser (root) account. This facility is used to allow users to perform system administration roles without the necessity of a specific login account for that role.

Discretionary Access Control 

This is the standard IRIX system of file and directory permissions.

Identification and Authentication 

The Commercial Security Pack has improved user identification and authentication facilities that ensure the integrity of system passwords and help to ensure that only authorized users are granted access to the system.

Reasons to Use a Trusted System

The Commercial Security Pak is designed to address the three fundamental issues of computer security: policy, accountability, and assurance. By fully addressing these areas, the system becomes a trustworthy base for secure development and business. Since the nature of a trusted system is already constrained, little must be trusted beyond the system itself. When you run your application programs on the system, you have a reasonable certainty that your applications will be free from corruption and safe from intruders.

The most important security aspect of the system is a clear definition of the site security policy with respect to all the trusted system features listed above. To accomplish this, all system objects have been examined and altered to close potential security holes and determine a basic clearance level. This examination and revision process ensures the integrity and security of the system.

Another highly important security aspect is assurance. A secure system design must be inspected and approved by a competent agency. The Commercial Security Pak from Silicon Graphics is under evaluation for the C2 security rating from the National Computer Security Center (NCSC).

Reasons to Use the Commercial Security Pak

Many commercial sites are finding that in order to protect their investment in software and research from malicious intrusion both from inside and outside their organization, an extra measure of security is warranted. This security, though, should not impede the progress of their employees.

Ease of Use

As a modified version of an existing operating system, many of the underlying features of the Commercial Security Pak have withstood the test of time. Designing a system that promoted “ease of use” was a paramount consideration in the creation of IRIX. Silicon Graphics has a firm commitment to visual computing as evidenced by the graphical tools provided to you in the IRIX environment.

Greater User Friendliness

Part and parcel of our commitment to ease of use is by extension our commitment to “user-friendliness.” A consistent and logical framework underlies the design of Silicon Graphics visual desktop tools. This design permits even the novice user to move about the operating system with some confidence. The desktop provides a visual representation of the file system and allows you to navigate using the mouse alone.

Customer Support

You may contact Silicon Graphics customer support at 1-800-800-4SGI.

Commercial Security Pak Features

The distinguishing difference between trusted systems and nontrusted systems is the security-enhanced feature set. In the Commercial Security Pak, this feature set includes three main components: improved identification and authentication of users, auditing, and access control (ACLs and Capabilities).

Every trusted system has a Trusted Computing Base (TCB). The TCB is the system hardware, the operating system program itself, and the commands, utilities, tools, and system files that are known to be secure. This set of hardware, files, and programs is the “trusted” part of a trusted system.

Within the TCB, there are subjects and objects. A subject is any active force on the system, such as a user's shell process, or the audit daemon, or the operating system itself. An object is any passive resource on the system, such as a text file, a page of memory, or a piece of system hardware.

The Commercial Security Pak is fully configurable to your site's needs. You are free to select your own capabilities and access control lists, and your own system of password protection.

Identification and Authentication

The Identification and Authentication mechanism controls user access to the system. In common terms, the I&A mechanism is the login procedure. This subsystem is always active if the system is running, and it is impossible to have any contact with the system without first logging in through the I&A system.

The improved I&A facilities of the Commercial Security Pak allow the administrator to be certain that the people on the system are authorized users and that private password integrity is maintained to the highest possible levels.

Passwords Under the Commercial Security Pak

Under the Commercial Security Pak, encrypted passwords are stored separately from other user identification information. This separate location is hidden from normal user access, so the process of a systematic “dictionary encryption” hunt for a password is precluded. User clearance information is also stored in a hidden or shadow file. Under the Commercial Security Pak, the /etc/passwd file does not contain the encrypted password; only the shadow password file contains that information.

Passwords can be generated automatically for the users under the Commercial Security Pak. System administrators can configure the system to require this feature for every password change, or it can be an option for the user. The complexity, length, and character combinations required of passwords can also be configured. For example, it is possible to require users to mix control characters into their passwords. It is also possible to check and reject passwords that can be found in a dictionary, proper names, place names, and technical words associated with computers or the current project. System administrators can also require passwords to be changed on a regular basis.


Your Site Security Officer can require a user-specific capability requirement for access to system executable files. A capability requirement can be imposed on any executable file — without the corresponding capability endorsement, no user can access the file. The capability endorsements are made separately for each user. This allows the Site Security Officer to allow only certain users to access system programs and to designate certain users to perform system administration tasks — to fulfill the system administration roles without requiring a special privileged login account (root) for the role.

Discretionary Access Control Permissions

The Commercial Security Pak supports the POSIX P1003.1e Draft15 definition for Access Control Lists (ACLs). This draft standard provides for traditional file permission bits working in concert with the more versatile ACLs. DAC permissions are defined by the user who owns the file in question. For example, if a user has a personal file in his or her home directory, that user can set the DAC permissions to allow no other users on the system, save only root, to view, copy, or edit that file. Default DAC permissions for newly created files are set via the umask(1) command.

Thus, to gain access to a file owned by another user, the owner must have set the DAC permissions on the file to allow others to access it. Typically, DAC permissions would be set to allow access on all but personal files.

Default DAC permissions for newly created files depend on the umask and on any default ACL entries found in the containing directory. Default DAC permissions for newly created sockets are specified with the setpsoacl(2) system call.

Access Control Lists

Access Control Lists allow users to specify on a user-by-user basis who may access their files and directories. The purpose of this feature is to provide a finer level of control than is allowed through traditional discretionary access control.

System Audit Trail

A foundation of system security is the System Audit Trail. The System Audit Trail provides a means for the system administrator to oversee each important event taking place on the system. The Audit Trail is useful for tracking changes in sensitive files and programs and for identifying inappropriate use of the system.

The Audit Trail is generated by additional code in the operating system kernel that notes specific important events, such as file creation, changes and removal; invocation of programs; and the login and logout events.

The audit subsystem allows the administrator to create a dynamic record of the system's activity. This record allows the administrator to hold each user strictly accountable for his or her actions. The audit system is completely configurable at any time by the audit administrator.

Audit information must be carefully gathered and protected so that actions affecting security can be traced to the responsible party. IRIX records the occurrences of security-relevant events in an audit log. For each event audited, the system records the date and time of the event, the initiating user, the type of event, the success or failure of the event, and the name and security classification of the files or programs used.

The auditing process is transparent to the user. It is important to recognize that when working on a trusted system, your actions will be audited. You should not, however, be apprehensive or fearful of the auditing process. It is not used to spy on individual users or to trap you in any way. Its function is to protect you from others who may try to use your identity for mischief.

Object Reuse Policy

To preclude accidental disclosure of data, display memory and long-term data storage are subject to an object reuse policy and implementation. For example, all system memory is always automatically cleared before it is allocated to another program. Surrendered disk space is also cleaned before being reallocated.