Document revision date: 19 July 1999

Appendix A lists all user privileges and includes recommendations on when to grant them. When allocating user privileges, be conservative.

The summary guidelines in Table 8-3 indicate the minimum privilege requirements for common classes of system users.

Table 8-3 Minimum Privileges for System Users

Type of User	Minimum Privileges
General	TMPMBX, NETMBX
Operator	OPER
Group manager	GROUP, GRPPRV
System manager/administrator	SYSPRV, OPER, SYSNAM, CMKRNL+
Security administrator	SECURITY, AUDIT, READALL

Granting privileges allows users those privileges until you remove them. To avoid such blanket permission, you may want to grant privileges on an as-needed basis. For example, certain users may need to run a program requiring one of the more powerful privileges. You can install the program with the necessary privilege by using the Install utility (INSTALL). Section 8.7.4 discusses installing privileged images in more detail.

An alternative to granting blanket privileges is to set up emergency or specialized privileged accounts. Users would log in to these privileged accounts only to perform specific functions. You have two options with this technique:

• Establish a limited group of users who know about the account and are informed how to use it.
• Create two accounts for the user, giving the privileges to one account but not to the other. In this case, the user would have the same UIC and the same default directory in each account. (This is the only case where Compaq recommends shared UICs, because there is still only one actual user.) If you decide to adopt this dual account practice, avoid obvious user names that reveal which account is the privileged account.

With both options, you can place special restrictions on the privileged account, such as long passwords, brief password lifetimes, restricted hours, and limited modes of operation (no dialup, network, remote, or batch logins). In addition, limited account durations would force frequent consideration of privilege requirements.

Yet another alternative is to use protected subsystems, which are described in Chapter 13, and thereby eliminate the need for any system privileges.

8.7.4 Installing Images with Privilege

A user cannot execute an image that requires a privilege the user does not possess unless the image is installed as a known image with the privilege in question. (See the OpenVMS System Management Utilities Reference Manual for instructions on installing known images.) Execution of a known image with privileges grants those privileges to the user process executing the image for the duration of the image's execution. Thus, you should install images with amplified privileges (other than the normal Compaq-supplied configuration) only after ensuring that the privileges are required by the image's function and that the image operates safely. Also consider restricting access to the image to a selected set of users.

Images installed with privileges are activated with all amplified privileges enabled. For maximum safety, images designed to run with amplified privilege should use the $SETPRV system service to disable all amplified privileges immediately on activation, and enable them only when they are needed.

Following is an example of installing an image with privilege. The System Dump Analyzer utility (SDA) requires CMKRNL privilege to analyze the running system.

1. Install SDA.EXE with the CMKRNL privilege, as follows:

   $ INSTALL SDA.EXE /PRIVILEGED=CMKRNL

2. Place an ACL on SDA.EXE, and also set the UIC-based protection to deny all access to the world category of users, as follows:

   $ SET SECURITY/ACL=(IDENTIFIER=SDA,ACCESS=EXECUTE)- _$ SYS$SYSTEM:SDA.EXE $ SET SECURITY/PROTECTION=(WORLD) SYS$SYSTEM:SDA.EXE

3. Use the AUTHORIZE command to confirm that the users who hold the SDA identifier are those intended to run the program. If necessary, make adjustments to this list of users.

   Note All images that you install with privilege must be linked with the /NOTRACEBACK qualifier to prevent online debugging and traceback. Compaq ensures that all system programs that are supplied with the operating system (such as the SDA) are linked with the /NOTRACEBACK qualifier to prevent online debugging or traceback.

Some DCL commands behave differently depending on the privileges that the user holds.

For example, unless a user holds the GROUP or WORLD privilege, the SHOW PROCESS command limits the display of process information to the user's process. A user with GROUP privilege can display other processes in the user's UIC group; a user with WORLD privilege can display any process on the system.

8.8 Setting Default Protection and Ownership

After designing user groups and identifiers, you need to address which protected objects your users need permission to access and which ones can be unrestricted. Become familiar with the default protection of new objects, shown in Chapter 5, and when necessary modify the defaults, as shown in the following sections.

The procedure for setting up object protection and ownership defaults varies, depending on whether the object is a file or another class of protected object.

8.8.1 Controlling File Access

As Section 5.4.5 explains, there are four possible areas where you can specify protection defaults that would affect the user. In order of increasing influence, they are as follows:

• The system parameter RMS_FILEPROT sets the systemwide default for file protection. You can change the value of RMS_FILEPROT with AUTOGEN. However, the effectiveness of this value may be overridden by any of the following defaults.
• The DCL command SET PROTECTION/DEFAULT can specify the file protection placed on files created or modified by the user during the terminal session. While the command typically appears in the user's login command procedure, the user can also enter this command at any time during a session to override the value set by a previous SET PROTECTION/DEFAULT command. The SET PROTECTION/DEFAULT command negates the influence of the systemwide protection for this user.
• The default protection for the specific directory can be specified in an ACL applied to the directory. If a Default Protection ACE exists for the directory, all new files added to the directory, including subdirectories and their files, are subject to this protection code. This code overrides the systemwide default and the user-specified default (if any).
• In special cases where the file being created is not owned by the user identification code (UIC) of the process creating the file (for example, when a directory is owned by a resource identifier), the default protection for the new file can be modified by a Creator ACE within the directory's ACL. Refer to Section 5.4.5 for a discussion of the Creator ACE.

Also consider the protection imposed on the volume through the DCL command SET VOLUME/PROTECTION. This protection code, if specified, prevents a user from accessing any part of the volume, regardless of the protection code on the directory or the file. If no volume protection is specified with the SET VOLUME command, the volume is accessible to all users.

The assignment of file ownership affects the outcome of any protection check. The operational effect of this combined protection structure is depicted in Figure 8-1.

Figure 8-1 Flowchart of File Creation

You may want to make adjustments to control default behavior. The systemwide default protection code specified by the system parameter RMS_FILE PROT sets the user's default protection to the following:

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

Assume that the volume protection has been set by the operator to the following:

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

The file protection on the directory [PROJECT] has been set to the following:

(S:RWED,O:RW,G:R,W)

If all the files created in the subdirectory [PROJECT.DIARY] demand more protection, you, or any user who has control access to the directory, could define a specific default protection code for this specific directory with an ACL consisting of a Default Protection ACE, as follows:

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

The following DCL command would provide the desired default protection:

$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED)- _$ [PROJECT]DIARY.DIR

Once this ACE is placed on the directory file, files created or modified in the directory are subject to the default protection code. Because these protection codes are only defaults, a user who has control access to a file in the directory can include a specific protection code as a replacement for the default value on the file by using the following DCL commands:

• SET SECURITY/PROTECTION
• COPY/PROTECTION
• APPEND/PROTECTION
• CREATE/PROTECTION

Once the default protection code is replaced, the new code becomes the default and is propagated to subsequent versions of the file.

If you provide a special login command procedure for some of your users, you may want to supplement the systemwide default process protection specified by the system parameter RMS_FILEPROT for this group of users. Add the SET PROTECTION/DEFAULT command to the login command procedure to specify the default process protection, as follows:

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

Files created in users' directories receive this default protection code unless explicitly overridden.

8.8.1.2 Setting Defaults for a Directory Owned by a Resource Identifier

To allow for more flexible data management as well as more accurate accounting of disk space, you can set up a directory that is owned by a resource identifier and rely on ACLs to control access to the directory and to files created within it.

The ACL can limit file access to all project members holding the project identifier. To achieve this kind of access restriction, you add an Identifier ACE to define the group's access to files. A second Identifier ACE is added that duplicates the first but holds the Default attribute. It is the Default attribute that ensures the ACE is copied to all files created within the directory. Sometimes a third ACE is necessary---a Default Protection ACE, depending on the default protection code for the directory. A Default Protection ACE establishes the protection code for the directory's files. (As Section 4.3 explains, if an ACL denies access to a file, it is still possible to gain access through a protection code.)

In addition to limiting the group's access to files, an ACL can control the type of access users have to files that they have created within the common directory. Because the file is created in the resource identifier's directory, the resource identifier owns the file. For users to access files they have created, the operating system normally gives control access to the file's creator plus the access specified in the owner field of the protection code. However, you can modify this behavior by adding a Creator ACE to the directory's ACL. A Creator ACE defines the type of access users have to files they have created in the project's directory.

8.8.1.2.1 Setting Up the Resource Identifier

A security administrator used the following command sequence to set up the project identifier PROJECTX and grant it to members of the project. Notice that the identifier is added to the rights database with the resource identifier, and it is also granted to users with the resource identifier. The project identifier needs to carry the Resource attribute so it can own disk space.

$ RUN SYS$SYSTEM:AUTHORIZE UAF> ADD/IDENTIFIER PROJECTX /ATTRIBUTES=RESOURCE UAF> GRANT/IDENTIFIER PROJECTX user1 /ATTRIBUTES=RESOURCE UAF> GRANT/IDENTIFIER PROJECTX user2 /ATTRIBUTES=RESOURCE . . .

8.8.1.2.2 Setting Up the Directory of a Resource Identifier

When a project- or department-specific identifier is the owner of a directory, the space used by files created in the directory can be charged to the appropriate department or project rather than to the individual who creates them. When users work on multiple projects, they can charge their disk space requirements to the related project rather than to their personal accounts.

In setting up a directory for a resource identifier, you first create the disk quota authorization for the project identifier. For example, the following command invokes the System Management utility (SYSMAN) and assigns the identifier PROJECTX 2000 blocks of disk quota with 200 blocks of overdraft:

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA ADD PROJECTX /PERMQUOTA=2000 /OVERDRAFT=200

After setting up the disk quota, you create the project directory. For example, the following DCL command creates the project directory [PROJECTX] and establishes the identifier PROJECTX as its owner:

$ CREATE/DIRECTORY [PROJECTX] /OWNER=[PROJECTX]

8.8.1.2.3 Setting Up the ACL

In setting up the directory [PROJECTX], you use an ACL to provide file access to project members. The following example shows how several ACEs are used to define access:

$ SET SECURITY [PROJECTX] /ACL= (- _$ (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W),- (1) _$ (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE),- (2) _$ (IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE),- (3) _$ (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE)) (4)

1. The Default Protection ACE sets up a protection code for files created within the directory. The ACE denies access to group and world users.
2. The first Identifier ACE gives holders of the PROJECTX identifier read, write, and execute access to the directory.
3. The second Identifier ACE guarantees that all files created in the directory will carry the first Identifier ACE.
4. The Creator ACE specifies that a user who creates a file in the PROJECTX directory will receive read, write, execute, and delete access to it.

Thus, when project member Crandall creates the file SEPTEMBER-REPORTS.TXT in the [PROJECTX] directory, the file receives the following security profile:

$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT SEPTEMBER-REPORTS.TXT object of class FILE Owner: [PROJECTX] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=CRANDALL,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

Project members are not allowed to delete (or control) files created by others; however, the Creator ACE gives them delete access to files they have created.

Without a Creator ACE, project members each have complete access to files they have created in the directory. For example, Crandall would receive the following access to files created in the project directories:

$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT SEPTEMBER-REPORTS.TXT object of class FILE Owner: [CRANDALL] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=CRANDALL,OPTIONS=NOPROPAGATE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

To negate this behavior, you can add a Creator ACE to the ACL that specifies ACCESS=NONE.

8.8.2 Setting Defaults for Objects Other Than Files

With the exception of files, all classes of protected objects offer one or more template profiles that provide security elements for new objects. You can thus use a single mechanism to establish the default protection code, ACL, and ownership elements for objects. The operating system always stores these values so they are available from one system startup to the next. The SHOW SECURITY command displays the current default values for your particular site. Refer to Chapter 5 for a listing of the operating system's default values.

The operating system generates the security profiles of new objects from data stored by security class objects. These objects are all logical constructs used to keep track of such class elements as the valid access types, the templates, and the types of auditing that have been enabled. As Figure 8-2 shows, every class of protected object has a member in the security class. All members have a security profile template, except for files, which have their own rules.

Figure 8-2 Security Class Object

To display any class template, use the SHOW SECURITY/CLASS=SECURITY_CLASS command. The following command, for example, displays templates available for logical name tables. The logical name table object has the following three templates:

$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE . . . Template: GROUP Owner: [TTSY,SYSTEM] Protection: (System: RWCD, Owner: R, Group: R, World:R) Access Control List: <empty> Template: JOB Owner: [TTSY,SYSTEM] Protection: (System: RWCD, Owner: RWCD, Group, World) Access Control List: <empty> Template: DEFAULT Owner: [TTSY,SYSTEM] Protection: (System: RW, Owner: RW, Group, World) Access Control List: <empty>

All objects in the security class are protected in the same manner as other objects. For this reason, any SHOW SECURITY display of a security class object begins with the security profile for the object itself. The following display shows a profile for the logical name table object in the security class. The object is owned by the system, and its protection code allows read access to any user category but allows write access only to system and owner categories.

$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE LOGICAL_NAME_TABLE object of class SECURITY_CLASS Owner: [SYSTEM] Protection: (System: RW, Owner: RW, Group: R, World: R) Access Control List: <empty>

8.8.2.2 Modifying Class Templates

Security administrators and users with control access to a security class object can modify the elements of a given template with the following command:

SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=template-name

The following command modifies the MAILBOX template for the device class. It changes the template values from a protection of S:RWPL,O:RWPL,G:RWPL,W:RWPL to a protection that disallows group and world access.

$ SET SECURITY/CLASS=SECURITY_CLASS/TEMPLATE=MAILBOX - _$ /PROTECTION=(S:RWPL,ORWPL,G,W) DEVICE

The operating system applies this value to all new mailboxes. To change the protection for each existing mailbox, enter an explicit SET SECURITY command for each existing mailbox. For example:

$ SET SECURITY/CLASS=DEVICE - _$ /PROTECTION=(S:RWPL,ORWPL,G,W) mailbox_name

The operating system saves the default object protections specified in security templates, so rebooting the system automatically ensures that all objects created after the reboot are created with the new default protections.

	privacy and legal statement
6346PRO_019.HTML