[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS Guide to System Security


Previous Contents Index


Chapter 4
Protecting Data

This chapter extends the discussion of security design introduced in Chapter 2. It describes how the operating system controls the way a user process or an application can access a protected object.

To summarize, the operating system controls access to any object that contains shareable information. These objects are known as protected objects. Devices, volumes, logical name tables, files, common event flag clusters, group and system global sections, resource domains, queues, capabilities, and security classes fall into this category. An accessing process carries credentials in the form of rights identifiers, and all protected objects list a set of access requirements specifying who has a right to access the object in a given manner.

This chapter:

Chapter 5 describes the unique features of each class of protected object.

4.1 Contents of a User's Security Profile


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:

4.1.1 Per-Thread Security

OpenVMS Alpha Version 7.2 includes the implementation of thread-level security. This feature, known as per-thread security, allows each execution thread of a multithreaded process to run an independent security profile without impacting the security profiles of other threads in the process.

Security profile information previously contained in various process level data structures and data cells is now stored in a single data structure, the Persona Security Block (PSB), which is then bound to a thread of execution. All associated references within OpenVMS have been redirected accordingly. Every process in the system has at least one PSB that is the natural persona of the process. The natural persona is created during process creation.

Interaction between a thread manager (for example, the thread manager incorporated within DECthreads) and the security subsystem provides for the automatic switching of profiles as threads are scheduled for execution.

4.1.2 Persona Security Block Data Structure (PSB)

The user's security profile (privileges, rights, and identity information) has shifted from the process level to the user thread level. The security information previously stored in several structures (including the Access Rights Block (ARB), Process Control Block (PCB), Process Header Descriptor (PHD), Job Information Block (JIB), and Control (CTL) region fields) has moved to a new Persona Security Block (PSB) data structure and all references are redirected accordingly. OpenVMS no longer uses some of the fields in these structures. The affected fields are now considered obsolete. (See the Obsolete Data Cells and New Location of Security Information table in the OpenVMS Version 7.2 Release Notes.)

Each process has a persona array containing the addresses of all persona blocks allocated to the process.

The new persona block (PSB) contains the following:

The kernel threads block (KTB) points to the persona block for the currently active thread.

4.1.3 Previous Security Model

In previous versions of OpenVMS, the information that constitutes a user's security profile was bound at the process level, common to all threads of execution within the process. Figure 4-1 illustrates this relationship.

Figure 4-1 Previous Per-Thread Security Model


Modifications made to the security profile by one thread are potentially visible to other threads, depending on how the threads perform profile management among themselves.

4.1.4 Per-Thread Security Model

In OpenVMS Version 7.2, each thread of execution can share a security profile with other threads or have a thread-specific security profile. Figure 4-2 illustrates these relationships.

Figure 4-2 Per-Thread Security Profile Model


As is the case in the previous model, modifications to a shared profile are potentially visible to all threads that share the profile. However, modifications made to a thread-specific security profile are only applicable to the particular thread.

4.1.5 User Identification Code (UIC)

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.

4.1.5.1 Format of a UIC

A UIC specification always appears in brackets, but its format can differ. Valid formats include the following:

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


1Only one user can have the member name JONES; therefore JONES must belong to the EXEC group.

4.1.5.2 Guidelines for Creating a UIC

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.

4.1.5.3 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 necessary.

4.1.6.1 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.

Table 4-1 Major Types of Rights Identifiers
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).

4.1.6.2 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. 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.

4.1.6.3 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:

  1. UIC identifier, indicating user Greg is a member of the DOC group
  2. Environmental identifier, indicating user Greg is an interactive user
  3. Environmental identifier, indicating user Greg is logged in locally
  4. General identifier, indicating user Greg is also a member of the SALES group
  5. General identifier, indicating Greg holds the MINDCRIME identifier with the resource attribute so he can charge disk space to the identifier
  6. Environmental identifier, indicating user Greg is working from the ACCOUNTS node

4.1.6.4 How Rights Identifiers Appear in the Audit Trail

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

4.1.7 Privileges

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 
 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 
Puterman can enable specific authorized privileges as he needs them; for example, he needs ALLSPOOL to allocate a spooled device and LOG_IO to perform logical I/O operations.

4.2 Security Profile of Objects


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.

4.2.1 Definition of a Protected Object

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.

4.2.2 Contents of an Object's Profile

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.


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6346PRO_005.HTML