HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
The group and member names can each contain up to 31 alphanumeric characters, at least one of which is alphabetic. The names can include upper- and lowercase characters A through Z, dollar signs ($), underscores (_), and the numbers 0 through 9.
The group number is an octal number in the range of 1 through 37776; the member number is an octal number in the range of 0 through 177776. You can omit leading zeros when you are specifying group and member numbers. Compaq reserves group 1 and groups 300--377 for its own use.
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, 1 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.
220.127.116.11 How Your Process Acquires a UIC
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 IMPERSONATE privilege, you can
create a detached process with a different UIC (by using the /UIC
qualifier of the RUN command).
4.1.6 Rights Identifiers
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
18.104.22.168 Types of Identifiers
The operating system supports several types of rights identifiers. Table 4-1 shows the identifiers that are most commonly used in access control.
|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.||
|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 (_).||
|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.||
|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).
22.214.171.124 Process and System Rights Lists
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. The system manager or the
system software grants identifiers to the system rights list that are
granted to all users currently logged on to the system.
126.96.36.199 Displaying the Rights Identifiers of Your Process
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 ordinarily would be denied to you. 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 DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPERSONATE 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
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:
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 using 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.