HP OpenVMS Systems Documentation
OpenVMS Guide to System Security
B.2.15 Files in SYSMSG
The directory SYSMSG contains the following files:
B.2.16 Files in SYSTEST
The directory SYSTEST contains the following files:
B.2.17 Files in SYSUPD
The directory SYSUPD contains the following files:
B.2.18 Files in VUE$LIBRARY
The directory VUE$LIBRARY contains the following files:
The security protection provided by OpenVMS VAX Version 6.1 and OpenVMS
AXP Version 6.1 has been evaluated by the National Computer Security
Center (NCSC) against the requirements specified by the "Department of
Defense Trusted Computer System Evaluation Criteria" dated December
1985. OpenVMS VAX Version 6.1 and OpenVMS AXP Version 6.1 have been
given a C2 rating.
C.1 Introduction to C2 Systems
This section describes the requirements for a C2 system and explains
the documentation that the OpenVMS product provides to support such a
C.1.1 Definition of the C2 Environment
A C2 environment is one that meets the United States Defense Department's criteria for trusted computer systems and that contains only those hardware and software components of the trusted computing base (TCB) that were included in the government's evaluation of the OpenVMS operating system.
The criteria for C2 systems are defined in the Department of Defense Trusted Computer System Evaluation Criteria, published by the Department of Defense Computer Security Center (DOD 5200.28-STD). They include the following:
The trusted facility manual is intended for the system administrator. The C2 trusted facility manual includes the following:
The federal government's evaluation of a computer system measures the
trusted computing base (TCB) against the criteria
summarized in Section C.1.1. The TCB is a combination of computer
hardware and an operating system that enforces a security policy.
C.2.1 Hardware in the TCB
The architectural design of VAX processors prevent competing programs from interfering with the data of another program. VAX hardware prevents one program from interfering with the memory of another program.
The security features described in this guide apply to any VAX
processor in the evaluated hardware configurations and to all supported
mass storage and communications devices. The Final Evaluation
Report, Compaq Equipment Corporation, OpenVMS VAX and SEVMS Version
6.1 provides a full listing of the evaluated hardware.
C.2.2 Software in the TCB
In OpenVMS operating systems, the TCB encompasses much of the operating system. It includes the entire executive and file system, all other system components that do not execute in user mode (such as device drivers, RMS, and DCL), most system programs installed with privilege, and a variety of other utilities used by system managers to maintain data relevant to the TCB.
As a convenience to customers, the OpenVMS operating system ships with more than the base operating system. The software package includes save sets and supportive images for layered products typically run on OpenVMS operating systems. Yet only the base operating system was evaluated as a C2 system. Layered products, such as DECwindows software and Display PostScript support, were not part of the evaluation. For this reason, the C2 rating does not extend to OpenVMS VAX systems running the software listed in Table C-1. The exclusion of these software components in no way implies they are insecure; it only means that they were not part of the evaluated system. After the introduction of any such software, the base system must be accredited for its particular usage.
|DECwindows is a layered product. Although DECwindows has been designed to meet the C2 requirements, it has not been evaluated.|
|DECdns distributed name service||Client support||DECdns software requires server software, which is a layered product. A cluster can make DECnet connections independently of DECdns.|
|Compaq DECamds software||Monitoring and diagnostics||Compaq DECamds software is outside the domain of the evaluated configuration.|
|LASTport and LASTport/DISK protocols||Protocol support||Compaq's Infoserver products, which are outside the security domain of a clustered system, depend on these protocols.|
|LAT protocol||Protocol support||The LAT protocol is used for connections to DECserver terminal servers, which are outside the domain of the evaluated configuration.|
|DECnet/OSI Full Names||Protocol support||Support of the use of DECnet/OSI (Phase V) node names within the OpenVMS operating system. Use of this feature is not in the C2 evaluated configuration.|
|HSM (Hierarchial Shelving Manager)||Storage Support||File Shelving is a layered product. Use of the File Shelving facility (HSM) is not supported in the C2 evaluated configuration.|
|MME (Media Management Extension)||Client Support||Media Management Extension (MME) allows the use of storage media programs. Use of media management is outside of the domain of the C2 evaluated configuration.|
|OpenVMS Management Station||The OpenVMS Management Station provides PC-based system management tools for OpenVMS. The OpenVMS Management Station has not been validated in a C2 evaluated configuration.|
|Access control strings||File access on a remote node||You should use proxy accounts instead of access control strings in an evaluated configuration.|
Typical site additions may include DECwindows software, LOGINOUT callouts, and other privileged Compaq or third-party products.
Before you add layered products, become familiar with the behavior of these products and understand their impact on your existing system. Also study the the SYSMAN database, from which layered products can be started, in the context of a C2 environment.
All site-specific additions to the trusted computing base (TCB) must be
controlled. The C2 rating applies only to the software and hardware
components described in the Final Evaluation Report, Compaq
Equipment Corporation, OpenVMS VAX and SEVMS Version 6.1. If
additional software or hardware is added to the TCB, the new TCB must
go through a system certification to demonstrate its compliance with
the C2 criteria.
C.3 Protecting Objects
The OpenVMS operating system controls access to objects that contain information. Protected objects include ODS-2 disk files, common event flag clusters, devices, all group and system global sections, logical name tables, queues, resource domains, and ODS-2 disk volumes. The capability object and the security class object enjoy full discretionary access protection but they are not objects according to the C2 evaluation criteria.
Chapter 4 and Chapter 5 describe object protection and explain how the operating system provides template profiles so all new objects have UICs, protection codes and, possibly, ACLs. Section 4.4.7, Section 4.5.6, and Section 8.8, in particular, explain how to set default protection for newly created objects.
The default protections assigned to global section and mailbox objects are less restrictive than those assigned to other objects. This is due to the fact that certain software products assume that mailbox and global section objects are created, by default, with the less restrictive protections. You can modify the template profiles for these objects so they have more stringent protection, but do keep in mind that some software products may be adversely affected.
To change the default protection, you need to modify both the template profile for the object and any existing object. For example, the following command modifies the MAILBOX template for the device class:
$ SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=MAILBOX - _$ /PROTECTION=(S:RWPL,O:RWPL,G,W) DEVICE
The operating system applies this value to all new mailboxes. The protection on each existing mailbox still has to be made more restrictive using the SET SECURITY command. For example:
$ SET SECURITY/CLASS=DEVICE - _$ /PROTECTION=(S:RWPL,O:RWPL,G,W) mailbox_name
The default object protections specified in security templates survive
system shutdown and reboot, so rebooting the system automatically
ensures that all objects created after the reboot are created with the
new default protections unless an object's creator specifies an
C.4 Protecting the TCB
The code and data that make up the OpenVMS TCB reside in files and, in
part, in the address space of the running operating system. They are
protected by the use of file access controls and memory page
protection. Memory page protection is set up by the operating system as
it executes and is normally not of concern to the system manager.
C.4.1 Protecting Files
The files that make up the TCB are correctly protected when the operating system is installed; however, sufficiently privileged users can alter the protection. Appendix B of this guide describes the correct file protection of operating system files.
When installing an OpenVMS operating system, avoid modifying any system
files except those specific to your site. You want to maintain the
security of the base operating system.
C.4.2 Privileges for Trusted Users
Certain privileges allow the holder to bypass normal file and memory access controls directly or indirectly and, therefore, must not be granted to persons other than the system manager, security administrator, or other trusted users. Privileges in four categories are appropriate only for trusted users: Objects, All, System, and Group. Refer to Table 8-2 for the privileges belonging to each of these categories. The privileges themselves are described in detail in Appendix A.
Privileges in the Objects and All categories allow the holder to violate the isolation of the TCB from untrusted users. Privileges in the System category allow the holder to interfere with normal system operation and cause denial of service, but they do not allow the holder to actually violate object access controls. Some privileges in the System category also allow access controls to be ultimately bypassed.
Privileges in the Group category permit the holder to interfere with the operations of others in the same group. The GRPPRV privilege, in particular, permits the holder to violate normal access controls within that holder's group because it grants access (through the system field of the protection code) to objects owned by subjects sharing the same group UIC.
All trusted users should be familiar with all the effects of any
operations they perform. In particular, they need to know all software
products an operation might use because a trusted user's privileges can
allow untrusted software to perform operations that OpenVMS security
policy would otherwise preclude.
C.4.3 Privileges for Untrusted Users
Untrusted users can hold any privilege in the Normal and Devour category with the exception of GRPNAM. Exercise caution in granting privileges from the Devour category; however, for they permit the holder to consume resources without limit, thereby causing possible denial of service and interference with the operations of other users on the system. Table C-2 lists privileges allowed to untrusted users.
Create network connections
Create temporary mailbox
Allocate spooled devices
Make bugcheck error log entries
Exceed disk quotas
Create/delete permanent common event flag clusters
Create permanent global sections
Create permanent mailboxes
Create/delete structures in shared memory