The profile of a user process or application includes
the following elements:
User identification code
(UIC) identifying the user
Rights identifiers held
by the process
Privileges, if any
Per-Thread Security
OpenVMS Alpha Version 7.2 includes the implementation
of thread-level security. This feature, known as per-thread security,
allows each execution thread of a multithreaded process to run an
independent security profile without impacting the security profiles
of other threads in the process.
Security profile information previously contained
in various process level data structures and data cells is now stored
in a single data structure, the Persona Security Block (PSB), which
is then bound to a thread of execution. All associated references
within OpenVMS have been redirected accordingly. Every process in
the system has at least one PSB that is the natural persona of the process. The natural persona is created during process creation.
Interaction between a thread manager (for example,
the thread manager incorporated within HP POSIX Threads Library) and
the security subsystem provides for the automatic switching of profiles
while threads are scheduled for execution.
Persona Security Block Data Structure (PSB)
The user's security profile (privileges,
rights, and identity information) has shifted from the process level
to the user thread level. The security information previously stored
in several structures (including the Access Rights Block (ARB), Process
Control Block (PCB), Process Header Descriptor (PHD), Job Information
Block (JIB), and Control (CTL) region fields) has moved to a new Persona
Security Block (PSB) data structure and all references are redirected
accordingly. OpenVMS no longer uses some of the fields in these structures.
The affected fields are now considered obsolete.
Each process has a persona array containing the
addresses of all persona blocks allocated to the process.
The new persona block (PSB) contains the following:
UIC
Persona, and system rights
chains
Permanent, authorized,
and working privileges
Account name
User name
Auditing flags and counters
The kernel threads block (KTB) points to the persona
block for the currently active thread.
Previous Security Model
In previous versions of OpenVMS, the information
that constitutes a user's security profile was bound at the process
level, common to all threads of execution within the process. For
more information on the relationship between security profile and
the threads, see “Previous Per-Thread Security Model”.
Figure 4-1 Previous Per-Thread Security Model
Modifications made to the security profile by
one thread are potentially visible to other threads, depending on
how the threads perform profile management among themselves.
Per-Thread Security Model
In OpenVMS Version 7.2
and later, each thread of execution can share a security profile with
other threads or have a thread-specific security profile. For more
information on the relationship between security profiles with threads,
see the “Per-Thread Security Profile Model”.
Figure 4-2 Per-Thread Security Profile Model
As is the case in the previous model, modifications
to a shared profile are potentially visible to all threads that share
the profile. However, modifications made to a thread-specific security
profile are only applicable to the particular thread.
User Identification Code (UIC)
The first element of a subject's security
profile is the user identification code (UIC). Your UIC tells what
system group you belong to and what your unique identification is
within that group.
Format of a UIC
A UIC specification always appears in brackets,
but its format can differ. Valid formats include the following:
An alphanumeric UIC consists of a member name and, optionally,
a group name:
[member]
or
[group,member]
The group and member names can each contain up
to 31 alphanumeric characters, at least one of which is alphabetic.
The names can include upper- and lowercase characters A through Z,
dollar signs ($), underscores(_), and the numbers 0 through 9.
A numeric UIC contains a group number and a member number:
[group,member]
The group number is an octal number in the range
of 1 through 37776; the member number is an octal number in the range
of 0 through 177776. You can omit leading zeros when you are specifying
group and member numbers. HP reserves group 1 and groups
300--377 for its own use.
The following table illustrates several UICs in
proper UIC notation:
Type of UIC
Example
Meaning
Alphanumeric
[USER,FRED]
Group USER, member FRED
[EXEC,JONES]
Group EXEC, member JONES
[JONES]
Group EXEC, member JONES
Numeric
[200,10]
Group 200, member 10
[3777,3777]
Group 3777, member 3777
Only one user can have the member name JONES;
therefore JONES must belong to the EXEC group.
Guidelines for Creating a UIC
UICs cannot be arbitrarily assigned. A security
administrator has to observe the following guidelines when creating
them:
Member names must be unique
for each user on the system.
No member can participate
in more than one UIC group.
These guidelines exist because the system translates
a UIC to a 32-bit value that represents a group number and a member
number; the high-order 16 bits contain the group number, and the low-order
16 bits contain the member number. When translating an alphanumeric
UIC such as [J_JONES], the operating system equates the member part
of the alphanumeric UIC to both the group and member parts of a numeric
UIC. The resulting 32-bit numeric UIC is kept in the rights database
(which is a file containing information about identifiers, their attributes,
and holders). For example, you could not have the two UICs [GROUP1,JONES]
and [GROUP2,JONES] on the same system because the member JONES can
have only one associated numeric UIC. The member name of the alphanumeric
UIC is normally the same as the associated login user name.
How Your Process Acquires a UIC
When you log in to a system, the operating system
copies your UIC from your user authorization (UAF) record in the system
user authorization file (SYSUAF.DAT) and assigns it to your process.
It serves as an identification for the life of the process.
By default, detached processes (created by the
DCL command SUBMIT or RUN) and subprocesses (created by the DCL command
SPAWN) take the same UICs as their creators. If you have IMPERSONATE
privilege, you can create a detached process with a different UIC
(by using the /UIC qualifier of the RUN command).
Rights Identifiers
The second element of a subject's security
profile is a set of rights identifiers.
A rights identifier represents an individual user
or a group of users. Using the Authorize utility (AUTHORIZE), security
administrators create and remove identifiers and assign users to hold
these identifiers. Rights identifiers can be a temporary way of identifying
a group of users because users hold certain identifiers only as long
as they are necessary.
Types of Identifiers
The operating system supports several types of
rights identifiers. “Major Types of Rights Identifiers” shows the identifiers that are most
commonly used in access control.
Table 4-1 Major Types of Rights Identifiers
Type
Description
Format
Example
Environmental identifiers
Describe different types of
users based on their initial entry into the system.
Alphanumeric strings of 1 through 31 characters
with at least one alphabetic character. Valid characters include numbers
0 through 9, characters A through Z and a through z, the dollar sign
($) and the underscore (_).
SALES, PERSONNEL, DATA_ENTRY, RESERVE_DESK
UIC identifiers
Based on a user's identification
code (UIC), which uniquely identifies a user on the system and defines
the group to which the user belongs.
Alphanumeric UICs, with or without brackets.
Valid characters are the same as those for a general identifier.
[GROUP1,JONES], [JONES],
GROUP1, JONES
Facility identifiers
Defined by the application.
Same as a general identifier. See the HP OpenVMS Programming Concepts Manual for details.
DBM$MOD_SCHEMA
In addition to the identifiers listed in “Major Types of Rights Identifiers”, a system node
identifier of the form SYS$NODE_ node_name is
created by the system startup procedure (STARTUP.COM in SYS$SYSTEM).
Process and System Rights Lists
Associated with your process is a rights list
that contains all the identifiers granted to it. In addition, there
is a system rights list that is shared by all users on the system.
The system manager or the system software grants identifiers to the
system rights list that are granted to all users currently logged
on to the system.
Displaying the Rights Identifiers of Your Process
You can display the identifiers for your current
process with the SHOW PROCESS command, for example:
$SHOW PROCESS/ALL25-JUN-2008 15:23:18.08 User: GREG Process ID: 34200094Node: ACCOUNTS Process name: "_TWA2:"Terminal: TWA2:User Identifier: [DOC,GREG][1]
Base priority: 4Default file spec: WORK1:[GREG.FISCAL_91]Devices allocated: ACCOUNTS$TWA2:Process Quotas:[vellip]
Process rights:INTERACTIVE[2]
LOCAL[3]
SALES[4] MINDCRIME resource[5]
System rights:SYS$NODE_ACCOUNTS[6]
Output from this SHOW PROCESS command displays
three types of identifiers:
UIC identifier, indicating
user Greg is a member of the DOC group
Environmental identifier,
indicating user Greg is an interactive user
Environmental identifier,
indicating user Greg is logged in locally
General identifier, indicating
user Greg is also a member of the SALES group
General identifier, indicating
Greg holds the MINDCRIME identifier with the resource attribute so
he can charge disk space to the identifier
Environmental identifier,
indicating user Greg is working from the ACCOUNTS node
How Rights Identifiers Appear in the Audit Trail
The rights identifiers of a process also appear
in audit records. If a security administrator chooses to audit access
to objects, then the operating system can produce a record of which
users accessed objects and when. Although a single audit record rarely
tells very much, the trail of records can, over a period of time,
reveal a pattern of behavior that tells a story.
The following audit record shows that user Greg
attempted to delete a file but was prevented from doing so because
he holds the identifier MINDCRIME. The file 93_FORECAST.DAT has an
ACE preventing access by processes with the identifier MINDCRIME.
(Relevant lines are Event information, Matching ACE, and Status.)
Message from user AUDIT$SERVER on FNORD
Security alarm (SECURITY) and security audit (SECURITY) on ACCOUNTS,
system id: 19662
Auditable event: Object deletion
Event information: file deletion request (IO$_DELETE)
Event time: 24-APR-2008 13:17:24.59
PID: 34200094
Process name: _TWA2:
Username: GREG
Process owner: [DOC,GREG]
Terminal name: TWA2:
Image name: DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE
Object class name: FILE
Object owner: [SYSTEM]
Object protection: SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RE, WORLD:RE
File name: _DSA2200:[GREG]93_FORECAST.DAT;1
File ID: (17481,6299,1)
Access requested: DELETE
Matching ACE: (IDENTIFIER=MINDCRIME,ACCESS=NONE)
Sequence key: 00008A41
Status: %SYSTEM-F-NOPRIV, no privilege for
attempted operation
Privileges
A third (optional) element of a subject's
security profile is a set of privileges.
Privileges let you use or perform system functions
that ordinarily would be denied to you. Security administrators can
grant privileges to users under special circumstances so they can
perform necessary tasks without changing existing protection authorizations.
Privileges vary in power. Some allow normal network
operations; for example, NETMBX and TMPMBX let you send and receive
mail across the network. But others, such as SYSNAM, grant the ability
to influence system operations. A user with the SYSNAM privilege can
modify the system logical name table.
A user's privileges are recorded in the user's
UAF record in a 64-bit privilege mask. When a user logs in to the
system, the user's privilege vector is stored in the subject's
(process) security profile.
You can use the DCL command SET PROCESS/PRIVILEGES
to enable and disable privileges for which you are are authorized,
thus controlling the privileges available to the images you run. “Authorized Versus Default Process Privileges” shows user
Puterman has a large number of authorized privileges, which are available
for use when necessary, yet Puterman's process runs by default
with only two privileges enabled: NETMBX and TMPMBX.
Example 4-1 Authorized Versus Default Process Privileges
$SHOW PROCESS/PRIVILEGE
8-OCT-2008 16:58:58.77
User: PUTERMAN Process ID: 27E00496
Node: FNORD Process name: "Hobbit"Authorized privileges:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL
DIAGNOSE DOWNGRADE EXQUOTA GROUP GRPNAM GRPPRV IMPERSONATE IMPORT
LOG_IO MOUNT NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL
PRMMBX PSWAPM READALL SECURITY SETPRV SHARE SHMEM SYSGBL
SYSLCK SYSNAM SYSPRV TMPMBX UPGRADE VOLPRO WORLD
Process privileges:
NETMBX may create network device
TMPMBX may create temporary mailbox
Puterman can enable specific authorized privileges
as he needs them; for example, he needs ALLSPOOL to allocate a spooled
device and LOG_IO to perform logical I/O operations.
