|
HP OpenVMS Systems Documentation |
|
OpenVMS System Manager's Manual
12.4 Understanding Ways to Protect ObjectsThe 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.
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:
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.
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 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:
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 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 (:). 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:
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:
12.5 Creating Intra-Cluster Communications Security ObjectsOpenVMS 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.
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.
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:
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.
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: `
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).
You can place ACLs on the following object classes: Capability
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.
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:
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$:
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.
An Identifier ACE controls the types of access allowed to a particular user or group of users. It has the following format:
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.
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:
As a result of this ACE, any file created in the [MALCOLM] directory has the following ACE:
Refer to the OpenVMS Guide to System Security for further discussion of the Default
attribute and its effect on the processing of an ACL.
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:
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:
12.8.3 Generating Security Alarms and AuditsSecurity 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.
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.
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.
Refer to the OpenVMS DCL Dictionary for more information about the SET AUDIT command.
|