|
 HP OpenVMS Guide to System Security |
 Security Overview |
| OpenVMS Security Model |
|
|
| |
Implementation ofthe Reference Monitor
The following sections describe the OpenVMS operating system'simplementation of the reference monitor model.
Subjects
Subjects are the users or user agents (the user processes)that access information and, in some cases, may be prevented fromaccessing information. Subjects can be interactive processes, networkprocesses, or batch jobs, and:
During process creation
During information access
User names
Passwords
User identification codes
Rights identifiers
When a user logs in to use the operating system interactivelyor when a batch or network job starts, the operating system createsa process that includes the identity of the user. That process gainsaccess to information as the agent for the user, as described in Protecting Data.
Processes are vulnerable to security breaches while they arebeing created and while they are accessing information. The systemmanages process access to information by using its authorizationdata and internal mechanisms, such as hardware controls. Becauseprocess creation has many areas of security vulnerability, manyoperating security features concentrate on the area of process (orsubject) creation.
When a user attempts to log in to a system, the user providesa username (a name that will be given to the resulting process)and a password. The password servesas an authenticator that should be known only to the user and tothe operating system.
Because a short or obvious password is likely to fail thisrequirement, the system incorporates many password protection mechanismsthat can be invoked by the user or required by the security administrator (see Managing System Access). The operating systemis also capable of limiting the number of attempts that an intrudercan make to guess a password.
The file of users' passwords is part of the security databasethat must be protected from unauthorized observation and modification.The system meets this requirement by storing the passwords in afile protected from general access, the system user authorizationfile (SYSUAF.DAT). The system takesthe additional precaution of storing passwords inan encoded form that is hard to use if stolen.
Once the operating system creates a process for a user, itassigns a user identification code or UIC from theuser authorization record to that process. The UICcorresponds to the name of the user who created the process (asauthenticated by the user's password). In addition, the UIC indicatesthe user's membership in a group that can correspond to the user'sdepartment, project, or function. The system can also attach additionalinformation to the process regarding the creation of the processand the affiliation of the process owner with other groups. Thisadditional information plays a part in the application of the authorization database.(Both Protecting Data and Controlling Access to System Data and Resources discuss UICs.)
Objects
In the reference monitor concept, objects are passive repositoriesof information. In the OpenVMS system, there are many objects, suchas files and devices, that are subject to protection, as describedin Objects Protected by Security Controls. The operatingsystem protects objects from unauthorized access and provides avariety of mechanisms (described in Protecting Data and Descriptions of Object Classes )for sharing them in a controlled manner. These mechanisms are alsoused to control access to system resources.
Authorization Database
According to the reference monitor model, each subject's authorizationto gain access to an object is based on an abstract authorizationdatabase. This database is a set of dynamic security attributesthat govern a subject's access to an object at any given time. Inthe OpenVMS system, the database is distributed and stored in associationwith the objects that must be protected. For example, the authorizationdata for a file or directory is stored in the file header for thatfile or directory. The following table summarizes the information storedin 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 |
| Protectioncodes | Access control checks | |
| Access controllists | Access control checks | |
| #VMS$AUDIT_ #SERVER.DAT | Auditable events | Reporting of events |
As Objects suggests,different objects in the OpenVMS system can be shared with differinglevels of flexibility. Protected objects are subject to a protectioncode. This code specifieswhether access is allowed or denied to processes run on behalf ofsystem users, the user who is owner of the object, other membersof the UIC group of the owner, and all other users.
In addition to the protection code, objects can be sharedunder control of access control lists (ACLs).ACLs provide a finer granularity of access control than UIC-basedprotection, especially for user groups or subsets of groups. ACLslist individual users or groups of users who are to be allowed ordenied particular types of access to the object. ACLs specify sharingon the basis of UIC identification as well as other groupings or identifiers thatcan be associated with a process. For example, it is possible tospecify that a file should never be read by a process connectedto a terminal on a dialup line. Authorization Database Represented as an Access Matrix uses an access matrix to explain the conceptof an ACL. Controlling Access with ACLs givesa general discussion of ACLs and identifiers, and Controlling Access to System Data and Resources explains how you, as security administrators,can create identifiers and construct ACLs for system resources.
Audit Trail
All security-relevant events can be recorded in an audit logfile, sent to an operator terminal, or both. A terminal can be designatedas a security operator terminal where all auditable events can bedisplayed. An audit log file provides a permanent record of securityevents. Many times a security administrator can find a pattern ofactivity, called an audit trail, by studying the log file.
The operating system audits the classes of security eventsshown in Security Auditing Overview by default.You can select other events for auditing, such as volume mountsor changes to system time.
The audit log allows users and security administrators torecord many events. Because it is time-consuming to examine everyevent, it is most efficient to audit events that will contributethe most information to your security picture. See Security Auditing for a description of securityauditing.
Reference Monitor
In the OpenVMS operating system, the executive performs therole of the reference monitor. All system programs that run in kerneland executive mode help implement the reference monitor, as do thecommand line interpreter and certain user-mode images that run withprivilege. While the volume of code comprising the executive islarge, HP attempts to ensure that none of the code can be used tobypass system security.
Some privileges can grant a user the authority to modify orsubvert the reference monitor. For example, a process with the CMKRNLprivilege can execute code of its own within the system kernel,gaining access to the reference monitor's internal data and theinternal representation of protected objects. Clearly, granting suchcritical privileges should be severely limited.
Similarly, give privileges such as SYSPRV and SECURITY onlyto users whose processes help maintain the reference monitor andauthorization database.
Authorization Database Represented as anAccess Matrix
The reference monitor model specifies an authorization database,which describes all access authorizations in the system for allsubjects and all objects. This database is often represented asan access matrix, which lists subjects onone axis and objects on the other (see Authorization Access Matrix). Each crosspoint in the matrix thus representsthe access that one subject has to one object.
| Figure 2 Authorization Access Matrix |
 |
In this access matrix, an asterisk (*) denotes that the subjecthas access to that object. (Different types of access, such as readand write, are omitted from this example for simplicity.) Thus,subjects B, C, and D all have access to objects W, X, and Y. Inaddition, subject A has access to objects W and Z, subject D toobject V, and subject E to object V.
Breaking up the access matrix by rows yields a capability-basedmodel, inwhich each subject carries a list of the objects that it can access.Thus, a capability representation of this access matrix would appearas 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. Thisresults in an authority-based model, implemented in the OpenVMSsystem by ACLs (see Protecting Data). The ACL representationappears 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 systemcombine the properties of both the capability- and authority-basedsystems. In OpenVMS systems, both subjects and objects carry identifiers.Subjects can access objects if they have matching identifiers andif the objects' access statements grant the requested access.
The result of combining properties of the capability- andauthority-based systems is an extremely powerful and flexible systemcapable of representing complex access matrixes in a compact andconvenient manner. Consider what happens to the previous exampleof an access matrix when some of the cross-points have labels, asshown in Authorization Access Matrix with Labeled Cross-Points.
| Figure 3 Authorization Access Matrix with LabeledCross-Points |
 |
Some labeled cross-points can be grouped and treated as asingle entity. Thus, the points that are labeled Q in Authorization Access Matrix with Labeled Cross-Points represent the accessthat subjects B, C, and D have to objects W, X, and Y. All the Qpoints can be considered as a single area of interest. The systemprovides the concept of identifiers to take practical advantageof this grouping of areas of interest.
You can define identifiers to represent the two groups ofaccess, P and Q, in Authorization Access Matrix with Labeled Cross-Points. Note that two of the cross-points in the matrix remainunlabeled. Identifiers can also represent individual subjects andthus allow the traditional ACL facility.
To represent the access matrix, the OpenVMS operating systemuses two structures, one for each dimension:
Note that the system structures required to represent theaccess matrix are simpler than either the traditional capability-or authority-based model and require fewer terms in total. In theexample, the difference is slight. However, complexity of the accessmatrix increases with the square of its size.
|
|
