Document revision date: 19 July 1999

By using the OpenVMS Debugger, you can turn on and off unaligned data exception breakpoints by using the commands SET BREAK/UNALIGNED_DATA and CANCEL BREAK/UNALIGNED_DATA. These commands must be used with the SET BREAK/EXCEPTION command. When the debugger breaks at the unaligned data exception, the context is like any other exception. You can examine the program counter (PC), processor status (PS), and virtual address of the unaligned data exception. Example 24-1 shows the output from the debugger using the SET OUTPUT LOG command of a simple program.

Example 24-1 OpenVMS Debugger Output from SET OUTPUT LOG Command

#include <stdio.h> #include <stdlib.h> main( ) { char *p; long *lp; /* malloc returns at least quadword aligned printer */ p = (char *)malloc( 32 ); /* construct unaligned longword pointer and place into lp */ lp = (long *)((char *)(p+1)); /* load data into unaligned longword */ lp[0] = 123456; printf( "data - %d\n", lp[0] ); return; } ------- Compile and Link commands ------- $ cc/debug debug_example $ link/debug debug_example $ run debug_example ------- DEBUG session using set output log ------- Go ! break at routine DEBUG_EXAMPLE\main ! 598: p - (char *)malloc( 32 ); set break/unaligned_data set break/exception set radix hexadecimal Go !Unaligned data access: virtual address - 003CEEA1, PC - 00020048 !break on unaligned data trap preceding DEBUG_EXAMPLE\main\%LINE 602 ! 602: printf( "data - %d\n", lp[0] ); ex/inst 00020048-4 !DEBUG_EXAMPLE\main\%LINE 600+4: STL R1,(R0) ex r0 !DEBUG_EXAMPLE\main\%R0: 00000000 003CEEA1

24.3.2 The Performance and Coverage Analyzer---PCA

The PCA allows you to detect and fix performance problems. Because unaligned data handling can significantly increase overhead, PCA has the capability to collect and present information on aligned data exceptions. PCA commands that collect and display unaligned data exceptions are:

• SET UNALIGNED_DATA
• PLOT/UNALIGNED_DATA PROGRAM BY LINE

Also, PCA can display data according to the PC of the fault, or by the virtual address of the unaligned data.

24.3.3 System Services (Alpha Only)

On Alpha systems, there are eight system services to help locate unaligned data. The first three system services establish temporary image reporting; the next two provide process-permanent reporting; and the last three provide for system alignment fault tracking. The symbols used in calling all eight of these system services are located in $AFRDEF in the OpenVMS Alpha MACRO-32 library, SYS$LIBRARY:STARLET.MLB. You can also call these system services in C with #include <afrdef.h>.

The first three system services can be used together; they report on the currently executing image. They are as follows:

• SYS$START_ALIGN_FAULT_REPORT. This service enables unaligned data exception for the current image. You can use either a buffered or an exception method of reporting, but you can enable only one method at a time.
  • Buffered method. This method requires that the buffer address and size be specified. You use the SYS$GET_ALIGN_FAULT_DATA service to retrieve buffered alignment data under program control.
  • Exception method. This method requires no buffer. Unaligned data exceptions are signaled to the image, at which point a user-written condition handler takes whatever action is desired. If no user-written handler is set up, then an informational exception message is broadcast for each unaligned data trap, and the program continues to execute.
• SYS$STOP_ALIGN_FAULT_REPORT. This service cancels unaligned data exception reporting for the current image if it were previously enabled. If you do not explicitly call this routine, then reporting is disabled by the operating systems' image rundown logic.
• SYS$GET_ALIGN_FAULT_DATA. This service retrieves the accumulated, buffered alignment data when using the buffered collection method.

You can use two of the eight system services to report unaligned data exceptions for the current process. The two services are as follows:

• SYS$PERM_REPORT_ALIGN_FAULT. This service enables unaligned data exception reporting for the process. Once you enable this service, the reporting remains in effect for the process until you explicitly disable it. Once enabled, the SS$_ALIGN condition is signaled for all unaligned data exceptions while the process is active. By default, if no user-written exception handler handles the condition, this results in an information display message for each unaligned data exception.
  This service provides a convenient way of running a number of images without modifying the code in each image, and also of recording the unaligned data exception behavior of each image.
• SYS$PERM_DIS_ALIGN_FAULT_REPORT. This service disables unaligned data exception reporting for the process.

The three system services that allow you to track systemwide alignment faults are as follows:

• SYS$INIT_SYS_ALIGN_FAULT_REPORT. This service initializes system process alignment fault reporting.
• SYS$STOP_SYS_ALIGN_FAULT_REPORT. This service disables systemwide alignment fault reporting.
• SYS$GET_SYS_ALIGN_FAULT_DATA. This service obtains data from the system alignment fault buffer.

These services require CMKRNL privilege. Alignment faults for all modes and all addresses can be reported using these services. The user can also set up masks to report only certain types of alignment faults. For example, you can get reports on only kernel modes, only user PC, or only data in system space.

This chapter describes the security system services that provide various mechanisms to enhance the security of operating systems. It contains the following sections:

Section 25.1 provides an overview of the protection scheme.

Section 25.2 describes identifiers and how they are used in security.

Section 25.3 describes the rights database.

Section 25.4 describes the persona and per-thread security features.

Section 25.5 describes how to create, translate, and maintain access control entries (ACEs).

Section 25.6 describes protected subsystems.

Section 25.7 describes security auditing.

Section 25.8 describes how to determine a user's access to an object.

Section 25.9 describes SYS$CHECK_PRIVILEGE system service.

Section 25.10 describes how to implement site-specific security policies.

25.1 Overview of the Operating System's Protection Scheme

The basis of the security scheme is an identifier, which is a 32-bit binary value that represents a set of users to the system. An identifier can represent an individual user, a group of users, or some aspect of the environment in which a user is operating. A process is a holder of an identifier when that identifier can represent that process to the system. The protection scheme also includes the user identification code (UIC), the authorization database, and access control lists.

Authorization Database

The authorization database consists of the system authorization file (SYSUAF.DAT), the network proxy database, and the rights list database (RIGHTSLISTS.DAT). Note that the network proxy database is called NETPROXY.DAT on Alpha systems and NET$PROXY.DAT on VAX systems. (The file NETPROXY.DAT on VAX systems is maintained for platform compatibility, translation of DECnet Phase IV node names, and layered product support.) The system rights database is an indexed file consisting of identifier and holder records. These records define the identifiers and the holders of those identifiers on a system. When a user logs in to the system, a process is created and LOGINOUT creates a rights list for the process from the applicable entries in the rights database. The process rights list contains all the identifiers that the process holds. A process can be the holder of a number of identifiers. These identifiers determine the access rights of the list holder. The process rights list becomes part of the process and is propagated to any created subprocesses.

Access Protection

When a process without special privileges attempts to access an object (protected by an ACL) in the system, the operating system uses the rights list when performing a protection check. The system compares the identifiers in the rights list to the protection attributes of the object and grants or denies access to the object based on the comparison. In other words, the entries in the rights list do not specifically grant access; instead, the system uses them to perform a protection check when the process attempts to access an object.

Access Control Lists

The protection scheme provides security with the mechanism of the access control list (ACL). An ACL consists of access control entries (ACEs) that specify the type of access an identifier has to an object like a file, device, or queue. When a process attempts to access an object with an associated ACL, the system grants or denies access based on whether an exact match for the identifier in the ACL exists in the process rights list.

The following sections describe each of the components of the security scheme---identifiers, rights database, process and system rights lists, protection codes, and ACLs---and the system services affecting those components.

25.2 Identifiers

The basic component of the protection scheme is an identifier. An identifier represents various types of agents using the system. The types of agents represented include individual users, groups of users, and environments in which a process is operating. Identifiers and their attributes apply to both processes and objects. An identifier name consists of 1 to 31 alphanumeric characters with no embedded blanks and must contain at least one nonnumeric character. It can include the uppercase letters A through Z, dollar signs ($), and underscores (_), as well as the numbers 0 through 9. Any lowercase letters are automatically converted to uppercase.

25.2.1 Identifier Format

Each of the three types of identifier has an internal format in the rights database: user identification code (UIC) format, identification (ID) format, and facility-specific format. The high-order bits <31:28> of the identifier value specify the format of the identifier.

25.2.2 General Identifiers

You can define general identifiers to meet the specific needs of your site. You grant these identifiers to users by establishing holder records in the rights database. General identifiers can identify a single user, a single UIC group, a group of users, or a number of groups.

Bit <31>, which is set to 1, specifies ID format used by general identifiers as shown in Figure 25-1. Bits <30:28> are reserved by Compaq. The remaining bits specify the identifier value.

Figure 25-1 ID Format

You define identifiers and their holders in the rights database with the Authorize utility or with the appropriate system services. Each user can hold multiple identifiers. This allows you to create a different kind of group designation from the one used with the user's UIC.

The alternative grouping described here permits each user to be a member of multiple overlapping groups. Access control lists (ACLs) define the access to protected objects based on the identifiers the user holds rather than on the user's UIC. See Section 25.5.3.1 for information on creating ACLs.

You can also define identifiers to represent particular terminals, times of day, or other site-specific environmental attributes. These identifiers are not given holder records in the rights database but may be granted to users by customer-written privileged software. This feature of the security system allows each site flexibility and, because the identifiers can be specific to the site, enhanced security. For a programming example demonstrating this technique, see Section 25.3.2.4. For more information, also see the OpenVMS Guide to System Security.

25.2.3 System-Defined Identifiers

System-defined identifiers, or environmental identifiers, are general identifiers that are automatically defined when the rights database is initialized. The following system-defined identifiers correspond directly with the login classes and relate to the environment in which the process operates:

BATCH	All attempts at access made by batch jobs
NETWORK	All attempts at access made across the network
INTERACTIVE	All attempts at access made by interactive processes
LOCAL	All attempts at access made by users logged in at local terminals
DIALUP	All attempts at access made by users logged in at dialup terminals
REMOTE	All attempts at access made by users logged in on a network

Depending on the environment in which the process is operating, the system includes one or more of these identifiers when creating the process rights list.

25.2.4 UIC Identifiers

Each UIC identifier is unique and represents a system user. By default, when an account is created, its UIC is associated with the account's user name generating an identifier value. When the high-order bit <31> of the identifier value is zero, the value identifies a UIC format identifier as shown in Figure 25-2.

Figure 25-2 UIC Identifier Format

Bits <27:16> and <15:0> designate a group field and member field. Group numbers range from 1 through 16,382; member numbers range from 0 through 65,534.

25.2.5 Facility Identifiers

Facility-specific rights identifiers allow a range of unique binary identifier values to be reserved for a particular software product or application. Compare the format of facility-specific identifiers with the format of general identifiers and UIC identifiers, as shown in Section 25.2.1. The system normally determines the binary values of general identifiers when the system manager creates them; the system manager determines the binary values of UIC identifiers.

Figure 25-3 shows the facility-specific identifiers.

Figure 25-3 Facility-Specific Identifiers

The binary value of a facility-specific identifier is determined at the time the application is designed. The facility number of the identifier must match the facility number the application has chosen for its condition and message codes. The remaining 16-bit facility-specific value may be assigned at will by the application designer. By reserving specific binary identifier values, the application designer may code fixed identifier values into an application's calls to $CHECK_PRIVILEGE, $GRANT_ID, and so forth. It avoids the added complexity of first having to translate an identifier name to binary with $ASCTOID.

An application can choose to register the identifiers in the rights database or not, depending on its needs. If the identifiers are registered, they are visible to the system manager who may grant them to users. In any case, they will be displayed properly if they appear on access control lists. If they are not registered, they will remain invisible to the system manager. Unregistered identifiers that appear on access control lists are displayed as a hexadecimal value.

To register its identifiers, the installation procedure of the application must run a program that enters the identifiers into the rights database using the $ADD_IDENT service. You cannot specify facility-specific identifier values to AUTHORIZE with the ADD/IDENTIFIER command.

Typically, facility-specific identifiers serve to extend the OpenVMS privilege mechanism for an application. For example, consider a database manager that includes a function to allow appropriately privileged users to modify a schema. Access to this function could be controlled through a facility-specific identifier named, for example, DBM$MOD_SCHEMA. The system manager grants the identifier to authorized persons using the AUTHORIZE command GRANT/ID. The database services that modify schemas use the $CHECK_PRIVILEGE service to check that the caller holds the identifier.

In another example, a privileged program run by users when they log in uses $GRANT_ID to grant the user certain facility-specific identifiers, depending on conditions determined by the program; for example, time of day or access port name. These identifiers can be placed on the ACLs of files to control file access, or they might be checked by other software with $CHECK_PRIVILEGE.

25.2.6 Identifier Attributes

An identifier has attributes associated with it in the rights database. The process rights list includes the attributes of any identifiers that the process holds.

The use of rights identifiers can be extended with the following identifier attribute keywords:

DYNAMIC	Allows unprivileged holders of an identifier to add or remove the identifier from the process rights list using the DCL SET RIGHTS command. Conversely, an unprivileged user who does not have the attribute cannot modify the identifier.
HOLDER_HIDDEN	Prevents someone from using the SYS$FIND_HOLDER system service to get a list of users who hold an identifier, unless that person holds the identifier.
NAME_HIDDEN	Allows only the holders of an identifier to have it translated, either from binary to ASCII or from ASCII to binary.
NO_ACCESS	Specifies that the identifier does not affect the access rights of the user holding the identifier.
RESOURCE	Allows the holder of an identifier to charge resources, such as disk blocks, to an identifier.
SUBSYSTEM	Allows holders of the identifier to create and maintain protected subsystems.

Using the Resource Attribute

The following example demonstrates the advantages of defining an identifier and holders for a project.

The Physics department of a school has a common library with an associated disk quota on the system. In order to use the Resource attribute, you must enable disk quotas and establish a quota file entry using the SYSMAN utility. You want to allow the faculty members to charge disk quota that they use in conjunction with the library to the identifier PHYSICS associated with the common library and to prevent the students from charging resources to that identifier.

• Define an identifier PHYSICS with the Resource attribute in the rights database using the SYS$ADD_IDENT service.
• Enable disk quotas using SYSMAN as shown in the example.

  $ MCR SYSMAN SYSMAN> DISKQUOTA CREATE/DEVICE=DKB0: SYSMAN> DISKQUOTA MODIFY/DEVICE=DKB0: PHYSICS /PERMQUOTA=150000 - _SYSMAN> /OVERDRAFT=5000 SYSMAN> EXIT

• Create the common library and assign the identifier PHYSICS using the run-time library routine LIB$CREATE_DIR.
• Grant the identifier PHYSICS to holders FRED, a faculty member, and GEORGE, a student using the SYS$ADD_HOLDER service.

If you specify the Resource attribute for identifier FRED, he can charge disk resources to the PHYSICS identifier; if you do not specify the Resource attribute for identifier GEORGE, he will not inherit the Resource attribute associated with the identifier PHYSICS and cannot charge disk resources to the PHYSICS identifier. The following input file, USERLIST.DAT, contains valid UIC identifiers of students and faculty members:

FRED NORESOURCE GEORGE RESOURCE NANCY NORESOURCE HAROLD RESOURCE SUSAN RESOURCE CHERYL NORESOURCE MARVIN NORESOURCE

The following program reads USERLIST.DAT and associates the UIC identifiers with the identifier PHYSICS:

#include <stdio.h> #include <descrip.h> #include <ssdef.h> #include <lib$routines.h> #include <kgbdef.h> #include <nam.h> #include <string.h> #include <stdlib.h> #define IDENT_LEN 31 #define NO_ATTR 0 #define RESOURCE 1 #define NORESOURCE 0 unsigned int sys$asctoid(), sys$add_ident(), sys$add_holder(), sys$idtoasc(), convert_id( struct dsc$descriptor_s, unsigned int ); void add_holder( unsigned int, unsigned int, unsigned int); struct { unsigned int uic; unsigned int terminator; }holder; static char ascii_ident[IDENT_LEN], abuffer[IDENT_LEN], dirbuf[NAM$C_MAXRSS], targbuf[IDENT_LEN]; $DESCRIPTOR(target,targbuf); unsigned int status; main() { FILE *ptr; char attr[11]; unsigned int owner_uic, attrib, resid, bin_id; $DESCRIPTOR(dirspec,dirbuf); $DESCRIPTOR(aident, abuffer); printf("\nEnter directory spec: "); gets(dirbuf); dirspec.dsc$w_length = strlen(dirbuf); printf("\nEnter its owner identifier: "); gets(targbuf); target.dsc$w_length = strlen(targbuf); /* Add target identifier WITH resource attribute to the rights database */ attrib = KGB$M_RESOURCE; status = sys$add_ident( &target, 0, attrib, &resid); if((status & 1) != SS$_NORMAL) lib$signal( status ); else printf("\nAdding identifier %s to rights database...\n", target.dsc$a_pointer); /* Create the common directory with the target id as owner */ owner_uic = resid; status = lib$create_dir( &dirspec, &owner_uic, 0, 0); if((status & 1) != SS$_NORMAL) lib$signal( status ); else printf("Creating the directory %s...\n",dirspec.dsc$a_pointer); /* Open an input file of UIC identifiers and attribute types */ if((ptr = fopen("USERLIST.DAT","r")) == NULL) { perror("OPEN"); exit(EXIT_FAILURE); } /* Read the input file of UIC identifiers */ while((fscanf(ptr,"%s %s\n",abuffer,attr)) != EOF) { aident.dsc$w_length = strlen(abuffer); attrib = (strcmp(attr,"RESOURCE")) == 0 ? KGB$M_RESOURCE : NO_ATTR; bin_id = convert_id( aident, attrib); add_holder( bin_id, resid, attrib ); } /* Close the input file */ fclose(ptr); } unsigned int convert_id( struct dsc$descriptor_s uic_id, unsigned int attr ) { unsigned int bin_id; status = sys$asctoid(&uic_id, &bin_id, &attr); if((status & 1) != SS$_NORMAL) lib$signal( status ); else { printf("Converting identifier %s to binary format...\n", uic_id.dsc$a_pointer); return bin_id; } } void add_holder( unsigned int bin_id, unsigned int resid, unsigned int attrib ) { int i; $DESCRIPTOR(nambuf, ascii_ident); holder.uic = bin_id; holder.terminator = 0; status = sys$add_holder( resid, &holder, attrib); if((status & 1) != SS$_NORMAL) lib$signal( status ); else { status = sys$idtoasc(bin_id, 0, &nambuf, 0, 0, 0); if((status & 1) != SS$_NORMAL) lib$signal( status ); /* Remove padding */ nambuf.dsc$w_length = strlen(ascii_ident); for(i=0;i < nambuf.dsc$w_length + 1; i++) if (ascii_ident[i] == 0x20) ascii_ident[i] = '\0'; printf("\nAdding holder %s to target identifier %s...\n", \ nambuf.dsc$a_pointer,target.dsc$a_pointer); } }

	privacy and legal statement
5841PRO_064.HTML