This User's Guide has been designed to introduce you to working with secure systems. In particular, it addresses your first interactions with Silicon Graphics Commercial Security Pak and gives you some pointers on how to maintain system integrity with regard to security. It also describes the various modifications and additions made to standard IRIX that make this system secure.
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 necessarily be provided.
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 the term trusted rather than secure is more accurate. 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 circumvent the security measures or they do not use the system at all. In either case, the trusted system is rendered useless. Many users are concerned that they cannot 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. The Commercial Security Pak offers a variety of security measures that are sufficient to satisfy most sites. These measures are:
| Access Control Lists |
| |
| Auditing | The Audit subsystem allows your Site Security Officer to keep a precise log of all system activity. | |
| Capabilities | Capabilities allows your Site Security Officer to specify specific individuals to be given the capability to execute sensitive system files. This eliminates the risk of having a single all-powerful root account. | |
| Discretionary Access Control |
| |
| Identification and Authenthication |
|
This security package is a significant improvement over conventional operating systems derived from the standard UNIX kernel. While trusted operating systems necessarily add some level of extra effort to user interactions, the system need not be hostile to the average, or even novice user.
This security package 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 are free from corruption and safe from intruders.
A number of features of the Commercial Security Pak are invisible to the user most of the time. These may occasionally affect your environment and so it is best to mention them here.
| Access Control Lists (ACL) |
| |
| Auditing | Auditing is constantly in effect on most Commercial Security Pak systems. This is not a cause for user concern, as the purpose of the audit trail is to discern intentional violations of security by malicious intruders, not to spy on legitimate users. See Chapter 3, “System Audit Trail” for information on auditing. | |
| Capabilities | It is possible to grant a user certain capabilities that have formerly been reserved for the superuser. It is also possible that userid 0 (root) need not have special privilege. See “Capabilities” in Chapter 2 for more information. | |
| CSP-Kerberos | The CSP-Kerberos authentication system is provided and may be in use on your system. See Chapter 4, “Using CSP-Kerberos” for information on CSP-Kerberos. | |
| Password Aging |
| |
| Password Generation |
|
The distinguishing difference between trusted and nontrusted systems is the security-enhanced feature set.
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, 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, and CSP-Kerberos authentication for network services.
The Identification and Authentication (I&A) 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.
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.
In response to basic security requirements, 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 files. A capability requirement can be imposed on any file—without the corresponding capability endorsement, no user can access the file. The capability endorsements are made on a user-by-user basis. This allows the Site Security Officer to allow only certain users to access system files. The reason for this facility is to allow the Site Security Officer to designate certain users to perform system administration tasks, to fulfill the system administration roles without requiring a special login account for the role.
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, except root, to view, copy, or edit that file. Default DAC permissions for newly created files are set via the umask(1) command.
Typically, DAC permissions are 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.
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.
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 prior to reallocation.