![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Chapter 5 describes the unique features of each class of protected object.
User processes and applications as well as objects have security
profiles,
which contain a consistent set of elements. Before a process can access
a
file, device, global section, or any other protected object, the
operating
system checks to ensure that the requesting process has the authority to
access the object in the manner requested. To establish this, the
operating
system examines the security profile of both the requesting process and
the
object.
The profile of a user process or application includes the following elements:
The first element of a subject's security profile is the user identification code (UIC). Your UIC tells what system group you belong to and what your unique identification is within that group.
A UIC specification always appears in brackets, but its format can differ. Valid formats include the following:
[member]or
[group,member]
[group,member]
The following table illustrates several UICs in proper UIC notation:
| Type of UIC | Example | Meaning |
|---|---|---|
| Alphanumeric | [USER,FRED] | Group USER, member FRED |
| [EXEC,JONES] | Group EXEC, member JONES | |
| [JONES] | Group EXEC,¹ member JONES | |
| Numeric | [200,10] | Group 200, member 10 |
| [3777,3777] | Group 3777, member 3777 |
UICs cannot be arbitrarily assigned. A security administrator has to observe the following guidelines when creating them:
These guidelines exist because the system translates a UIC to a 32-bit value that represents a group number and a member number; the high-order 16 bits contain the group number, and the low-order 16 bits contain the member number. When translating an alphanumeric UIC such as [J_JONES], the operating system equates the member part of the alphanumeric UIC to both the group and member parts of a numeric UIC. The resulting 32-bit numeric UIC is kept in the rights database (which is a file containing information about identifiers, their attributes, and holders). For example, you could not have the two UICs [GROUP1,JONES] and [GROUP2,JONES] on the same system because the member JONES can have only one associated numeric UIC. The member name of the alphanumeric UIC is normally the same as the associated login user name.
When you log in to a system, the operating system copies your UIC from your user authorization (UAF) record in the system user authorization file (SYSUAF.DAT) and assigns it to your process. It serves as an identification for the life of the process.
By default, detached processes (created by the DCL command SUBMIT or RUN) and subprocesses (created by the DCL command SPAWN) take the same UICs as their creators. If you have DETACH privilege, you can create a detached process with a different UIC (by using the /UIC qualifier of the RUN command).
The second element of a subject's security profile is a set of rights identifiers.
A rights identifier represents an individual user or a group of users. Using the Authorize utility (AUTHORIZE), security administrators create and remove identifiers and assign users to hold these identifiers. Rights identifiers can be a temporary way of identifying a group of users because users hold certain identifiers only as long as they are necessary.
The operating system supports several types of rights identifiers. Table 4-1 shows the identifiers that are most commonly used in access control.
| Type | Description | Format | Example |
|---|---|---|---|
| Environmental identifiers | Describe different types of users based on their initial entry into the system. | Alphanumeric strings automatically created by the system. See Section 3.4 for details. |
BATCH, NETWORK,
INTERACTIVE, LOCAL, DIALUP, REMOTE |
|
General
identifiers |
Defined by the security administrator. | Alphanumeric strings of 1 through 31 characters with at least one alphabetic character. Valid characters include numbers 0 through 9, characters A through Z and a through z, the dollar sign ($) and the underscore (_). |
SALES,
PERSONNEL, DATA_ENTRY, RESERVE_DESK |
| UIC identifiers | Based on a user's identification code (UIC), which uniquely identifies a user on the system and defines the group to which the user belongs. | Alphanumeric UICs, with or without brackets. Valid characters are the same as those for a general identifier. |
[GROUP1,JONES],
[JONES], GROUP1, JONES |
|
Facility
identifiers |
Defined by the application. | Same as a general identifier. See the OpenVMS Programming Concepts Manual for details. | DBM$MOD_SCHEMA |
In addition to the identifiers listed in Table 4-1, a system node identifier of the form SYS$NODE_node_name is created by the system startup procedure (STARTUP.COM in SYS$SYSTEM).
Associated with your process is a rights list that contains all the identifiers granted to it. In addition, there is a system rights list that is shared by all users on the system. Identifiers granted to the system rights list by the system manager or the system software are in effect granted to all users currently logged on to the system.
You can display the identifiers for your current process with the SHOW PROCESS command, for example:
$ SHOW PROCESS/ALL
25-JUN-1991 15:23:18.08 User: GREG Process ID: 34200094
Node: ACCOUNTS Process name: "_TWA2:"
Terminal: TWA2:
User Identifier: [DOC,GREG] (1)
Base priority: 4
Default file spec: WORK1:[GREG.FISCAL_91]
Devices allocated: ACCOUNTS$TWA2:
Process Quotas:
.
.
.
Process rights:
INTERACTIVE (2)
LOCAL (3)
SALES (4)
MINDCRIME resource (5)
System rights:
SYS$NODE_ACCOUNTS (6)
Output from this SHOW PROCESS command displays three types of identifiers:
The rights identifiers of a process also appear in audit records. If a security administrator chooses to audit access to objects, then the operating system can produce a record of which users accessed objects and when. Although a single audit record rarely tells very much, the trail of records can, over a period of time, reveal a pattern of behavior that tells a story.
The following audit record shows that user Greg attempted to delete a file but was prevented from doing so because he holds the identifier MINDCRIME. The file 93_FORECAST.DAT has an ACE preventing access by processes with the identifier MINDCRIME. (Relevant lines in the audit record are highlighted.)
Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) and security audit (SECURITY) on ACCOUNTS, system id: 19662 Auditable event: Object deletion Event information: file deletion request (IO$_DELETE) Event time: 24-APR-1992 13:17:24.59 PID: 34200094 Process name: _TWA2: Username: GREG Process owner: [DOC,GREG] Terminal name: TWA2: Image name: DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE Object class name: FILE Object owner: [SYSTEM] Object protection: SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RE, WORLD:RE File name: _DSA2200:[GREG]93_FORECAST.DAT;1 File ID: (17481,6299,1) Access requested: DELETE Matching ACE: (IDENTIFIER=MINDCRIME,ACCESS=NONE) Sequence key: 00008A41 Status: %SYSTEM-F-NOPRIV, no privilege for attempted operation
A third (optional) element of a subject's security profile is a set of privileges.
Privileges let you use or perform system functions that you ordinarily would be denied. Security administrators can grant privileges to users under special circumstances so they can perform necessary tasks without changing existing protection authorizations.
Privileges vary in power. Some allow normal network operations; for example, NETMBX and TMPMBX let you send and receive mail across the network. But others, such as SYSNAM, grant the ability to influence system operations. A user with the SYSNAM privilege can modify the system logical name table.
A user's privileges are recorded in the user's UAF record in a 64-bit privilege mask. When a user logs in to the system, the user's privilege vector is stored in the subject's (process) security profile.
You can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which you are are authorized, thus controlling the privileges available to the images you run. Example 4-1 shows user Puterman has a large number of authorized privileges, which are available for use when necessary, yet Puterman's process runs by default with only two privileges enabled: NETMBX and TMPMBX.
Example 4-1 Authorized Versus Default Process Privileges
$ SHOW PROCESS/PRIVILEGE
8-OCT-1992 16:58:58.77 User: PUTERMAN Process ID: 27E00496
Node: FNORD Process name: "Hobbit"
Authorized privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL
DETACH DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPORT
LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL
SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD
Process privileges:
NETMBX may create network device
TMPMBX may create temporary mailbox
Because the operating system supports many users simultaneously, it has
built-in security mechanisms to prevent one user's activities from
interfering with another's. Protection codes, access controls, and
hardware
design together protect the use of memory, shareable devices, and data
so
many users can share the system.
The objects of the OpenVMS operating system that require protection are all passive repositories that either contain or receive information. These objects are protected because once you have access to the object, you have access to the information it holds. Some examples of protected objects include:
Section 4.2.5 lists the classes of objects that OpenVMS protects; refer to Chapter 5 for an in-depth description of each class.
The security elements of any object comprise its security profile. An object's security profile contains the following types of information:
With the exception of files, a new object inherits its security elements from a system-supplied template profile, which the site security administrator may modify. Files have a more complicated inheritance mechanism, one that affords greater control over the security elements of new objects. In all cases, you can assign security elements during object creation rather than use the operating system defaults.
This section gives an overview of protection codes and ACLs. Section 4.4 and Section 4.5 explore these protection mechanisms in greater detail. Refer to Chapter 5 for a description of individual object classes.
The first element of an object's security profile is the UIC of its owner.
In most cases, if you create an object, you are its owner. As the owner, you can modify its security profile. The system automatically assigns your UIC to the object and uses it in making access decisions.
There are some exceptions to the ownership rule. Files owned by resource identifiers do not have a UIC. When a user creates a file in the directory of a resource identifier, the file may be owned by the resource identifier and not the user who created the file (see Section 5.4.5). Refer to Chapter 5 for an explanation of the ownership rules for each object class.
The owner of any object except a file can reassign ownership to another user with the SET SECURITY/OWNER command, as described in Section 4.2.4. Changing the owner of a file usually requires privilege (see Section 5.4.2).
The second element of an object's security profile is the object's protection code.
The system automatically assigns a protection code to each new object. The protection code associated with an object determines the type of access allowed to a user, based on the relationship between the user UIC and the owner UIC. With the exception of files, the code a protected object receives is derived from a template profile for the class. (A file's protection code originates from another source, described in Section 5.4.)
Typically, you rely on the protection code to protect an object if the object is to be accessed by: (a) only the owner, (b) all users on the system, or (c) a specific UIC-based group of users. If you want to grant access to specific groups of users outside the UIC group but not to all users on the system, then you need to add an ACL (see Section 4.2.2.3).
Interpreting a Protection Code
A protection code defines the access rights for four categories of users: (a) the owner, (b) the users who share the same group UIC as the owner (the group category), (c) all users on the system (the world category), and (d) those with system privileges or rights (the system category). A code lists access rights in a fixed order: the system category (S), then owner (O), then group (G), and then world (W). It has the following syntax:
[user category: access allowed (,user category: access allowed,...)]
When the operating system processes a request to use a protected object, it compares the user's UIC to the UIC of the object's owner. If the user's UIC is the same as the UIC of the object's owner, the user is granted the access of the owner protection field. Failing a match of UICs, the system progresses through the other user categories. The system tries to find a match of the group fields to determine if there is a common group membership. The system may also evaluate whether the UIC group number indicates the user belongs to the system category of users. The world category applies to all users.
For example, user Jones has a UIC of [14,1], and he tries to read a file that is owned by UIC [14,5]. Because Jones is in the same group (14), the system might grant access to the file. The final decision depends on the access rights specified in the protection code.
See Section 4.5 for a complete description of how to interpret and create protection codes.
The third (optional) element of an object's security profile is the object's access control list.
An access control list (ACL) is a collection of entries that define the access rights a user or group of users has to a particular protected object, such as a file, directory, or device.
ACLs may be created by default when an object is created, they may be created by the security administrator, or they may be created by users for objects to which they have control access (see Section 4.6.2).
Because security administrators can set up default ACLs, some users may be unaware that their objects have ACLs and may never change ACLs themselves. (You can use the DCL command DIRECTORY/SECURITY or SHOW SECURITY to see if there are ACLs on your files.) Other users are actively involved in creating and maintaining their own ACLs.
Using ACLs is optional. Although ACLs can enhance the security of objects in any installation through a more detailed definition of who is allowed what kind of access, users have to spend time creating and maintaining the ACLs.
You use the DCL commands SET SECURITY and SHOW SECURITY for creating and displaying ACLs, although the access control list editor (ACL editor) is an important utility for more extensive work.
Section 4.4 continues the discussion of ACLs and how to use them.
To see the security profile of any protected object, use the DCL command SHOW SECURITY. For example, the following command requests security information about the file 93_FORECAST.TXT:
$ SHOW SECURITY 93_FORECAST.TXT
WORK_DISK$:[GREG]93_FORECAST.TXT;1 object of class FILE
Owner: [ACCOUNTING,GREG]
Protection: (System: RWED, Owner: RWED, Group: RE, World)
Access Control List: <empty>
The display indicates the file 93_FORECAST.TXT is owned by user Greg. It also lists the file's protection code, which gives read, write, execute, and delete access to system users and the owner. The code grants read and execute access to group users and provides no access to world users. (See Section 4.5 for further explanation.) There is no ACL on the file as yet.
You can provide new values for the owner, protection code, or ACL of a protected object or even copy a profile from one object to another by using the SET SECURITY command.
For example, the SHOW SECURITY display in Section 4.2.3 shows the file 93_FORECAST.TXT is owned by user Greg. As owner, he can change the protection code for that file. Originally, the code gave no access to users in the world category. Now, Greg changes that to allow read and write access to world users:
$ SET SECURITY/PROTECTION=(W:RW) 93_FORECAST.TXT
The SHOW SECURITY command verifies the new protection code for the file:
$ SHOW SECURITY 93_FORECAST.TXT
93_FORECAST.TXT object of class FILE
Owner: [GREG]
Protection: (System: RWED, Owner: RWED, Group: RE, World: RW)
Access Control List: <empty>
Section 4.2.5 shows how to modify other elements in a profile. Section 4.4 and Section 4.5 discuss protection codes and ACLs extensively. For a full description of the SET SECURITY and SHOW SECURITY commands, see the OpenVMS DCL Dictionary.
Groups of objects that behave in a particular way and have a common set of attributes are subset into classes. Files, queues, and volumes are very common examples. As Table 4-2 shows, the operating system supports 11 classes of protected objects.
When you modify the profile of an object, you need to specify the class of the object; otherwise, the SET SECURITY command assumes the object is a file.
For example, the following command sequence changes the profile of an object and uses the /CLASS qualifier to identify the object LNM$GROUP as a logical name table:
$ SET SECURITY /CLASS=LOGICAL_NAME_TABLE- _$ /OWNER=ACCOUNTING /PROTECTION=(S:RWCD, O:RWCD, G:R, W:R)- _$ /ACL=((IDENTIFIER=CHEKOV,ACCESS=CONTROL),- _$ (IDENTIFIER=WU,ACCESS=READ+WRITE)) LNM$GROUP
The SET SECURITY command makes the Accounting group owner of the logical name table. It changes the protection code to allow read, write, create, and delete access for the owner and for system users and to limit group and world users to read access. Finally, it creates an ACL to allow control access for user Chekov and to allow read and write access for user Wu.
The SHOW SECURITY command displays the results of the changes.
$ SHOW SECURITY LNM$GROUP /CLASS=LOGICAL_NAME_TABLE
LNM$GROUP object of class LOGICAL_NAME_TABLE
Owner: [ACCOUNTING]
Protection: (System: RWCD, Owner: RWCD, Group: R, World: R)
Access Control List:
(IDENTIFIER=[USER,CHEKOV],ACCESS=CONTROL)
(IDENTIFIER=[USER,WU],ACCESS=READ+WRITE)
| 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. |
6346P004.HTM OSSG Documentation 22-NOV-1996 13:04:54.94
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.