![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
When a user attempts to log in to a system, the user provides a user name (a name that will be given to the resulting process) and a password. The password serves as an authenticator that should be known only to the user and to the operating system.
Because a short or obvious password is likely to fail this requirement, the system incorporates many password protection mechanisms that can be invoked by the user or required by the security administrator (see Chapter 7). The operating system is also capable of limiting the number of attempts that an intruder can make to guess a password.
The file of users' passwords is part of the security database that must be protected from unauthorized observation and modification. The system meets this requirement by storing the passwords in a file protected from general access, the system user authorization file (SYSUAF.DAT). The system takes the additional precaution of storing passwords in an encoded form that is hard to use if stolen.
Once the operating system creates a process for a user, it assigns a user identification code or UIC from the user authorization record to that process. The UIC corresponds to the name of the user who created the process (as authenticated by the user's password). In addition, the UIC indicates the user's membership in a group that can correspond to the user's department, project, or function. The system can also attach additional information to the process regarding the creation of the process and the affiliation of the process owner with other groups. This additional information plays a part in the application of the authorization database. (Both Chapter 4 and Chapter 8 discuss UICs.)
In the reference monitor concept, objects are passive repositories of information. In the OpenVMS system, there are many objects, such as files and devices, that are subject to protection, as described in Table 2-1. The operating system protects objects from unauthorized access and provides a variety of mechanisms (described in Chapter 4 and Chapter 5) for sharing them in a controlled manner. These mechanisms are also used to control access to system resources.
| Class Name | Definition |
|---|---|
| Capability | A resource to which the system controls access; currently, the only defined capability is the vector processor. |
| Common event flag cluster | A set of 32 event flags that enable cooperating processes to post event notifications to each other. |
| Device | A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data. |
| File | Files-11 On-Disk Structure Level 2 (ODS-2) files and directories. |
| Group global section | A shareable memory section potentially available to all processes in the same group. |
| Logical name table | A shareable table of logical names and their equivalence names for the system or a particular group. |
| Queue | A set of jobs to be processed in a batch, terminal, server, or print job queue. |
| Resource domain | A namespace controlling access to the lock manager's resources. |
| Security class | A data structure containing the elements and management routines for all members of the security class. |
| System global section | A shareable memory section potentially available to all processes in the system. |
| Volume | A mass storage medium, such as a disk or tape, that is in ODS-2 format. Volumes contain files and may be mounted on devices. |
According to the reference monitor model, each subject's authorization to gain access to an object is based on an abstract authorization database. This database is a set of dynamic security attributes that govern a subject's access to an object at any given time. In the OpenVMS system, the database is distributed and stored in association with the objects that must be protected. For example, the authorization data for a file or directory is stored in the file header for that file or directory. Table 2-2 summarizes the information stored in the authorization database.
| File | Contents | Data Used to Interpret |
|---|---|---|
| SYSUAF.DAT | User names | Logins |
| Passwords | Logins | |
| UICs | Access control checks | |
| NETPROXY.DAT | User names | Logins |
| NET$PROXY.DAT | User names | Logins |
| RIGHTSLIST.DAT | Rights identifiers | Access control checks |
| VMS$OBJECTS.DAT | UICs | Access control checks |
| Protection codes | Access control checks | |
| Access control lists | Access control checks | |
|
VMS$AUDIT_
SERVER.DAT |
Auditable events | Reporting of events |
As Section 2.2.2 suggests, different objects in the OpenVMS system can be shared with differing levels of flexibility. Protected objects are subject to a protection code. This code specifies whether access is allowed or denied to processes run on behalf of system users, the user who is owner of the object, other members of the UIC group of the owner, and all other users.
In addition to the protection code, objects can be shared under control of access control lists (ACLs). ACLs provide a finer granularity of access control than UIC-based protection, especially for user groups or subsets of groups. ACLs list individual users or groups of users who are to be allowed or denied particular types of access to the object. ACLs specify sharing on the basis of UIC identification as well as other groupings or identifiers that can be associated with a process. For example, it is possible to specify that a file should never be read by a process connected to a terminal on a dialup line. Section 2.2.6 uses an access matrix to explain the concept of an ACL. Section 4.4 gives a general discussion of ACLs and identifiers, and Chapter 8 explains how you, as security administrators, can create identifiers and construct ACLs for system resources.
All security-relevant events can be recorded in an audit log file, sent to an operator terminal, or both. A terminal can be designated as a security operator terminal where all auditable events can be displayed. An audit log file provides a permanent record of security events. Many times a security administrator can find a pattern of activity, called an audit trail, by studying the log file.
The operating system audits the classes of security events shown in Table 2-3 by default. You can select other events for auditing, such as volume mounts or changes to system time.
| Destination | Events Audited by Default |
|---|---|
| Log file or terminal display | Authorization database changes |
| Intrusion attempts | |
| Login failures | |
| Use of DCL command SET AUDIT | |
| Events triggered by Audit or Alarm ACEs |
The audit log allows users and security administrators to record many events. Because it is time-consuming to examine every event, it is most efficient to audit events that will contribute the most information to your security picture. See Chapter 9 for a description of security auditing.
In the OpenVMS operating system, the executive performs the role of the reference monitor. All system programs that run in kernel and executive mode help implement the reference monitor, as do the command line interpreter and certain user-mode images that run with privilege. While the volume of code comprising the executive is large, Digital attempts to ensure that none of the code can be used to bypass system security.
Some privileges can grant a user the authority to modify or subvert the reference monitor. For example, a process with the CMKRNL privilege can execute code of its own within the system kernel, gaining access to the reference monitor's internal data and the internal representation of protected objects. Clearly, granting such critical privileges should be severely limited.
Similarly, give privileges such as SYSPRV and SECURITY only to users whose processes help maintain the reference monitor and authorization database.
The reference monitor model specifies an authorization database, which describes all access authorizations in the system for all subjects and all objects. This database is often represented as an access matrix, which lists subjects on one axis and objects on the other (see Figure 2-2). Each crosspoint in the matrix thus represents the access that one subject has to one object.
Figure 2-2 Authorization Access Matrix
In this access matrix, an asterisk (*) denotes that the subject has access to that object. (Different types of access, such as read and write, are omitted from this example for simplicity.) Thus, subjects B, C, and D all have access to objects W, X, and Y. In addition, subject A has access to objects W and Z, subject D to object V, and subject E to object V.
Breaking up the access matrix by rows yields a capability-based model, in which each subject carries a list of the objects that it can access. Thus, a capability representation of this access matrix would appear as follows:
A: W, Z
B: W, X, Y
C: W, X, Y
D: V, W, X, Y
E: V
It is also possible to break up the access matrix by columns, listing for each object the subjects that have access to it. This results in an authority-based model, implemented in the OpenVMS system by ACLs (see Chapter 4). The ACL representation appears as follows:
V: D, E
W: A, B, C, D
X: B, C, D
Y: B, C, D
Z: A
The ACL and identifier controls used by the operating system combine the properties of both the capability- and authority-based systems. In OpenVMS systems, both subjects and objects carry identifiers. Subjects can access objects if they have matching identifiers and if the objects' access statements grant the requested access.
The result of combining properties of the capability- and authority-based systems is an extremely powerful and flexible system capable of representing complex access matrixes in a compact and convenient manner. Consider what happens to the previous example of an access matrix when some of the cross-points have labels, as shown in Figure 2-3.
Figure 2-3 Authorization Access Matrix with Labeled Cross-Points
Some labeled cross-points can be grouped and treated as a single entity. Thus, the points that are labeled Q in Figure 2-3 represent the access that subjects B, C, and D have to objects W, X, and Y. All the Q points can be considered as a single area of interest. The system provides the concept of identifiers to take practical advantage of this grouping of areas of interest.
You can define identifiers to represent the two groups of access, P and Q, in Figure 2-3. Note that two of the cross-points in the matrix remain unlabeled. Identifiers can also represent individual subjects and thus allow the traditional ACL facility.
To represent the access matrix, the OpenVMS operating system uses two structures, one for each dimension:
Note that the system structures required to represent the access matrix are simpler than either the traditional capability- or authority-based model and require fewer terms in total. In the example, the difference is slight. However, complexity of the access matrix increases with the square of its size.
When designing an overall system security plan, ask yourself the following questions:
These considerations, as well as the underlying reference monitor design, apply equally to a timesharing system, a widespread network, or a single application on a system that grants access to records in a file or database. The operating system provides general mechanisms that users and security administrators must apply to achieve system security. See Chapter 6 for more information on designing and implementing a security policy.
This chapter provides basic information on how to use the system securely. If you apply this knowledge consistently and accurately, while observing your site's specific security policies, you can make the difference between a secure system and one that is vulnerable to unauthorized users.
To choose a secure password, use the following guidelines:
Your security administrator may set up additional restrictions, for example, not allowing passwords with fewer than 10 characters.
Table 3-1 provides examples of secure as opposed to risky passwords.
| Secure Passwords | Insecure Passwords |
|---|---|
|
Nonsense syllables:
aladaskgam eojfuvcue joxtyois |
Words with a strong personal association:
your name the name of a loved one the name of your pet the name of your town the name of your automobile |
|
A mixed string:
492_weid $924spa zu_$rags |
A work-related term:
your company name a special project your work group name |
Typically, when you learn that an account has been created for you on the system, you are told whether a user password is required. If user passwords are in effect, you are told to use a specific password for your first login. This password has been placed in the system user authorization file (SYSUAF.DAT) with other information about how your account can be used.
It is inadvisable to have passwords that can be easily guessed. Ask the person creating an account for you to specify a password that is difficult to guess. If you have no control over the password you are given, you might be given a password that is the same as your first name. If so, change it immediately after you log in. (The use of first or last names as passwords is a practice so well known that it is undesirable from a security standpoint.)
Log in to your account soon after it is created to change your password. If there is a time lapse from the moment when your account is created until your first login, other users might log in to your account successfully, gaining a chance to damage the system. Similarly, if you neglect to change the password or are unable to do so, the system remains vulnerable. Possible damage depends largely on what other security measures are in effect.
At the time your account is created, you should also be told a minimum length for your password and whether you can choose your new password or let the system generate the password for you.
The system screens passwords for acceptability, as follows:
There are several types of passwords recognized by the OpenVMS operating system. In general, you need to provide a user password when you log in. In some cases, you might also need to provide a system password to gain access to a particular terminal before logging in with your user password. If you are using a system with high security requirements, you might need to provide a primary password and a secondary password.
If you are an externally authenticated user with external authentication enabled on your system, you enter your LAN Manager password at the OpenVMS password prompt. See Section 7.4 for more information. Table 3-2 describes each type of password.
Your security administrator will tell you if you must specify a system password to log in to one or more of the terminals designated for your use. Ask your security administrator for the current system password, how often it changes, and how to obtain the new system password when it does change.
To specify a system password, do the following:
[Return] <bell>
[Return]
MAPLE - A member of the Forest Cluster
Unauthorized Access Is Prohibited
Username:
An example of a login requiring primary and secondary passwords follows:
WILLOW - A member of the Forest Cluster
Welcome to OpenVMS on node WILLOW
Username: RWOODS
Password: [Return]
Password: [Return]
Last interactive login on Friday, 11-DEC-1993 10:22
$
As with a single password login, the system allots a limited amount of time for the entire login. If you do not enter a secondary password in time, the login period expires.
Five types of user accounts are available on OpenVMS systems:
Logins can be either interactive or noninteractive. When you log in interactively, you enter an OpenVMS user name and a password. In noninteractive logins, the system performs the identification and authentication for you; you are not prompted for a user name and password. (The term interactive, as used here, differs from an interactive mode process defined by the DCL lexical function F$MODE(). For a description of the F$MODE function, see the OpenVMS DCL Dictionary.)
6346P001.HTM OSSG Documentation 22-NOV-1996 13:04:50.06
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.