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 HP
OpenVMS System Management Utilities Reference Manual for
more information.)
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.
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 “Customizing Identifiers”, 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 |
Restoring the Rights Database |
|
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 “Assigning Identifiers to Users”.
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.
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.
Removing Identifiers |
|
Before you remove an identifier from the rights
database:
Remove all occurrences
of the identifier from ACLs on the system. For example, the following
command removes the obsolete identifier 87SUMMER from the ACL of multiple
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.
Remove the identifier
87SUMMER from the rights database with the AUTHORIZE command REMOVE/IDENTIFIER.
For example, use the following AUTHORIZE command to remove the identifier
87TERM3:
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.
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:
Dynamic
attribute | Allows
holders of the identifier to remove and to restore the identifier
from the process rights list by using the DCL command SET RIGHTS_LIST. |
Resource
attribute | Allows
holders of the identifier to charge disk space to the identifier.
It is used for file objects. |
Subsystem
attribute | Allows
holders of the identifier to create and maintain protected subsystems
by assigning the Subsystem ACE to the application images in the subsystem. |
No Access attribute | Makes any access rights of the identifier
null and void. This attribute is intended as a modifier for a resource
identifier or for purposes unrelated to access control. |
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:
Grant the identifier with
the Resource attribute to all desired users:
UAF>GRANT/IDENTIFIER MGMT101/ATTRIBUTES=RESOURCE SCHWARTZ
|
Modify the directory to
allow read and write access to the resource identifier:
$SET SECURITY/ACL=(-
_$(IDENTIFIER=MGMT101,ACCESS=READ+WRITE ) -
_$(IDENTIFIER=MGMT101,OPTIONS=DEFAULT,ACCESS=READ+WRITE))-
_$INVENTORY.DIR
|
Change the ownership of
the parent directory so that 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 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). (See the“Setting Defaults for a Directory Owned by a Resource Identifier” 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 “Using Protected Subsystems” 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 |
Modifying a System or Process Rights List |
|
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 |
