Document revision date: 30 March 2001 | |
Previous | Contents | Index |
Rather than attempting to restructure UIC groups to solve data and resource protection problems, you may be able to achieve your goals by using access control lists (ACLs). ( Section 4.4 provides a detailed description of ACLs.) The UIC can serve as an identifier in an ACE, so you can easily construct ACLs that allow specific users across various UIC groups access to an object.
For example, consider the ACL that you might construct to allow specific users from the Rainbow Paint Company to access the file PAYROLL.DAT:
(IDENTIFIER=OWESTWOOD,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=CRUIZ,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=RSMITH,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=JSIMON,ACCESS=READ) (IDENTIFIER=SGIBSON,ACCESS=READ) |
Many users often share the same access needs, and an ACL consisting strictly of UIC identifiers can become too lengthy. To shorten the ACL, you can include environmental identifiers, which are system-defined, or create general identifiers (see Table 4-1).
When creating general identifiers, you design the names of the identifiers you want on your system and compose the set of holders for the identifiers. Then you add the identifiers to the rights database and assign the identifiers to the intended users.
For example, the Rainbow Paint Company decided to add the identifier PAYROLL to the rights database. The holders of that identifier were all users who needed read, write, execute, and delete access to PAYROLL.DAT: OWESTWOOD, CRUIZ, and RSMITH.
Once the identifier and its holders were defined, the security administrator used the following ACL to specify the same type of access to PAYROLL.DAT:
(IDENTIFIER=PAYROLL,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=JSIMON,ACCESS=READ) (IDENTIFIER=SGIBSON,ACCESS=READ) |
A final step in designing ACLs and identifiers is to consider how and when different identifiers are going to be used. Users often need to hold an identifier for different reasons, such as updating databases or performing system operations. For this reason, you may want to qualify the use of an identifier.
There are several ways to qualify identifiers. One way is to use environmental identifiers, and another is to add special attributes to identifiers, as described in Section 8.6.7.
Environmental identifiers describe different types of users based on their initial entry into the system. These identifiers---local, dialup, remote, interactive, network, and batch---let you define a large potential group of users according to their use of the system. Typically, these types of identifiers are used in combination with other identifiers.
For example, the following ACE permits user Martin to have read, write, execute, and delete access to the object only when logged in from a local terminal:
(IDENTIFIER=MARTIN+LOCAL,ACCESS=READ+WRITE+EXECUTE+DELETE) |
You can use the environmental identifiers in ACLs to deny access to an entire class of logins. For example, the following ACE denies access to all dialup users:
(IDENTIFIER=DIALUP,ACCESS=NONE) |
In assigning these environmental identifiers to users in a DECwindows
environment, remember that DECwindows processes can be virtually any
type of process. For example, a user may choose to run DECwindows Mail
in a batch job. Even though the process is communicating interactively
with a user through a DECwindows workstation, it is still classified as
a batch job.
8.5 Designing ACLs
There are several factors to consider when designing ACLs:
ACLs become too long (for example, more than 200 entries or so),
you might consider grouping users into discrete categories and creating
general identifiers.
For more information on defining identifiers, see Section 8.6 and the
description of AUTHORIZE in the OpenVMS System Management Utilities Reference Manual. For more information
about creating and maintaining ACLs, see Chapter 4. For extensive
work, using the access control list editor (ACL editor) is appropriate;
the ACL editor is described in the OpenVMS System Management Utilities Reference Manual.
8.6 Populating the Rights Database
Once you have designed the names of the identifiers you want on your system and composed the set of holders for the identifiers, use AUTHORIZE to add the identifiers to the rights database and assign the identifiers to the intended users. These associations are kept in the rights database (RIGHTSLIST.DAT), which you maintain as you add or remove users and identifiers.
Initially, the rights database is created at system installation and is located in the [SYSEXE] directory. At creation, it contains the names of the environmental identifiers. As you add users to the authorization file, one identifier is added for each authorized user. The identifier, called a UIC identifier, is associated with the user's UIC and user name.
There is also an identifier in the rights database equivalent to each UIC group name. When you add a new user as the first member of a new UIC group and you specify an account group name with the user, an identifier corresponding to the account group name is added to the rights database, as shown in the following example:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD ROB/PASSWORD=SP0152/UIC=[014,006] - _UAF> /DIRECTORY=WORK:[ROB]/ACCOUNT=MGMT UAF-I-ADDMSG, user record successfully added UAF-I-RDBADDMSGU, identifier ROB value: [000014,000006] added to RIGHTSLIST.DAT UAF-I-RDBADDMSGU, identifier MGMT value: [000014,177777] added to RIGHTSLIST.DAT |
Because the account name MGMT is specified when adding ROB's account and no UIC group of that name exists, the MGMT identifier is added to the rights database.
Each site adapts its own rights database according to actual use and needs.
Note that when you use AUTHORIZE to add, remove, or change user names in the system user authorization file (SYSUAF.DAT), AUTHORIZE makes corresponding changes for you in RIGHTSLIST.DAT so that the rights list corresponds to SYSUAF.DAT.
Because of the automatic creation and maintenance of the rights
database, you seldom need to use the AUTHORIZE command CREATE/RIGHTS.
However, if the rights database is damaged or deleted, you can create a
new one with this command. (See the OpenVMS System Management Utilities Reference Manual for more information.)
8.6.1 Displaying the Database
You should regularly display the rights database to check that it is correct and current. Two AUTHORIZE commands are used for this: SHOW/IDENTIFIER and SHOW/RIGHTS. To display all holders of an identifier, use the SHOW/IDENTIFIER command, as shown in the following example:
UAF> SHOW/IDENTIFIER/FULL NETWORK |
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.
8.6.2 Adding Identifiers
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.
8.6.4 Assigning Identifiers to Users
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.
8.6.5 Removing Holder Records
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.
8.6.6 Removing Identifiers
Before you remove an identifier from the rights database:
$ SET SECURITY/ACL=(IDENTIFIER=87SUMMER)- _$/DELETE/LOG *.*;* |
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.
8.6.7 Customizing Identifiers
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.
8.6.7.1 Dynamic Attribute
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.
8.6.7.2 Holder Hidden Attribute
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.
8.6.7.3 Name Hidden Attribute
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.
Previous | Next | Contents | Index |
privacy and legal statement | ||
6346PRO_018.HTML |