skip book previous and next navigation links
go up to top of book: HP OpenVMS Guide to System SecurityHP OpenVMS Guide to System Security
go to beginning of part: Security for the System AdministratorSecurity for the System Administrator
go to beginning of chapter: Controlling Access to System Data and ResourcesControlling Access to System Data and Resources
go to previous page: Designing ACLsDesigning ACLs
go to next page: Giving Users PrivilegesGiving Users Privileges
end of book navigation links

Populating the Rights Database  



Once you have designed the names of the identifiers you wanton your system and composed the set of holders for the identifiers,use AUTHORIZE to add the identifiers to the rights database andassign the identifiers to the intended users. These associationsare kept in the rights database (RIGHTSLIST.DAT), which you maintainas you add or remove users and identifiers.

Initially, the rights database is created at system installationand is located in the [SYSEXE] directory. At creation, it containsthe names of the environmental identifiers. As you add users tothe authorization file, one identifier is added for each authorizeduser. The identifier, called a UIC identifier, is associated withthe user's UIC and user name.

There is also an identifier in the rights database equivalentto each UIC group name. When you add a new user as the first memberof a new UIC group and you specify an account group name with theuser, an identifier corresponding to the account group name is addedto the rights database, as shown in the following example:

$ SET DEFAULT SYS$SYSTEM$ RUN AUTHORIZEUAF> ADD ROB/PASSWORD=SP0152/UIC=[014,006] -_UAF> /DIRECTORY=WORK:[ROB]/ACCOUNT=MGMTUAF-I-ADDMSG, user record successfully addedUAF-I-RDBADDMSGU, identifier ROB value: [000014,000006]    added to RIGHTSLIST.DATUAF-I-RDBADDMSGU, identifier MGMT value: [000014,177777]    added to RIGHTSLIST.DAT
Because the account name MGMT is specified when adding ROB'saccount and no UIC group of that name exists, the MGMT identifieris added to the rights database.

Each site adapts its own rights database according to actualuse and needs.

Notethat when you use AUTHORIZE to add, remove, or change user namesin the system user authorization file (SYSUAF.DAT), AUTHORIZE makescorresponding changes for you in RIGHTSLIST.DAT so that the rightslist corresponds to SYSUAF.DAT.

Because of the automatic creation and maintenance of the rightsdatabase, you seldom need to use the AUTHORIZE command CREATE/RIGHTS.However, if the rights database is damaged or deleted, you can createa new one with this command. (See the HP OpenVMS SystemManagement Utilities Reference Manual for more information.)

Displaying the Database  

You should regularly display the rights database to checkthat it is correct and current. Two AUTHORIZE commands are usedfor this: SHOW/IDENTIFIER and SHOW/RIGHTS. To display all holdersof an identifier, use the SHOW/IDENTIFIER command, as shown in thefollowing example:

UAF> SHOW/IDENTIFIER/FULL NETWORK
Use the asterisk (*) wildcard to display all holders of allidentifiers on the system, as follows:
UAF> SHOW/IDENTIFIER/FULL *
To display the identifiers held by a particular user, usethe SHOW/RIGHTS command, as follows:
UAF> SHOW/RIGHTS/USER=ROBIN
Use the asterisk wildcard to display all identifiers heldby all users, as follows:
UAF> SHOW/RIGHTS/USER=*UAF> SHOW/RIGHTS/USER=[*,*]
The first command displays users alphabetically. The secondcommand displays users according to UICs.

Adding Identifiers  

You add identifiers to the rights list with the AUTHORIZEcommand ADD/IDENTIFIER, for example:

UAF> ADD/IDENTIFIER PAYROLLidentifier PAYROLL value %X80080011 added to RIGHTSLIST.DAT
To grant users an identifier with any of the attributes describedin Customizing Identifiers, you must name thatattribute when adding the identifier. For example, to allow usersto add or modify an identifier, specify the Dynamic attribute:
UAF> ADD/IDENTIFIER PROJECT_TEAM1 /ATTRIBUTES=DYNAMIC

Restoring the Rights Database  

If you accidentally deleted the rights list and it cannotbe recovered from a backup copy, recreate RIGHTSLIST.DAT by enteringthe 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 therights list corresponding to each user name in SYSUAF.DAT. To completethe task, use the ADD/IDENTIFIER command to add all general identifiersthat were lost. Then redefine the holders of the identifiers withGRANT/IDENTIFIER commands, as described in Assigning Identifiers to Users.

Assigning Identifiers to Users  

After adding identifiers, you associate users as holders ofthe existing identifiers by using the AUTHORIZE command GRANT/IDENTIFIER,as shown in the following example:

UAF> GRANT/IDENTIFIER PAYROLL MARTINUAF-I-GRANTMSG, identifier PAYROLL granted to MARTINUAF> GRANT/IDENTIFIER PAYROLL IPPOLITOUAF-I-GRANTMSG, identifier PAYROLL granted to IPPOLITO
To give user Martin the EXECUTIVE identifier in addition tothe PAYROLL identifier would require another use of the GRANT/IDENTIFIERcommand. You can introduce only one holder association at a timewith the GRANT/IDENTIFIER command.

In all cases shown above, AUTHORIZE associates the PAYROLLidentifier with the UIC identifier corresponding to the user, specificallyMartin and Ippolito. Both the identifiers must exist in the rights database.

Removing Holder Records  

When a user leaves the company, remove the UAF record forthat user. Notify the managers of all sites where that user hasaccess to proxy accounts to remove proxy access information in theremote node's NETPROXY.DAT file. When you run AUTHORIZE to removea user's UAF record, AUTHORIZE also removes the user's connectionsas a holder of identifiers in the rights database. However, if adeparted user is the only remaining holder of a given identifier,remove that identifier to avoid future confusion.

Removing Identifiers  

Before you remove an identifier from the rights database:

  1. Remove all occurrencesof the identifier from ACLs on the system. For example, the followingcommand removes the obsolete identifier 87SUMMER from the ACL ofmultiple files:
    $ 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.
  2. Remove the identifier 87SUMMER from the rights databasewith the AUTHORIZE command REMOVE/IDENTIFIER. For example, use thefollowing AUTHORIZE command to remove the identifier 87TERM3:
    UAF> REMOVE/IDENTIFIER 87TERM3{message}

Identifiers in hexadecimal format in an ACE indicate thata 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. DeleteACEs with numeric UIC or hexadecimal identifiers.

It is wise not to reuse UICs after an employee leaves. Thenew employee may gain some or all of the access rights of the previousemployee through ACL entries that still reference the old UIC innumeric format.

To rename an identifier, use the AUTHORIZE command RENAME/IDENTIFIERin the following format: RENAME/IDENTIFIER old-identifier new-identifier

Renaming an identifier preserves the set of resources availablethrough that identifier. ACLs containing the renamed identifierautomatically display the new identifier name.

Customizing Identifiers  

Whenever you add identifiers to the rights list or grant identifiersto users, you can stipulate that the identifier carry special characteristicscalled attributes. Although there are manypossible attributes, most sites commonly use the following ones:

Dynamic attribute
Allows holders of the identifierto remove and to restore the identifier from the process rightslist by using the DCL command SET RIGHTS_LIST.
Resource attribute
Allows holders of the identifierto charge disk space to the identifier. It is used for file objects.
Subsystem attribute
Allows holders of the identifierto create and maintain protected subsystems by assigning the SubsystemACE to the application images in the subsystem.
No Access attribute
Makes any access rights of the identifiernull and void. This attribute is intended as a modifier for a resourceidentifier or for purposes unrelated to access control.

Sites with high security requirements are likely to use twoother attributes, which discourage users from scanning the rightsdatabase:

Holder Hiddenattribute
Prevents someone from gettinga list of users who hold an identifier unless that person owns theidentifier.
Name Hidden attribute
Allows holders of an identifier to haveit translated (either from binary to ASCII or vice versa), but preventsunauthorized users from translating the identifier.

Read access to RIGHTSLIST.DAT overrides the Holder Hiddenand Name Hidden attributes. The rights list by default denies accessto world users; it has a protection of S:RWED,O;RWED,G:R,W:.

The following sections describe each attribute and explainwhen you might want to add them to some of your site's identifiers.

Dynamic Attribute  

Once you grant an identifier to a user, processes createdby that user hold the identifier for the life of the process. However,if you grant the identifier with the Dynamic attribute, the userwho holds the identifier can use the DCL command SET RIGHTS_LISTto add or remove the identifier or its attributes from the process rightslist as needed.

To allow users to modify an identifier, specify the Dynamicattribute when adding the identifier to the rights database by usingAUTHORIZE, as shown in the following example:

$ SET DEFAULT SYS$SYSTEM$ RUN AUTHORIZEUAF> ADD/IDENTIFIER MGMT101 /ATTRIBUTES=DYNAMIC
To allow specific holders of the identifier to modify theidentifier, 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 removethe MGMT101 identifier from the process rights list:
$ SET RIGHTS_LIST/DISABLE MGMT101
Users who hold identifiers with the Dynamic and Resource attributescan also use the SET RIGHTS_LIST command to remove only the Resourceattribute on the identifier.

Because users might be able to circumvent intended securitypolicy by removing their identifiers, be careful when granting usersan identifier with the Dynamic attribute. If an identifier is usedin an ACL to deny access to users who hold that identifier withthe Dynamic attribute, users may be able to gain access to the objectthrough another ACL entry by removing the identifier from theirprocess rights lists.

Holder Hidden Attribute  

Sites with high security requirements can conceal the holdersof certain identifiers, thereby preventing malicious users fromdetermining which accounts are more interesting to target for break-ins.

You place the attribute on an identifier the user holds byusing 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.

Name Hidden Attribute  

Sites with high security requirements can hide the names ofidentifiers. For example, sites implementing mandatory access controlscan hide the names of identifiers associated with their securitycategories. This prevents people from seeing the names of identifiersunless they personally hold them. When an identifier holds the NameHidden attribute, the operating system refuses to translate theidentifier from its binary value to ASCII or from ASCII to the binaryvalue unless the requesting process holds the identifier.

To assign the attribute to an identifier, use the AUTHORIZEcommand MODIFY/IDENTIFIER:

UAF> MODIFY/IDENTIFIER SECRET_NEWS /ATTRIBUTES=NAME_HIDDEN

No Access Attribute  

The No Access attribute allows a process to hold an identifierbut not have the identifier considered in determining access rightsto the object.

For example, a user with the Resource and No Access attributescan charge disk space to the identifier but not have access to objectsowned by the identifier. Or a system manager can manage data andperform tasks connected with the data but cannot read from or writeto any of the files.

You can allow file space to be owned by and charged to anidentifier yet prevent the files from being accessed in any way.Use AUTHORIZE to specify the No Access attribute with the Resourceattribute when adding the identifier to the rights database, asshown in the following example:

UAF> ADD/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)-_UAF> MGMT101
To limit the rights of users holding an identifier with theResource attribute, grant the identifier with the No Access attributeas well as the Resource attribute to all desired users:
UAF> GRANT/IDENTIFIER/ATTRIBUTES=(RESOURCE,NOACCESS)-_UAF> MGMT101 SCHWARTZ

Resource Attribute  

Consumptionof disk space is generally charged to the creator of each file bysubtracting the disk space from the file owner's disk quota. Systemmanagers and security administrators might prefer to track the use ofdisk space according to logical groups of users (such as departmentsor projects) rather than individual users. General identifiers areused to specify these groups. Thus, when general identifiers owndirectories, disk space used by files created in the directoriesmay be charged to the identifier rather than the UIC of the file'screator.

To allow file space to be owned by and charged to an identifier,use AUTHORIZE to specify the Resource attribute when adding theidentifier 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 diskspace to the identifier, perform the following steps:
  1. Grant the identifierwith the Resource attribute to all desired users:
    UAF> GRANT/IDENTIFIER MGMT101/ATTRIBUTES=RESOURCE SCHWARTZ
  2. Modify the directory to allow read and write accessto the resource identifier:
    $ SET SECURITY/ACL=(-_$ (IDENTIFIER=MGMT101,ACCESS=READ+WRITE ) -_$ (IDENTIFIER=MGMT101,OPTIONS=DEFAULT,ACCESS=READ+WRITE))-_$ INVENTORY.DIR
  3. Change the ownership of the parent directory sothat any files in it are owned by the identifier by default:
    $ SET SECURITY/OWNER=MGMT01 INVENTORY.DIR

Because resource identifier MGMT101 is going to own any fileyou create in directory INVENTORY.DIR, you use ACEs to determinethe 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 accessto the file's creator plus the access specified in the owner fieldof the protection code. You can set up the protection code by includinga Default Protection ACE in the ACL for INVENTORY.DIR, for example,(DEFAULT_PROTECTION, ACCESS=O:RW). (Refer to Setting Defaults for a Directory Owned by a Resource Identifier for further information.)

Not everyone who holds the identifier will also hold the Resourceattribute associated with that identifier. If you create a filein a directory owned by an identifier but you do not have the Resourceattribute for that identifier, the file will be owned by your UIC,and the required disk space is subtracted from your disk quota.

SubsystemAttribute  

You can authorize users to manage protected subsystems bygranting them a subsystem identifier with the Subsystem attribute.This empowers users to enable images to access the objects managedby the subsystem. (See Using Protected Subsystems for a discussion of protected subsystems.)

In the following example, user Schwartz is given the authorityto create a subsystem with the identifier MAIL_SUBSYSTEM. Schwartzis also given control access to the application image to set accesscontrols.

$ SET DEFAULT SYS$SYSTEM$ RUN AUTHORIZEUAF> ADD/IDENTIFIER MAIL_SUBSYSTEM /ATTRIBUTES=SUBSYSTEMUAF> GRANT/IDENTIFIER MAIL_SUBSYSTEM -_UAF> /ATTRIBUTES=SUBSYSTEM SCHWARTZUAF> Exit$ SET SECURITY/ACL=(IDENTIFIER=MAIL_SUBSYSTEM,ACCESS=CONTROL)-_$ MEMBER_LIST.EXE

Modifying a System or Process Rights List  

As a privileged security administrator, you can use the SETRIGHTS_LIST command to modify the rights list of any process onthe system or to modify identifiers in the system rights list. Addingan identifier to the system rights list effectively grants it toall users. You can also use the SET RIGHTS_LIST command to add attributesto existing identifiers.

A possible use of the system rights list is to enable site-specificenvironmental conditions. For example, a batch job scheduled torun 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 theidentifier DAY_SHIFT:
$ SET RIGHTS_LIST/SYSTEM/DISABLE DAY_SHIFT
The effect is to enable access to protected objects with theidentifier DAY_SHIFT during the 8:00 a.m. to 5:00 p.m. period.

The command in the next example modifies a process rightslist by adding the SALES identifier to the rights list of the processDEDNAM. Specifying the Resource attribute allows the holders ofthe SALES identifier to charge disk space to it.

$ SET RIGHTS_LIST/ENABLE/ATTRIBUTES=RESOURCE/PROCESS=DEDNAM SALES

go to previous page: Designing ACLsDesigning ACLs
go to next page: Giving Users PrivilegesGiving Users Privileges