HP OpenVMS systems
Auditing is the recording of security-relevant activity as it occurs on a system. See the HP OpenVMS Guide to System Security for a list of all types of security-relevant activity or classes of events that are audited. The following table describes the security services that provide security auditing:
|SYS$AUDIT_EVENT||Appends an event message to the system audit log file or sends an alarm to a security operator terminal|
|SYS$CHECK_PRIVILEGE||Determines whether the caller has the specified privileges or identifiers|
The system service SYS$AUDIT_EVENT is used to report security events to
the auditing system. It examines the settings of the DCL command SET
AUDIT to determine if an event is enabled for auditing. If the event is
enabled for alarms or audits, SYS$AUDIT_EVENT generates an audit record
and appends it to the system audit log file (or sends an alarm to a
security operator terminal) that identifies the process involved and
lists information supplied by its caller.
32.8 Checking Access Protection
The operating system provides two system services that allow a process to check access to objects on the system: SYS$CHKPRO and SYS$CHECK_ACCESS. The SYS$CHKPRO service performs the system access protection check on a user attempting direct access to an object on the system; SYS$CHECK_ACCESS performs a similar check on a third party attempting access to an object. The following table describes the security services that provide access checking:
|SYS$CHECK_ACCESS||Invokes a system access protection check on behalf of another user|
|SYS$CHKPRO||Invokes a system access protection check|
The SYS$CHKPRO and SYS$CHECK_ACCESS system services have been extended
to support auditing. The HP OpenVMS Guide to System Security describes how to use the
auditing function. The HP OpenVMS System Services Reference Manual: A--GETUAI describes how to use the two
system services. These services are described in the following sections.
32.8.1 Creating a Security Profile
The SYS$CREATE_USER_PROFILE system service returns a user profile,
using information in the rights database and the system authorization
database to generate the profile. The system services SYS$CHECK_ACCESS
or SYS$CHKPRO accept as input the profile from SYS$CREATE_USER_PROFILE.
32.8.2 SYS$CHKPRO System Sevice
The SYS$CHKPRO system service invokes the access protection check used by the system. The service does not grant or deny access; rather, it performs the protection check. Subsequently, an application might grant or deny access to the specified object.
To pass the input and output information to SYS$CHKPRO, use the itmlst argument, which is the address of an item list of descriptors. The SYS$CHKPRO service compares the item list of the rights and privileges of the accessor to a list of the protection attributes of the object to be accessed. If the accessor can access the object, SYS$CHKPRO returns the status SS$_NORMAL; if the accessor cannot access the object, SYS$CHKPRO returns the status SS$_NOPRIV. The SYS$CHKPRO service does not grant or deny access. The subsystem itself must grant or deny access based on the output (SS$_NORMAL or SS$_NOPRIV) from SYS$CHKPRO.
The SYS$CHKPRO service also returns an item list of the rights or privileges that allowed the accessor access to the object, as well as the names of security alarms raised by the access attempt. For information about the item codes defined for SYS$CHKPRO, see the description of SYS$CHKPRO in the HP OpenVMS System Services Reference Manual.
See the HP OpenVMS Guide to System Security for a flowchart describing how SYS$CHKPRO
evaluates an access request attempt.
32.8.3 SYS$CHECK_ACCESS System Service
The SYS$CHECK_ACCESS service performs a protection check on a third-party accessor. An example of this is a file server program that uses SYS$CHECK_ACCESS to ensure that an accessor (the third party) requesting a file has the required privileges to do so.
You pass the input and output information to SYS$CHECK_ACCESS by using the itmlst argument, which is the address of an item list of descriptors. You also pass the name of the accessor and the name and type of the object being accessed by using the usrnam, objnam, and objtyp arguments, respectively. The SYS$CHECK_ACCESS service compares the rights and privileges of the accessor to a list of the protection attributes of the object to be accessed. If the accessor can access the object, SYS$CHECK_ACCESS returns the status SS$_NORMAL; if the accessor cannot access the object, SYS$CHECK_ACCESS returns the status SS$_NOPRIV.
The SYS$CHECK_ACCESS service does not grant or deny access. The subsystem itself must explicitly grant or deny access based on the output (SS$_NORMAL or SS$_NOPRIV) from SYS$CHECK_ACCESS.
The SYS$CHECK_ACCESS service also returns an item list of the rights or
privileges that allowed the accessor to access the object, as well as
the names of security alarms raised by the access attempt. For
information about the item codes defined for SYS$CHECK_ACCESS, see the
description of SYS$CHECK_ACCESS in the HP OpenVMS System Services Reference Manual.
The SYS$CHECK_PRIVILEGE system service determines whether the caller has the specified privileges or identifiers. The service performs the privilege check and looks at the SET AUDIT settings to determine whether the system administrator enabled privilege auditing. When privilege auditing is enabled, SYS$CHECK_PRIVILEGE generates an audit record. The audit record identifies the process (subject) and privilege involved, provides the result of the privilege check, and lists supplemental event information supplied by its caller. Privilege audit records usually contain either the DCL command line or the system service name associated with the privilege check.
SYS$CHECK_PRIVILEGE completes asynchronously; that is, it does not wait
for final status. For synchronous completion, use the
32.10 Implementing Site-Specific Security Policies
Occasionally, you may need to write routines that implement
site-specific policies or special algorithms. The routines that you
write can either replace or augment built-in operating system policies.
This section contains instructions for replacing key operating system
security routines with routines that are specific to your site. Two
types of routines are discussed: loadable system services and shareable
32.10.1 Creating Loadable Security Services
This section describes how to create a system service image and how to update the SYS$LOADABLE_IMAGES:VMS$SYSTEM_IMAGES.DATA file, which controls site-specific loading of system images. These procedures update the loading of system images for all nodes of a cluster.
Currently, you can replace the following three system services with services specific to your site:
|SYS$ERAPAT||Generates a security erasure pattern|
|SYS$MTACCESS||Controls magnetic tape access|
|SYS$HASH_PASSWORD||Applies a hash algorithm to an ASCII password|
When you create the system service, you code the source module and define the vector offsets, the entry point, and the program sections for the system service. Then, you can assemble and link the module to create a loadable image.
Once you have created the loadable image, you install it. First, you copy the image into the SYS$LOADABLE_IMAGES directory and add an entry for it in the operating system's images file using the System Management utility (SYSMAN). Next, you invoke the system images command procedure to generate a new system image data file. Finally, you reboot the system to load your service.
The following sections describe how to create and load the the Get Security Erase Pattern (SYS$ERAPAT) system service.
The following files in SYS$EXAMPLES: are present only on VAX systems, though they work on Alpha and I64 systems, but are not supplied on Alpha and I64 systems:
You can find an example of the SYS$ERAPAT system service in
SYS$EXAMPLES:DOD_ERAPAT.MAR on a VAX system. The description here also
applies to the Hash Password (SYS$HASH_PASSWORD) and Magnetic Tape
Accessibility (SYS$MTACCESS) system services. You can find an example
of how to prepare and load the SYS$HASH_PASSWORD service in
SYS$EXAMPLES:HASH_PASSWORD.MAR on a VAX system.
184.108.40.206 Preparing and Loading a System Service
With the following example, use this procedure to prepare and load a system service, in this case SYS$ERAPAT:
$SYSVECTORDEF ; Define system service vector offsets
SYSTEM_SERVICE ERAPAT, - ; Entry point name <R4>, - ; Register to save MODE=KERNEL,- ; Mode of system service NARG=3 ; Number of arguments
DECLARE_PSECT EXEC$PAGED_CODE ; Pageable code PSCET DECLARE_PSECT EXEC$PAGED_DATA ; Pageable data PSECT DECLARE_PSECT EXEC$NONPAGED_DATA ; Nonpageable data PSECT DECLARE_PSECT EXEC$NONPAGED_CODE ; Nonpageable code PSCET
$ MACRO DOD_ERAPAT+SYS$LIBRARY:LIB.MLB/LIB
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> SYS_LOADABLE ADD _LOCAL_ SYS$ERAPAT - _SYSMAN> /LOAD_STEP = SYSINIT - _SYSMAN> /SEVERITY = WARNING - _SYSMAN> /MESSAGE = "failure to load SYS$ERAPAT.EXE"
%SYSINIT-E-failure to load SYS$ERAPAT.EXE -SYSINIT-E-error loading <SYS$LDR>SYS$ERAPAT.EXE, status = "status"
|NO_PHYSICAL_MEMORY||Physical memory is not available.||Check SYSGEN parameters.|
|NO_POOL||Amount of nonpaged pool is insufficient.||Check SYSGEN parameters.|
|MULTIPLE_ISDS||Encountered more than one image section of a given type.||Check link options.|
|BAD_GSD||An inconsistency was detected.||Verify that the image was linked properly.|
|NO_SUCH_IMAGE||The requested image cannot be located.||Check image name against images in SYS$LOADABLE_IMAGES.|
With the following example, use this procedure to remove an executive loaded image; in this case, SYS$ERAPAT.EXE:
SYSMAN> SYS_LOADABLE REMOVE _LOCAL_ SYS$ERAPAT
A site security administrator can screen new passwords to make sure they comply with a site-specific password policy. (See the HP OpenVMS Guide to System Security for more information.) This section describes how a security administrator can encode the policy, create a shareable image and install it in SYS$LIBRARY, and enable the policy by setting a SYSGEN parameter.
Installing and enabling a site-specific password policy image requires
both SYSPRV and CMKRNL privileges.
220.127.116.11 Creating a Shareable Image
To compile and link a shareable image that filters passwords for words that are sensitive to your site, perform the following steps:
To install a shareable image, perform the following steps:
$ COPY VMS$PASSWORD_POLICY.EXE SYS$COMMON:[SYSLIB]/PROTECTION=(W:RE) $ INSTALL ADD SYS$LIBRARY:VMS$PASSWORD_POLICY/OPEN/HEAD/SHARE
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> USE ACTIVE SYSGEN> SET LOAD_PWD_POLICY 1 SYSGEN> WRITE ACTIVE SYSGEN> WRITE CURRENT
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS
The Authentication and Credential Management (SYS$ACM[W]) service provides a standard programming interface for authentication, and can return credentials needed to enforce security policies of OpenVMS system logins. The SYS$ACM system service also provides a standard programming interface for user password management.
The SYS$ACM service might require the user, depending on the user name, to furnish two, one, or zero passwords. Other requirements might exist, such as supplying a code number from a "see-through" hardware token, or inserting a smart card into a reader. It is important that the program that calls SYS$ACM be relieved of the need to know all of these requirements, particularly because such a program might be used at multiple sites having different sets of rules.
Along with user authentication, the ACM service provides integrated credentials through normal and extended persona support. Normal persona support allows code to obtain native, that is, OpenVMS, process credentials, which contain username, UIC, and rights identifiers. Extended persona support also enables a process to obtain non-native credentials. As an example, this support would use both Windows NT credentials and OpenVMS credentials.
Use this chapter together with the description of the SYS$ACM[W] system service from the HP OpenVMS System Services Reference Manual: A--GETUAI. While this chapter presents a conceptual view, that manual contains the detailed formats and rules.
1 See the Authentication Glossary at the end of this manual for an explanation of this and other terminology.
When a user logs in to a system or runs an application that requires authentication, a dialogue takes place between that user and the system (or application). Policies may differ in some respects, but each requires the following basic functions of user identification, authentication, and authorization:
An authentication policy is defined by a particular combination of user identification, authentication, and authorization attributes.
Policy attributes include the following:
Two authentication policies are presently supported: standard OpenVMS
policy and external authentication with Microsoft distributed
33.2 ACME Subsystem Components
The Authentication and Credential Management Extensions (ACME) subsystem provides authentication and persona-based credential services. Applications can use these services to interact with the user to perform one or more of the following functions: user authentication, password change, and persona creation and modification. Both standard OpenVMS authentication and external authentication policies are supported, so applications use the same mechanisms as used by the system's LOGINOUT and SET PASSWORD components.
The ACME subsystem consists of the SYS$ACM system service, the ACME_SERVER process, one or more ACME (policy-provider) agents, and SET [SHOW] SERVER ACME configuration and management commands:
With the introduction of the SYS$ACM[W] system service, operations that were formerly handled entirely within the LOGINOUT and SET PASSWORD programs are now distributed across multiple processes. The user interface activities remain in the original programs, as shown on the left side of Figure 33-1. Actual authentication calculations, however, have been moved to the ACME server process, as shown on the right side of that figure. The VMS ACME supports traditional authentication interactions for the VMS domain of interpretation (DOI). Other ACME agents may support additional DOIs or assist the VMS ACME, for example by providing stronger authentication.