The federal government's evaluation of a computer system measuresthe trusted computing base (TCB) againstthe criteria summarized in Definition of the C2 Environment. The TCB is a combination of computer hardware andan operating system that enforces a security policy.
Hardware in the TCB The architectural design of VAX processors prevent competingprograms from interfering with the data of another program. VAXhardware prevents one program from interfering with the memory ofanother program.
The security features described in this guide apply to anyVAX processor in the evaluated hardware configurations and to allsupported mass storage and communications devices. The FinalEvaluation Report, Digital Equipment Corporation, OpenVMS VAX andSEVMS Version 6.1 provides a full listing of the evaluatedhardware.
Software in the TCB In OpenVMS operating systems, the TCB encompasses much ofthe operating system. It includes the entire executive and filesystem, all other system components that do not execute in usermode (such as device drivers, RMS, and DCL), most system programsinstalled with privilege, and a variety of other utilities used bysystem managers to maintain data relevant to the TCB.
As a convenience to customers, the OpenVMS operating systemships with more than the base operating system. The software packageincludes save sets and supportive images for layered products typicallyrun on OpenVMS operating systems. Yet only the base operating systemwas evaluated as a C2 system. Layered products, such as DECwindowssoftware and Display PostScript® support,were not part of the evaluation. For this reason, the C2 ratingdoes not extend to OpenVMS VAX systems running the software listedin Software Not Included in the C2-Evaluated System. The exclusionof these software components in no way implies they are insecure;it only means that they were not part of the evaluated system. Afterthe introduction of any such software, the base system must be accreditedfor its particular usage.
Table 1 Software Not Included in the C2-Evaluated System
Software
Function
Description
DECwindowssoftware
Windowing interface
DECwindows is a layered product.Although DECwindows has been designed to meet the C2 requirements,it has not been evaluated.
DECdns distributedname service
Client support
DECdns software requiresserver software, which is a layered product. A cluster can make DECnetconnections independently of DECdns.
HP DECamdssoftware
Monitoringand diagnostics
HP DECamds software is outside thedomain of the evaluated configuration.
LASTport andLASTport/DISK protocols
Protocol support
HP's Infoserver products,which are outside the security domain of a clustered system, dependon these protocols.
LAT protocol
Protocol support
The LAT protocol is usedfor connections to DECserver terminal servers, which are outsidethe domain of the evaluated configuration.
DECnet/OSIFull Names
Protocol support
Support of the use of DECnet/OSI (PhaseV) node names within the OpenVMS operating system. Use of this featureis not in the C2 evaluated configuration.
HSM (HierarchialShelving Manager)
Storage Support
File Shelving is a layered product.Use of the File Shelving facility (HSM) is not supported in theC2 evaluated configuration.
MME (MediaManagement Extension)
Client Support
Media Management Extension (MME)allows the use of storage media programs. Use of media managementis outside of the domain of the C2 evaluated configuration.
OpenVMS ManagementStation
The OpenVMS Management Stationprovides PC-based system management tools for OpenVMS. The OpenVMS ManagementStation has not been validated in a C2 evaluated configuration.
Access control strings
File access on a remotenode
You should use proxy accounts insteadof access control strings in an evaluated configuration.
Protecting Objects The OpenVMS operating system controls access to objects thatcontain information. Protected objects include ODS-2 or ODS-5 diskfiles, common event flag clusters, devices, all group and systemglobal sections, logical name tables, queues, resource domains,and ODS-2 or ODS-5 disk volumes. The capability object and the securityclass object enjoy full discretionary access protection but theyare not objects according to the C2 evaluation criteria.
The default protections assigned to global section and mailboxobjects are less restrictive than those assigned to other objects.This is due to the fact that certain software products assume thatmailbox and global section objects are created, by default, withthe less restrictive protections. You can modify the template profilesfor these objects so they have more stringent protection, but dokeep in mind that some software products may be adversely affected.
To change the default protection, you need to modify boththe template profile for the object and any existing object. Forexample, the following command modifies the MAILBOX template forthe 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 morerestrictive 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 templatessurvive system shutdown and reboot, so rebooting the system automaticallyensures that all objects created after the reboot are created withthe new default protections unless an object's creator specifiesan alternate protection.
Protecting the TCB The code and data that make up the OpenVMS TCB reside in filesand, in part, in the address space of the running operating system.They are protected by the use of file access controls and memorypage protection. Memory page protection is set up by the operatingsystem as it executes and is normally not of concern to the systemmanager.
Protecting Files The files that make up the TCB are correctly protected whenthe operating system is installed; however, sufficiently privilegedusers can alter the protection. Protection for OpenVMS System Files of this guide describes the correct file protectionof operating system files.
When installing an OpenVMS operating system, avoid modifyingany system files except those specific to your site. You want tomaintain the security of the base operating system.
Privileges for Trusted Users Certain privileges allow the holder to bypass normal fileand memory access controls directly or indirectly and, therefore,must not be granted to persons other than the system manager, securityadministrator, or other trusted users. Privileges in four categoriesare appropriate only for trusted users: Objects, All, System, andGroup. Refer to OpenVMS Privileges forthe privileges belonging to each of these categories. The privileges themselvesare described in detail in Assigning Privileges.
Privileges in the Objects and All categories allow the holderto violate the isolation of the TCB from untrusted users. Privilegesin the System category allow the holder to interfere with normalsystem operation and cause denial of service, but they do not allowthe holder to actually violate object access controls. Some privilegesin the System category also allow access controls to be ultimatelybypassed.
Privileges in the Group category permit the holder to interferewith the operations of others in the same group. The GRPPRV privilege,in particular, permits the holder to violate normal access controlswithin that holder's group because it grants access (through thesystem field of the protection code) to objects owned by subjectssharing the same group UIC.
All trusted users should be familiar with all the effectsof any operations they perform. In particular, they need to knowall software products an operation might use because a trusted user's privilegescan allow untrusted software to perform operations that OpenVMSsecurity policy would otherwise preclude.
Privileges for Untrusted Users Untrusted users can hold any privilege in the Normal and Devourcategory with the exception of GRPNAM. Exercise caution in grantingprivileges from the Devour category, however, for they permit theholder to consume resources without limit, thereby causing possibledenial of service and interference with the operations of otherusers on the system. Privileges for Untrusted Users lists privileges allowed to untrusted users.
Disable accounting Allocate spooled devicesMake bugcheck error log entries Exceed disk quotas Create/deletepermanent common event flag clusters Create permanent global sectionsCreate permanent mailboxes Create/delete structures in shared memory
Physical Security Physical and environmental securityare critical to the secure operation of the system. Allphysical components of the TCB require adequate protection, or unauthorizedpeople can jeopardize the system's security. Because the followingpractices and features jeopardize the security of the TCB, theymust not be used in a C2 environment:
Do not put the console terminal in a public area. The consoleterminal must always be physically secured because it controls operationof the CPU and, consequently, operation of the system.
Do not leave the console password disabled if theconsole has the password feature. (It is available on some VAXstation3100s, most later models, and the evaluated Alpha models.) The consolepassword prevents unauthorized personnel from using commands toboot from alternate media, to perform a conversational boot, orto modify memory.
Do not allow modems. Modems provide an avenue intothe trusted system, and the possibilities for compromising systemsecurity are enormous.
Do not leave remote diagnostics enabled. Remotediagnostics provide another avenue into the trusted system. Disableremote diagnostics by placing the diagnostics switch in the offposition.
Do not allow authentication cards. These devicesare not supported in a C2 evaluated configuration.
Do not permit physical access to cluster communicationmedia. Intruders can penetrate the system if they have physicalaccess to any processor or cable. The operating system protects all communications interfacesagainst world access by default. This includes the CI and localarea network (LAN) devices, such as the Ethernet, DSSI, FDDI, andSCSI. The CI interface is a trusted interface among members of aCI cluster and is inaccessible to unprivileged users. Unprivilegedusers should not be granted access to LAN devices.
Do not allow untrusted users to access the HSC console.Place the console in an area where only authorized personnel canuse it. You do not want untrusted users to perform sensitive operations,such as backing up and restoring disk volumes.
Do not allow users to read printer output of otherusers. Protect printer output so users have access only to theirown data.
Do not leave storage media, such as disks, tapes,and compact discs, where unauthorized users can access it. Onceusers have the media in their possession, they can read and modifyits contents.
Configuring a C2 System This section discusses C2 constraints on the use of OpenVMSfeatures. It includes the following topics:
Requirements for maintaining individualaccountability
Correct management of the audit log file
Correct use of terminals, volumes, and printers
Cluster requirements
Required settings for system parameters
Commands and software excluded from system operation
Keeping Individuals Accountable The proper use of names, UICs, and passwords ensures thatindividual accountability is enforced by the OpenVMS operating system.As a general practice, HP recommends that you use generated passwordson privileged accounts. Because the following practices and featuresresult in the loss of individual accountability, they must not beused in a C2 environment:
Donot assign the same UIC to more than one user. The UIC is used asthe universal internal user identifier; therefore, unique UICs mustbe assigned to all users.
Do not allow open accounts. Lack of a password makesan account available to all users aware of its identity. The systemmanager can prevent open accounts by never setting null passwordswith the Authorize utility (AUTHORIZE) and by ensuring that allaccounts are set up with a nonzero minimum password length.
Do not allow group accounts. Individual accountabilityis lost when more than one person shares an account. Each user mustbe given a unique account.
Do not allow guest accounts because they allow multipleusers access to resources on your system through a common account.Most needs for a guest account can be handled by special proxy loginaccounts.
Do not enable autologin. The automatic login facility(ALF) associates an account with a particular terminal instead ofa particular person and, therefore, causes a loss of individualaccountability.
Do not initiate network proxy accounts for groups.In order to preserve individual accountability, each individualin a network must be given a unique network proxy account on eachnode to which that user has access. Assign the same user name andUIC on all applicable nodes, and then set up individual proxiesamong the corresponding accounts.
Do not grant privileged access to proxy accounts.
Do not grant the DBG$ENABLE_SERVER identifer inthe rights database unless it is needed to run the debug server.
Do not log operator HSC activities to a video terminal.You must use a hardcopy printer to log operator activities so itis possible to associate a specific system operation with the personperforming it.
Ensure users are familiar with the restrictionson the use of access control strings in the evaluated configuration.(See page 3-15 in the SFUG.) Specifically, the use of access controlstrings is not permitted in an evaluated configuration. The proxylogin accounts should be used in the evaluated configuration.
Do not allow operators to perform any task fromthe HSC console without signing the operator log. The sign-in logis required to track who performed HSC console operations and when.Together with the hardcopy output, the log provides a record ofHSC operations.
Managing the Auditing Trail The security-auditing system lets you track security-relevantactivity on the system provided you manage it correctly. To followa trail of activity in the audit logs, you must have complete andaccurate records. Security event messages can be recorded in thesecurity audit log file and on any terminal designated to receive security-classevent messages. Because the following practices jeopardize a site'sability to track security-relevant events in the system, they mustnot be used in a C2 environment:
Do not disable the audit server orOPCOM. The audit server must be running to process audit event messages,and OPCOM is required to deliver alarms.
Do not use multiple audit log files in a cluster.You must use the clusterwide audit log file, which the system establishesby default. Without this clusterwide file, it is difficult to showthe precise relationship among events that occur on various clusternodes during any given time period.
Do not use a video terminal as a security operatorterminal. You must enable a hardcopy terminal to receive securityevent messages.
Do not place the security operator terminal in apublic location. Physically secure the terminal so that only authorizedpersonnel have access to it.
Do not ignore the audit log file. You must reviewthe security audit log file regularly for all audit events. In particular,notice whether any auditing modifications have been made. (Any useof the SET AUDIT command indicates some modification has taken place.)The audit log file is normally protected against reading or modificationby unauthorized users.
Do not allow tampering with the audit log file.Always place security-auditing ACEs on the system security auditlog file to enable auditing of all attempts to modify or deletethe audit log file. For example:
$ SET SECURITY SYS$MANAGER:SECURITY.AUDIT$JOURNAL -_$ /ACL=((ALARM=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE),-_$ (AUDIT=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE))
The operating system audits ACL events by default. You canverify this setting with the DCL command SHOW AUDIT. If necessary,reenable ACL alarms and audits with the following command:
$ SET AUDIT/ALARM/AUDIT/ENABLE=ACL
Do not allow trusted users to operate without supervision.You should audit the actions of trusted users (such as operators,managers, and security administrators) by enabling auditing of changesto the authorization database. Also place security-auditing ACEson captive login command procedures and the directories containingthem so you can detect modifications.
Reusing Objects Before allocating memory or protected objects like volumesand devices to new users, sites must ensure that they are free ofold data. The memory management subsystem protects against the reuseof system memory pages, and it cannot be defeated. Because the followingpractices jeopardize the clearing of old data from volumes and terminalsbefore reallocation, they must not be followed in a C2 environment:
Donot disable high-water marking on system disk volumes. The high-watermarking and erase-on-delete features of the operating system protectagainst reuse of disk blocks (see Protecting Disks).
Do not allow users to leave their terminals on afterlogging out. They must turn off their terminals so the logout messageis erased. The logout message reveals a user name and sometimesa node name. Moreover, by turning off the terminal, terminal characteristicsare reset, and memory buffers are cleared. Some Trojan horse attacksuse hardware frame buffers and the answerback capabilities thatare built into newer terminals.
Do not recycle tape volumes to new users until thetapes have been erased externally by operations personnel. The operatingsystem provides no protection against reuse of tape volumes. (Thisis because the OpenVMS operating system considers tape drives tobe single-user devices. It provides tape protection only at thevolume level; an entire volume can be assigned ownership and protectionbut individual files on the volume cannot.)
HP recommends that sites clear printers between jobs to ensurethat print jobs do not interfere with one another. A security administratorcan reset printers automatically at the start or end (or both) ofeach job by associating a device control library with the printqueue. Consult the documentation supplied with your printer to determinethe appropriate reset sequence, and then refer to the HPOpenVMS System Manager's Manual for directions on addingthat sequence to a library and associating the library with thequeue.
Configuring Clusters All valid cluster configurations, when configured as commonenvironment clusters, fully support the OpenVMS security features.Because the following practices and features result in the lossof a common environment cluster, they must not be used in a C2 environment.
OpenVMS clusters can consist of VAX and Alpha nodes.
Do not operate with multiple authorizationdatabases or audit log files. A clustered system is considered a singlesecurity and management domain and must operate with a shared authorizationdatabase and a single audit log file. If you have multiple systemdisks for performance reasons, system managers should ensure thatthe system files are identical. The following files must be shared across all cluster members:
NETOBJECT.DAT
NET$PROXY.DAT
NETPROXY.DAT
QMAN$MASTER.DAT
RIGHTSLIST.DAT
SYS$QUEUE_MANAGER.QMAN$QUEUES
SYSUAF.DAT
SYSUAFALT.DAT
VMS$AUDIT_SERVER.DAT
VMSMAIL_PROFILE.DATA
VMS$OBJECTS.DAT
VMS$PASSWORD_DICTIONARY.DATA
VMS$PASSWORD_HISTORY.DATA
VMS$PASSWORD_POLICY.EXE
Do not attach nodes to the cluster that are notpart of the evaluated system. The evaluated OpenVMS configurationincludes DECnet software bounded to the cluster environment thatis a single security domain. All physically attached nodes mustbe part of the evaluated system.
Starting Up and Operating the System A C2 system is the shipped system that has been configuredaccording to the guidelines in this appendix. When configuring yoursystem, you must observe the following guidelines:
Set security-sensitive parametersto the following values:
System Parameter
Setting
Description
LGI_CALLOUTS
0
Disables use of LOGINOUTcallouts
LOAD_PWD_POLICY
0
Disables site-specific passwordfilters
MAXSYSGROUP
7
Sets the maximum UIC valuefor the system category to single-digit UICs
NISCS_CONV_BOOT
0
Disables use of a conversationalsystem bootstrap
RMS_FILEPROT
65,280
Sets a default protectioncode for user's files of S:RWED,O:RWED,G,W
SECURITY_POLICY
0
Disables certain unevaluatedoperating system components
STARTUP_P1
"####"
Disables the minimum sequence of thestartup procedure
Do not use the CONNECT CONSOLE command to connectto a console storage device, except on a VAX 9000 system. On a VAX9000 system, use the console command SET SPU_UPDATE OFF to isolatethe storage device. Some console subsystems support a storage device,such as a tape or disk, that is used to load system and diagnosticprograms; however, the operating system also supports the capabilityto read and write data on a console storage device, so it is neccessaryto isolate the console storage device from the system. This commandis not available on the evaluated Alpha platforms.
Do not enable console operations by booting withFYDRIVER. FYDRIVER would make two DCL commands operative:
SET HOST/HSC allows a user to initiatecertain HSC console operations from an OpenVMS node
SET HOST/DUP is used for configuring DSSI devices
If you need to install FYDRIVER during system startup to configureyour HSC devices and disks or perform necessary diagnostics, thenperform a minimum boot and install FYDRIVER so you can configure devicesand so on. Then shut down the system and reboot without FYDRIVER.
ForcingImmediate Reauthentication of a Specified Subject After a Changein Access Rights A system or security administrator may force untrusted subjects to reauthenticatethemselves at any time. This might be necessary when the subject'saccess rights have been modified. The procedure is as follows and canbe performed only by a trusted subject.
This procedure assumes that there are no privilegedapplications present on the system that would enable an untrusteduser to create a detached process.
Additionally, this procedure is not suitable for forcing reauthenticationof trusted or privileged users, or where privileged applicationsare used. In these cases, a system reboot is required to adequatelyforce reauthentication.
Make the changesto the subject's authorization record in the authorization file.
Obtain the owner's UIC of the subject from the authorizationfile.
Enter the SYSMAN utility.
Use the SYSMAN utility to identify all processesowned by the subject.
In an OpenVMSCluster environment, set the SYSMAN environment clusterwide. Ifyou are not in an OpenVMS Cluster environment, skip this step.
Use SYSMAN DO SHOW SYSTEM/FULL to obtain a listingof all processes on the system or OpenVMS cluster. This commandalso lists the owner UIC and system PID of each process. Record thisinformation.
From SYSMAN, stop every process on every systemthat is owned by the subject. Note: Any process created by the subject after Step 4 is boundby the new access rights and does not need to be deleted. Therefore,this is not a recursive procedure.
In the OpenVMSCluster environment, set the SYSMAN environment to point to onlyone node. If you are not in the OpenVMS Cluster environment, skipthis step.
For each process on the system to be deleted, identifythe PID from Step 2 and use the SYSMAN DO STOP/ID=pid command tostop the job.
Repeat Steps a and b until all desired processeson all nodes of the cluster have been stopped.
HP OpenVMS Guide to System Security
Security for the System Administrator
