![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Use the asterisk (*) wildcard to display all holders of all identifiers on the system, as follows:
UAF> SHOW/IDENTIFIER/FULL *
To display the identifiers held by a particular user, use the SHOW/RIGHTS command, as follows:
UAF> SHOW/RIGHTS/USER=ROBIN
Use the asterisk wildcard to display all identifiers held by all users, as follows:
UAF> SHOW/RIGHTS/USER=* UAF> SHOW/RIGHTS/USER=[*,*]
The first command displays users alphabetically. The second command displays users according to UICs.
You add identifiers to the rights list with the AUTHORIZE command ADD/IDENTIFIER, for example:
UAF> ADD/IDENTIFIER PAYROLL identifier PAYROLL value %X80080011 added to RIGHTSLIST.DAT
To grant users an identifier with any of the attributes described in Section 8.6.7, you must name that attribute when adding the identifier. For example, to allow users to add or modify an identifier, specify the Dynamic attribute:
UAF> ADD/IDENTIFIER PROJECT_TEAM1 /ATTRIBUTES=DYNAMIC
If you accidentally deleted the rights list and it cannot be recovered from a backup copy, recreate RIGHTSLIST.DAT by entering the CREATE/RIGHTS command, followed by the ADD/IDENTIFIER command, as follows:
UAF> CREATE/RIGHTS
{message}
UAF> ADD/IDENTIFIER/USER=* or ADD/IDENTIFIER/USER=[*,*]
{messages}
The ADD/IDENTIFIER command generates a UIC identifier in the rights list corresponding to each user name in SYSUAF.DAT. To complete the task, use the ADD/IDENTIFIER command to add all general identifiers that were lost. Then redefine the holders of the identifiers with GRANT/IDENTIFIER commands, as described in Section 8.6.4.
After adding identifiers, you associate users as holders of the existing identifiers by using the AUTHORIZE command GRANT/IDENTIFIER, as shown in the following example:
UAF> GRANT/IDENTIFIER PAYROLL MARTIN UAF-I-GRANTMSG, identifier PAYROLL granted to MARTIN UAF> GRANT/IDENTIFIER PAYROLL IPPOLITO UAF-I-GRANTMSG, identifier PAYROLL granted to IPPOLITO
To give user Martin the EXECUTIVE identifier in addition to the PAYROLL identifier would require another use of the GRANT/IDENTIFIER command. You can introduce only one holder association at a time with the GRANT/IDENTIFIER command.
In all cases shown above, AUTHORIZE associates the PAYROLL identifier with the UIC identifier corresponding to the user, specifically Martin and Ippolito. Both the identifiers must exist in the rights database.
When a user leaves the company, remove the UAF record for that user. Notify the managers of all sites where that user has access to proxy accounts to remove proxy access information in the remote node's NETPROXY.DAT file. When you run AUTHORIZE to remove a user's UAF record, AUTHORIZE also removes the user's connections as a holder of identifiers in the rights database. However, if a departed user is the only remaining holder of a given identifier, remove that identifier to avoid future confusion.
Before you remove an identifier from the rights database:
$ SET SECURITY/ACL=(IDENTIFIER=87SUMMER)- _$/DELETE/LOG *.*;*You receive errors for files that do not contain the ACE, but the ACE is deleted from all files that do contain it.
UAF> REMOVE/IDENTIFIER 87TERM3
{message}
Identifiers in hexadecimal format in an ACE indicate that a general identifier has been deleted from the rights database. Similarly, if you see an identifier displayed as a numeric UIC, the original identifier was a UIC that has been removed. Delete ACEs with numeric UIC or hexadecimal identifiers.
It is wise not to reuse UICs after an employee leaves. The new employee may gain some or all of the access rights of the previous employee through ACL entries that still reference the old UIC in numeric format.
To rename an identifier, use the AUTHORIZE command RENAME/IDENTIFIER in the following format:
RENAME/IDENTIFIER old-identifier new-identifier
Renaming an identifier preserves the set of resources available through that identifier. ACLs containing the renamed identifier automatically display the new identifier name.
Whenever you add identifiers to the rights list or grant identifiers to users, you can stipulate that the identifier carry special characteristics called attributes. Although there are many possible attributes, most sites commonly use the following ones:
Sites with high security requirements are likely to use two other attributes, which discourage users from scanning the rights database:
| Holder Hidden attribute | Prevents someone from getting a list of users who hold an identifier unless that person owns the identifier. |
| Name Hidden attribute | Allows holders of an identifier to have it translated (either from binary to ASCII or vice versa), but prevents unauthorized users from translating the identifier. |
Read access to RIGHTSLIST.DAT overrides the Holder Hidden and Name Hidden attributes. The rights list by default denies access to world users; it has a protection of S:RWED,O;RWED,G:R,W:.
The following sections describe each attribute and explain when you might want to add them to some of your site's identifiers.
Once you grant an identifier to a user, processes created by that user hold the identifier for the life of the process. However, if you grant the identifier with the Dynamic attribute, the user who holds the identifier can use the DCL command SET RIGHTS_LIST to add or remove the identifier or its attributes from the process rights list as needed.
To allow users to modify an identifier, specify the Dynamic attribute when adding the identifier to the rights database by using AUTHORIZE, as shown in the following example:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=DYNAMIC
To allow specific holders of the identifier to modify the identifier, include the Dynamic attribute when granting the identifier, as follows:
UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=DYNAMIC SCHWARTZ
User Schwartz could then use the following command to remove the MGMT101 identifier from the process rights list:
$ SET RIGHTS_LIST/DISABLE MGMT101
Users who hold identifiers with the Dynamic and Resource attributes can also use the SET RIGHTS_LIST command to remove only the Resource attribute on the identifier.
Because users might be able to circumvent intended security policy by removing their identifiers, be careful when granting users an identifier with the Dynamic attribute. If an identifier is used in an ACL to deny access to users who hold that identifier with the Dynamic attribute, users may be able to gain access to the object through another ACL entry by removing the identifier from their process rights lists.
Sites with high security requirements can conceal the holders of certain identifiers, thereby preventing malicious users from determining which accounts are more interesting to target for break-ins.
You place the attribute on an identifier the user holds by using the AUTHORIZE command MODIFY/IDENTIFIER, for example:
UAF> MODIFY/IDENTIFIER /ATTRIBUTES=HOLDER_HIDDEN SECRET_PROJECT
Now the prober cannot discover who is on the secret project.
Sites with high security requirements can hide the names of identifiers. For example, sites implementing mandatory access controls can hide the names of identifiers associated with their security categories. This prevents people from seeing the names of identifiers unless they personally hold them. When an identifier holds the Name Hidden attribute, the operating system refuses to translate the identifier from its binary value to ASCII or from ASCII to the binary value unless the requesting process holds the identifier.
To assign the attribute to an identifier, use the AUTHORIZE command MODIFY/IDENTIFIER:
UAF> MODIFY/IDENTIFIER SECRET_NEWS /ATTRIBUTES=NAME_HIDDEN
The No Access attribute allows a process to hold an identifier but not have the identifier considered in determining access rights to the object.
For example, a user with the Resource and No Access attributes can charge disk space to the identifier but not have access to objects owned by the identifier. Or a system manager can manage data and perform tasks connected with the data but cannot read from or write to any of the files.
You can allow file space to be owned by and charged to an identifier yet prevent the files from being accessed in any way. Use AUTHORIZE to specify the No Access attribute with the Resource attribute when adding the identifier to the rights database, as shown in the following example:
UAF> ADD/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)- _UAF> MGMT101
To limit the rights of users holding an identifier with the Resource attribute, grant the identifier with the No Access attribute as well as the Resource attribute to all desired users:
UAF> GRANT/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)- _UAF> MGMT101 SCHWARTZ
Consumption of disk space is generally charged to the creator of each file by subtracting the disk space from the file owner's disk quota. System managers and security administrators might prefer to track the use of disk space according to logical groups of users (such as departments or projects) rather than individual users. General identifiers are used to specify these groups. Thus, when general identifiers own directories, disk space used by files created in the directories may be charged to the identifier rather than the UIC of the file's creator.
To allow file space to be owned by and charged to an identifier, use AUTHORIZE to specify the Resource attribute when adding the identifier to the rights database, as shown in the following example:
UAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=RESOURCE
To allow specific holders of the identifier to charge disk space to the identifier, perform the following steps:
UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=RESOURCE SCHWARTZ
$ SET SECURITY/ACL=(- _$ (IDENTIFIER=MGMT101,ACCESS=READ+WRITE ) - _$ (IDENTIFIER=MGMT101,OPTIONS=DEFAULT,ACCESS=READ+WRITE))- _$ INVENTORY.DIR
$ SET SECURITY/OWNER=MGMT01 INVENTORY.DIR
Because resource identifier MGMT101 is going to own any file you create in directory INVENTORY.DIR, you use ACEs to determine the type of file access you receive. Include a Creator ACE (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE) to set the access granted to the file's creator. Alternatively, you can let the system assign an ACE; its ACE grants control access to the file's creator plus the access specified in the owner field of the protection code. You can set up the protection code by including a Default Protection ACE in the ACL for INVENTORY.DIR, for example, (DEFAULT_PROTECTION, ACCESS=O:RW). (Refer to Section 8.8.1.2 for further information.)
Not everyone who holds the identifier will also hold the Resource attribute associated with that identifier. If you create a file in a directory owned by an identifier but you do not have the Resource attribute for that identifier, the file will be owned by your UIC, and the required disk space is subtracted from your disk quota.
You can authorize users to manage protected subsystems by granting them a subsystem identifier with the Subsystem attribute. This empowers users to enable images to access the objects managed by the subsystem. (See Chapter 13 for a discussion of protected subsystems.)
In the following example, user Schwartz is given the authority to create a subsystem with the identifier MAIL_SUBSYSTEM. Schwartz is also given control access to the application image to set access controls.
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD/IDENTIFIER MAIL_SUBSYSTEM /ATTRIBUTES=SUBSYSTEM UAF> GRANT/IDENTIFIER MAIL_SUBSYSTEM - _UAF> /ATTRIBUTES=SUBSYSTEM SCHWARTZ UAF> Exit $ SET SECURITY/ACL=(IDENTIFIER=MAIL_SUBSYSTEM,ACCESS=CONTROL)- _$ MEMBER_LIST.EXE
As a privileged security administrator, you can use the SET RIGHTS_LIST command to modify the rights list of any process on the system or to modify identifiers in the system rights list. Adding an identifier to the system rights list effectively grants it to all users. You can also use the SET RIGHTS_LIST command to add attributes to existing identifiers.
A possible use of the system rights list is to enable site-specific environmental conditions. For example, a batch job scheduled to run at 8:00 a.m. could add the following identifier:
$ SET RIGHTS_LIST/SYSTEM/ENABLE DAY_SHIFT
Another batch job scheduled for 5:00 p.m. could remove the identifier DAY_SHIFT:
$ SET RIGHTS_LIST/SYSTEM/DISABLE DAY_SHIFT
The effect is to enable access to protected objects with the identifier DAY_SHIFT during the 8:00 a.m. to 5:00 p.m. period.
The command in the next example modifies a process rights list by adding the SALES identifier to the rights list of the process DEDNAM. Specifying the Resource attribute allows the holders of the SALES identifier to charge disk space to it.
$ SET RIGHTS_LIST/ENABLE/ATTRIBUTES=RESOURCE/PROCESS=DEDNAM SALES
Some system activities are limited to users who hold specific privileges. These restrictions protect the integrity of the operating system's performance and, thus, the integrity of service provided to users. Grant privileges to each user on the basis of two factors: (a) whether the user has a legitimate need for the privilege and (b) whether the user has the skill and experience to use the privilege without disrupting the system.
A user's privileges are recorded in the user's UAF record in two privilege vectors. One vector stores the authorized privileges, and the other vector stores the default privileges. The default privileges are the subset of authorized privileges that a user process receives at login.
When a user logs in to the system, the user's privilege vector is stored in the header of the user's process. In this way, the user's privileges are passed on to the process created for the user. Users can use the DCL command SET PROCESS/PRIVILEGES to enable and disable privileges for which they are authorized.
The operating system monitors and audits the use of privilege. You can enable auditing for specific privileges and examine the audit log file to see what privileges were used to execute DCL commands or system services. See Chapter 9 for further information.
Privileges are divided into the following seven categories according to the damage that the user possessing them could cause the system:
Table 8-2 categorizes the privileges and includes a brief definition of the powers associated with each privilege.
| Category | Privilege | Activity Permitted |
|---|---|---|
| None | None | Denied activities requiring privileges |
| Normal |
NETMBX
TMPMBX |
Create network connections
Create temporary mailbox |
| Group |
GROUP
GRPPRV |
Control processes in the same group
Gain access through the system protection field of the group's objects |
| Devour |
ACNT
ALLSPOOL BUGCHK EXQUOTA GRPNAM PRMCEB PRMGBL PRMMBX SHMEM |
Disable accounting
Allocate spooled devices Make bugcheck error log entries Exceed disk quotas Insert group logical names in the name table Create/delete permanent common event flag clusters Create permanent global sections Create permanent mailboxes Create/delete structures in shared memory |
| System |
ALTPRI
AUDIT OPER PSWAPM WORLD SECURITY SYSLCK |
Set base priority higher than allotment
Generate audit records Perform operator functions Change process swap mode Control any process Perform security-related functions Lock systemwide resources |
| Objects |
DIAGNOSE
IMPORT MOUNT READALL SYSGBL VOLPRO |
Diagnose devices
Mount a nonlabeled tape volume Execute mount volume QIO Possess read access to all system objects Create systemwide global sections Override volume protection |
| All |
BYPASS
CMEXEC CMKRNL DETACH DOWNGRADE LOG_IO PFNMAP PHY_IO SETPRV SHARE SYSNAM SYSPRV UPGRADE |
Disregard protection
Change to executive mode Change to kernel mode Create detached processes of arbitrary UIC Write to a lower secrecy object or lower an object's classification Issue logical I/O requests Map to specific physical pages Issue physical I/O requests Enable any privilege Access devices allocated to other users Insert system logical names in the name table Access objects through the system protection field Write to a higher integrity object or raise an object's integrity level |
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.
| 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:
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.
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 Digital-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.
$ INSTALL SDA.EXE /PRIVILEGED=CMKRNL
$ SET SECURITY/ACL=(IDENTIFIER=SDA,ACCESS=EXECUTE)- _$ SYS$SYSTEM:SDA.EXE $ SET SECURITY/PROTECTION=(WORLD) SYS$SYSTEM:SDA.EXE
Note
All images that you install with privilege must be linked with the /NOTRACEBACK qualifier to prevent online debugging and traceback.
Digital 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.
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.
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:
6346P014.HTM OSSG Documentation 22-NOV-1996 13:05:11.45
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.