Document revision date: 19 July 1999

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.

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

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

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

The following example contains the ICC$SYSSTARTUP.COM command procedure.

11.5.1 Example of ICC Startup Commands

$! Copyright (c) 1998 Compaq Computer Corporation. All rights reserved. $! $! ICC$SYSTARTUP.COM -- ICC Startup Commands Specific to Site $! $! Use this command procedure to customize the ICC characteristics for $! the local node. The default setup in ICC$STARTUP has already been $! done when ICC$SYSTARTUP is called. Refer to ICC$SYSTARTUP.TEMPLATE $! to see the original state of this file prior to local editing. $! $! Remove this comment and the following line (exit) to activate this $! procedure after changing the example code to be relevant to your site. $ exit $! $! Most of the customization will consist of calls to $! @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT $! and $! @SYS$MANAGER:ICC$ADD_REGISTRY_TABLE $! $! We think very few installations will need to add extra registry tables. $! This example only shows setup for security objects. $! $! We set two servers up. User BOB may start BOB_SERVER on any node in $! the cluster. Initially no other users may access (connect to) his $! server, but since he is the owner of the security object, he may $! add ACLs of his own as and if he wishes. $! $! User BILL may start up to three copies of BILL_SERVER on the major $! nodes in the cluster, but only one copy on NODE3 and none on NODE4. $! The system owns his security object, and in this example, we did not $! give him control access (the ability to issue SET SECURITY commands) $! to the object. All users are allowed to access (connect to) it. $! $! Both users are allowed to create Clusterwide Registry entries for $! their service. In this example, the system owns these objects. $! Note that for registry entires, only "OPEN" access is relevant; $! all users may look associations up in the registry subject to $! the registry table protection; actual access to the server is $! controlled by the server's, not the association's, security object. $! Also note that in a running cluster, the security object table $! for registry entries (ICC$::) is not reinitialized, and calls to $! CREATE_SECURITY_OBJECT fail "gracefully" with SS$_DUPLNAM without $! doing any modifications to the security profile. $! $! We also give both server users WRITE access to the clusterwide $! logical table ICC$REGISTRY_TABLE to allow their registry entries $! to be created when servers start up. (Registry entries are EXEC $! mode, and cannot be directly manipulated by non-privileged users, $! even when they have write access to the table.) $! $ set noon $ required_privileges = "SYSNAM" $ prev_privs = f$setprv(required_privileges) $ if .not. f$privilege(required_privileges) then goto no_privileges $! $! --------------------- Get Local Node Name ------------------------ $! $ nodename=f$edit(f$getsyi("scsnode"),"trim") $ if nodename .eqs. "" then nodename = "LOCAL" ! no name assigned to node $! $! --------------------- Do work required on all nodes ------------------- $! $! Place in here calls to @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT and $! @SYS$MANAGER:ICC$ADD_REGISTRY_TABLE that apply to all nodes in the $! cluster. $! $ @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT 'nodename'::BOB_SERVER - "/owner=BOB/prot=(group,world)" $! $ @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT ICC$::BOB_SERVICE - "/acl=(id=BOB,access=open)" $ set security/class=logical_name_table icc$registry_table - /acl=(id=BOB,access=read+write) $! $ @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT ICC$::BILL_SERVICE - "/acl=(id=BILL,access=open)" $ set security/class=logical_name_table icc$registry_table - /acl=(id=BILL,access=read+write) $! $! --------------------- List Nodes with Special Actions ------------------- $! $ nodeactions = "/NODE1/NODE2/NODE3/NODE4/" $ if f$locate("/"+nodename+"/",nodeactions) .eq. f$length(nodeactions) - then goto exit ! No action for this node $ goto 'nodename' ! Go to action code for this node $! $! -------------------- Major Nodes ---------------------- $NODE1: $NODE2: $! $! Place in here calls to @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT and $! @SYS$MANAGER:ICC$ADD_REGISTRY_TABLE that apply to major nodes in the $! cluster $! $ @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT 'nodename'::BILL_SERVER1 - "/acl=(id=BILL,access=open+access)" $ @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT 'nodename'::BILL_SERVER2 - "/acl=(id=BILL,access=open+access)" $ @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT 'nodename'::BILL_SERVER3 - "/acl=(id=BILL,access=open+access)" $! $ GOTO EXIT $! $! ------------------------- Other Nodes ----------------------------- $! $NODE3: $! $! Place in here calls to @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT and $! @SYS$MANAGER:ICC$ADD_REGISTRY_TABLE that apply to other nodes. $! $ @SYS$MANAGER:ICC$CREATE_SECURITY_OBJECT 'nodename'::BILL_SERVER1 - "/acl=(id=BILL,access=open+access)" $! $ GOTO EXIT $! $NODE4: $! $ GOTO EXIT $! $! $exit: $ prev_privs = f$setprv(prev_privs) $ exit $! $no_privileges: $ write sys$output "Insufficient privileges to execute ICC setup commands." $ write sys$output "Requires ",required_privileges," privileges." $ goto exit

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

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

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

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

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

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

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

	privacy and legal statement
6017PRO_052.HTML