OpenVMS System Manager's Manual

Document revision date: 30 March 2001

OpenVMS System Manager's Manual

Contents

Index

12.4 Understanding Ways to Protect Objects

The OpenVMS operating system offers two primary protection mechanisms. The first, UIC-based protection, is based on the user identification code (UIC) and is applied to all protected objects.

The second protection mechanism uses access control lists (ACLs), which employ a more refined level of protection than that available with UIC-based protection. ACLs can be used to grant or deny access to individual users or groups of users.

12.4.1 Interpreting a User Identification Code

Your user identification code (UIC) tells what group you belong to and what your unique identification is within that group.

The Authorize utility assigns each user process in the system a unique UIC in the user authorization file (UAF). Each object on the system is also associated with a UIC (typically the UIC of its creator).

A UIC consists of two parts, group and member, specified in the following format:

[group,member]

A UIC can be either numeric or alphanumeric. A numeric UIC consists of a group number in the range 0 through 37776 (octal) and a member number in the range 0 through 177776 (octal). Compaq reserves group 1 and groups 300--377.

12.4.2 Understanding Protection Codes

A protection code controls the type of access allowed (or denied) to a particular user or group of users. It has the following format:

[user category: list of access allowed (, user category: list of access allowed,...)]

user category

User categories include system (S), owner (O), group (G), and world (W). Each category can be abbreviated to its first character. Categories have the following definitions:

System: Members of this category can include any of the following users:
- Users with low group numbers, usually from 1 to 10 (octal). These group numbers are generally for system managers, security administrators, and system programmers. (The exact range of system group numbers is determined by the security administrator in the setting of the system parameter MAXSYSGROUP. It can range as high as 37776 (octal).)
- Users with the SYSPRV privilege.
- Users with the GRPPRV privilege whose UIC group matches the UIC group of the object's owner.
- In access requests to files on a disk volume, users whose UIC matches the UIC of the volume's owner.
Owner: The user with the same UIC as the user who currently owns the object. In general, the creator of an object is entitled to owner access unless explicit action is taken to secure the object from its creator.
Group: All users who are in the same UIC group as the object's owner.
World: All users, including those in the first three categories.

When specifying more than one user category, separate the categories with commas, and enclose the entire code in parentheses. You can specify user categories and access types in any order.

A null access specification means no access, so when you omit an access type for a user category, that category of user is denied that type of access. To deny all access to a user category, specify the user category without any access types. Omit the colon after the user category when you are denying access to a category of users.

When you omit a user category from a protection code, the current access allowed that category of user remains unchanged.

access-list

Access types are object-dependent and are described in the OpenVMS Guide to System Security. For files, the access types include read (R), write (W), execute (E), and delete (D). The access type is assigned to each user category and is separated from its user category by a colon (:).

Example

The protection code in the following example allows system users full access to an object, the owner full access except delete, and group and world users no access:

$ SET SECURITY/PROTECTION=(S:RWED,O:RWE,G,W) [JONES]MY_FILE.TXT

How to Change the Default Protection

The operating system provides each process with a default UIC-based protection of (S:RWED,O:RWED,G:RE,W). To change the default protection, enter the SET PROTECTION/DEFAULT command, as shown in the following example:

$ SET PROTECTION=(S:RWED,O:RWED,G:RE,W:RE)/DEFAULT

12.5 Creating Intra-Cluster Communications Security Objects

OpenVMS provides SYS$MANAGER:ICC$SYSTARTUP.COM. This command procedure allows you to customize the ICC characteristics by creating ICC security objects and adding additional registry tables.

The ICC$CREATE_SECURITY_OBJECT procedure creates permanent ICC security objects and optionally issues an initial SET SECURITY command for the object. Specify node::association to create a security object for an association before it exists. For example, specify MYNODE::BOB_SERVER. Use the special node name ICC$ to create a security object for an entry in the ICC clusterwide registry.

Before creating an association through ICC, you need the OPEN security attribute on the node::association pair. A security object created by ICC$CREATE_SECURITY_OBJECT is not deleted until the system reboots.

The ability to connect to an association is controlled by the ACCESS security attribute on the security object.

Every process using ICC must open an association. If you have SYSNAM privilege, you can open associations without calling ICC$CREATE_SECURITY_OBJECT, however the object is not permanent. No privileges are required, therefore anyone can create access named ICC$pid* (for example, ICC$20203F9A_FOO).

ICC$CREATE_SECURITY_OBJECT can also be used to regulate creating names in the ICC clusterwide registry using the special node name ICC$. For creating names in the registry, the security access attributes OPEN and CONTROL are relevant.

Note that SYS$MANAGER: also contains file SYS$SYSTARTUP.TEMPLATE so that you can customize the procedure to your specific requirements.

12.6 Creating Access Control Lists

For most interactive user accounts, the default UIC-based protection is adequate. However, in some cases (such as project accounts) you may want to set up an additional level of protection by using access control lists (ACLs). ACL-based protection provides a more refined level of security in cases where different groups or members of overlapping groups share access to an account.

12.6.1 Kinds of Entries in an ACL

An access control list (ACL) is a list of entries, each of which defines some attribute of an object. Each entry is called an access control entry (ACE).

The following security-relevant types of ACEs are available:

ACE Description

Identifier ACE Controls the types of access allowed to specific users based on the user's identification. Each Identifier ACE includes one or more rights identifiers and a list of the types of access the user holding the identifier has permission to exercise. See Section 12.6.2 for a summary of identifiers.
For example, the following ACE grants the user Jones read, write, and execute access to an object:
(IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE)

Default Protection ACE Allows you to specify a protection code for a directory file that is propagated to all files created within that directory and its subdirectories.
For example, the following ACE assigns a protection code to newly created files in a directory. The code gives users in the system and owner categories full access, it gives group users both read and execute access, and it denies access to users in the world category.
(DEFAULT_PROTECTION,S:RWED,O:RWED,G:RE,W:)

Creator ACE Adds an extra ACE to the ACL of a file created within the directory to which you assign the Creator ACE. The Creator ACE applies when the file being created is not owned by the user identification code (UIC) of the process creating the file, such as when the directory is owned by a resource identifier.
The following ACE, for example, specifies that any user creating a file in the directory will receive read, write, execute, and delete access to it:
(CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE)

The Creator ACE applies to directory files only.

Security Alarm ACE Allows you to request that a security alarm message be sent to the operator's terminal if an object is accessed in a particular way.
For example, the following ACE causes an alarm message whenever a particular file is successfully read:
(ALARM=SECURITY,ACCESS=SUCCESS+READ)

The security Alarm ACE has no effect unless ACL alarms are enabled with the following command:
$ SET AUDIT/ALARM/ENABLE=(ACL)

Security Audit ACE Specifies the access criteria that cause a security alarm message be sent to the system security audit log file if an object is accessed in a particular way.
For example, the following ACE causes an alarm message whenever a particular file is successfully read:
(AUDIT=SECURITY,ACCESS=SUCCESS+READ)

A message is recorded only if ACL audits are enabled with the DCL command SET AUDIT/AUDIT/ENABLE=ACL.

Subsystem ACE Grants additional identifiers to a process while it is running the image to which the Subsystem ACE applies. Users with execute access to the image can access objects that are in the protected subsystem, such as data files and printers, but only when they run the subsystem image. The Subsystem ACE applies to executable images only.
For example, the following ACE adds the identifier ACCOUNTING to processes that are executing a particular subsystem image. The identifier entitles the processes to access objects owned by the subsystem.
(SUBSYSTEM, IDENTIFIER=ACCOUNTING)

ACE	Description
Identifier ACE	Controls the types of access allowed to specific users based on the user's identification. Each Identifier ACE includes one or more rights identifiers and a list of the types of access the user holding the identifier has permission to exercise. See Section 12.6.2 for a summary of identifiers. For example, the following ACE grants the user Jones read, write, and execute access to an object: (IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE)
Default Protection ACE	Allows you to specify a protection code for a directory file that is propagated to all files created within that directory and its subdirectories. For example, the following ACE assigns a protection code to newly created files in a directory. The code gives users in the system and owner categories full access, it gives group users both read and execute access, and it denies access to users in the world category. (DEFAULT_PROTECTION,S:RWED,O:RWED,G:RE,W:)
Creator ACE	Adds an extra ACE to the ACL of a file created within the directory to which you assign the Creator ACE. The Creator ACE applies when the file being created is not owned by the user identification code (UIC) of the process creating the file, such as when the directory is owned by a resource identifier. The following ACE, for example, specifies that any user creating a file in the directory will receive read, write, execute, and delete access to it: (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE) The Creator ACE applies to directory files only.
Security Alarm ACE	Allows you to request that a security alarm message be sent to the operator's terminal if an object is accessed in a particular way. For example, the following ACE causes an alarm message whenever a particular file is successfully read: (ALARM=SECURITY,ACCESS=SUCCESS+READ) The security Alarm ACE has no effect unless ACL alarms are enabled with the following command: $ SET AUDIT/ALARM/ENABLE=(ACL)
Security Audit ACE	Specifies the access criteria that cause a security alarm message be sent to the system security audit log file if an object is accessed in a particular way. For example, the following ACE causes an alarm message whenever a particular file is successfully read: (AUDIT=SECURITY,ACCESS=SUCCESS+READ) A message is recorded only if ACL audits are enabled with the DCL command SET AUDIT/AUDIT/ENABLE=ACL.
Subsystem ACE	Grants additional identifiers to a process while it is running the image to which the Subsystem ACE applies. Users with execute access to the image can access objects that are in the protected subsystem, such as data files and printers, but only when they run the subsystem image. The Subsystem ACE applies to executable images only. For example, the following ACE adds the identifier ACCOUNTING to processes that are executing a particular subsystem image. The identifier entitles the processes to access objects owned by the subsystem. (SUBSYSTEM, IDENTIFIER=ACCOUNTING)

Refer to the OpenVMS System Management Utilities Reference Manual for a complete description of each kind of ACE. The OpenVMS Guide to System Security provides further details on how to construct and apply ACEs.

12.6.2 Types of Identifiers

An Identifier ACE can contain different types of identifiers. Any of these identifiers is an alphanumeric string of 1 to 31 characters with at least one alphabetic character. Valid characters include numbers 0 to 9, characters A to Z, the dollar sign ($), and the underscore (_). The following table lists each type of identifier: `

Type Description Example

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. [GROUP1,JONES]
[JONES]
GROUP1
JONES

General identifiers Defined by the security administrator. SALES
RESERVE_DESK

Environmental identifiers Describe different types of users based on their initial entry into the system. These identifiers are automatically created by the system. BATCH, NETWORK
INTERACTIVE
LOCAL, DIALUP
REMOTE

Facility identifiers Defined by a facility during installation RDB$ENTRY

Type	Description	Example
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.	[GROUP1,JONES] [JONES] GROUP1 JONES
General identifiers	Defined by the security administrator.	SALES RESERVE_DESK
Environmental identifiers	Describe different types of users based on their initial entry into the system. These identifiers are automatically created by the system.	BATCH, NETWORK INTERACTIVE LOCAL, DIALUP REMOTE
Facility identifiers	Defined by a facility during installation	RDB$ENTRY

In addition to the environmental identifiers, a system node identifier of the form SYS$NODE_node_name is created by the system startup procedure (STARTUP.COM in SYS$SYSTEM).

12.7 Assigning ACLs

You can place ACLs on the following object classes:

Capability
Common event flag cluster
Device
File
Group global section
Logical name table
Queue
Resource domain
Security class
System global section
Volume

Typically, ACLs are used when you want to provide access to an object for some, but not all, users, or if you want to deny access to specific, unprivileged users. When the operating system receives a request for access to an object having an ACL, it searches each access control list entry in the ACL, stopping at the first match. If another match occurs in the ACL, it has no effect. Therefore, ACEs granting or denying access to a protected object for specific users should appear in the ACL before ACEs identifying broader classes of users.

12.8 Using the ACL Editor

The access control list editor (ACL editor) is a screen-oriented editor used to create and maintain ACLs. Use the ACL editor to define an ACL for a protected object or to edit an existing ACL.

You can use either the EDIT/ACL command or the SET SECURITY/EDIT command to invoke the ACL editor. In the command line, specify the name of the object whose ACL you want to create or modify. For example, the following command invokes the ACL editor to create an ACL for the file INVENTORY.DAT:

$ EDIT/ACL INVENTORY.DAT

If the object whose ACL you want to create or modify is not a file, you must specify the type of object with the /CLASS qualifier. For example, the following command invokes the ACL editor to create an ACL for the disk DOCD$:

$ EDIT/ACL/CLASS=DEVICE DOCD$

You can invoke the ACL editor to modify an existing ACL or to create a new ACL on the object. If an object has an ACL, the ACL will appear on the screen when the ACL editor is invoked.

The ACL editor can be invoked from within a program written in any OpenVMS common language that generates calls using the OpenVMS calling standard. Refer to the OpenVMS Utility Routines Manual for more information about using the callable interface to the ACL editor.

12.8.1 Adding an Identifier ACE

An Identifier ACE controls the types of access allowed to a particular user or group of users. It has the following format:

(IDENTIFIER=identifier[,options][,access])

For example, the following ACE grants user Pat, who is identified by the UIC identifier [SALES,PAT], read, write, and execute access to a file. The ACL denies Pat delete and control access because it omits them from the access statement.

(IDENTIFIER=[SALES,PAT],ACCESS=READ+WRITE+EXECUTE)

The Default attribute of an Identifier ACE allows users to define one or more default ACEs for inclusion in the ACLs for newly created files in a particular directory. Thus, if you wanted all files in the directory [MALCOLM] to have an ACE that permitted read and write access to users with the PERSONNEL identifier, you could include the following ACE in the ACL for the file MALCOLM.DIR:

(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE)

As a result of this ACE, any file created in the [MALCOLM] directory has the following ACE:

(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)

Refer to the OpenVMS Guide to System Security for further discussion of the Default attribute and its effect on the processing of an ACL.

12.8.2 Setting a Default Protection Code

A Default Protection ACE defines a protection code for all files that are subsequently created in the directory and in any subdirectories under that directory, unless protection is specified for one of those files individually. The ACE does not apply if a previous version of the file exists (in this case, the previous file protection is used). This ACE type has the following format:

(DEFAULT_PROTECTION[,options],protection-code)

For example, the following ACE specifies that users in the system and owner categories have read, write, execute, and delete access to any files subsequently created in the directory, and that group and world users have no access:

(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W)

Note

The Default Protection ACE does not apply to existing subdirectories. It applies to subdirectories created after the ACE is applied to the parent directory.

12.8.3 Generating Security Alarms and Audits

Security ACEs allow you to specify that an event message be sent when a protected object is accessed in a particular manner. The security Alarm ACE directs the event message to the security operator's terminal and the security Audit ACE directs the event message to the system security audit log file.

Refer to the OpenVMS Guide to System Security for more information about how to use these types of ACEs.

12.9 Auditing Security-Relevant Events

System managers can select the destination for security-relevant event messages. Alarm messages are sent to the operator's terminal and audit messages are sent to the system security audit log file. You can choose to have an event reported as an alarm, as an audit, or as both.

12.9.1 Enabling Classes of Security Alarms

The OpenVMS operating system automatically monitors a certain number of events, as listed in Table 20-7.

You can enable additional classes of events by listing one or more of the keywords of the /ENABLE qualifier to the DCL command SET AUDIT listed in Table 12-1.

Table 12-1 Kinds of Security Events OpenVMS Can Report
Event Class Description

Access Specifies access events for all objects in a class. You can audit selected types of access, both privileged and nonprivileged, to all protected objects of a particular class.

ACL Events requested by a security Audit or Alarm ACE in the access control list (ACL) of an object.

Authorization Modification of any portion of SYSUAF.DAT, NETPROXY.DAT, NET$PROXY.DAT, or RIGHTSLIST.DAT.

Breakin Break-in attempts.

Connection Logical link connections or terminations through SYSMAN, DECnet for OpenVMS Phase IV, DECwindows products, or an interprocess communication (IPC) call.

Create Creation of a protected object.

Deaccess Deaccess from a protected object.

Delete Deletion of a protected object.

Identifier Use of identifiers as privileges.

Install Modifications made to the known file list through the Install utility.

Logfailure Failed login attempts.

Login Successful login attempts.

Logout Logouts.

Mount Volume mounts and dismounts.

NCP Modification to the network configuration database, using the network control program (NCP).

Privilege Successful or unsuccessful use of privilege.

Process Use of one or more of the process control system services.

SYSGEN Modification of a system parameter with the System Generation utility (SYSGEN) or AUTOGEN.

Time Modification of system time.

**Table 12-1 Kinds of Security Events OpenVMS Can Report**
Event Class	Description
Access	Specifies access events for all objects in a class. You can audit selected types of access, both privileged and nonprivileged, to all protected objects of a particular class.
ACL	Events requested by a security Audit or Alarm ACE in the access control list (ACL) of an object.
Authorization	Modification of any portion of SYSUAF.DAT, NETPROXY.DAT, NET$PROXY.DAT, or RIGHTSLIST.DAT.
Breakin	Break-in attempts.
Connection	Logical link connections or terminations through SYSMAN, DECnet for OpenVMS Phase IV, DECwindows products, or an interprocess communication (IPC) call.
Create	Creation of a protected object.
Deaccess	Deaccess from a protected object.
Delete	Deletion of a protected object.
Identifier	Use of identifiers as privileges.
Install	Modifications made to the known file list through the Install utility.
Logfailure	Failed login attempts.
Login	Successful login attempts.
Logout	Logouts.
Mount	Volume mounts and dismounts.
NCP	Modification to the network configuration database, using the network control program (NCP).
Privilege	Successful or unsuccessful use of privilege.
Process	Use of one or more of the process control system services.
SYSGEN	Modification of a system parameter with the System Generation utility (SYSGEN) or AUTOGEN.
Time	Modification of system time.

Refer to the OpenVMS DCL Dictionary for more information about the SET AUDIT command.

Contents

Index

privacy and legal statement

6017PRO_053.HTML