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 “Security Auditing” for further information.
Categories of Privilege
Privileges are divided into the following seven
categories according to the damage that the user possessing them could
cause the system:
Normal: Minimum privileges
to effectively use the system
Group: Potential to interfere
with members of the same group
Devour: Potential to consume
noncritical systemwide resources
System: Potential to interfere
with normal system operation
Objects: Potential to
compromise object security
All: Potential to control
“OpenVMS Privileges” categorizes the privileges and includes
a brief definition of the powers associated with each privilege.
Table 8-2 OpenVMS Privileges
| Category|| Privilege|| Activity
Deny activities requiring
Create network connections
Create temporary mailbox
Control processes in
the same group Gain access through the system protection field of
the group's objects
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
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
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
BYPASS CMEXEC CMKRNL IMPERSONATE
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
Suggested Privilege Allocations
“Assigning Privileges” lists all user privileges and includes recommendations on when
to grant them. When allocating user privileges, be conservative.
The summary guidelines in “Minimum Privileges for System Users” indicate
the minimum privilege requirements for common classes of system users.
Table 8-3 Minimum Privileges for System Users
| Type of User|| Minimum Privileges|
SYSPRV, OPER, SYSNAM, CMKRNL
SECURITY, AUDIT, READALL
Limiting User Privileges
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). “Installing Images with Privilege” discusses installing privileged images
in more detail.
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 HP 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 “Using Protected Subsystems”, and thereby eliminate the need for
any system privileges.
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 HP 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 HP-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 with the
CMKRNL privilege, as follows:
$INSTALL SDA.EXE /PRIVILEGED=CMKRNL
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/PROTECTION=(WORLD) SYS$SYSTEM:SDA.EXE
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
Restricting Command Output
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.