OpenVMS Guide to System Security

Generally, for sites with high-level security requirements, a random pattern is preferable to a fixed pattern. The technology is already available that can detect and use faint residual magnetic impressions. Thus, if you conclude there is sufficient danger that a disk might be removed and read by some of this specialized analysis equipment, you may need to rewrite the erasure pattern several times. You can learn how to customize the data security erase pattern to fit your needs by studying the information provided in the file SYS$EXAMPLES:DOD_ERAPAT.MAR.

Employ erasing patterns only on disks where the security needs are the greatest. Erasures are time-consuming and affect system performance.

8.9.5.2 Prevention Through Highwater Marking

Highwater marking refers to a technique that tracks the furthest extent to which each file has been written and prohibits user attempts at reading data beyond that point.

The operating system implements true highwater marking for all sequential, exclusively accessed files, such as the set of files output from various text editors, compilers, and linkers, that is, most files a process writes. The highwater mark is updated in the file header whenever the logical end-of-file mark is updated (usually when the file is closed).

For shared files (both indexed and sequential), the operating system uses the principle of erase-on-allocate to achieve a result similar to true highwater marking. When a file is about to be created or extended, the system determines how much disk space (the extent of the file) is required and applies the security erasure pattern of zeros to the areas (extents) it allocates for writing. The file is then written into the area just erased for it. Thus, if any user gains access to the file (including its full extent) and attempts to read the area beyond where the file has been written, only the data security erase pattern is readable.

By default, the operating system turns on highwater marking for all volumes. Highwater marking is a deterrent to disk scavenging attempts. However, it does require additional I/O, which affects system performance.

You can turn off highwater marking and erase-on-allocate on a volume-by-volume basis by specifying the DCL command SET VOLUME/NOHIGHWATER_MARKING.

8.9.5.3 Summary of Prevention Techniques

As security administrator, you can apply the following controls to discourage disk scavengers:

• Provide tight physical security, particularly on those disks with the most valuable information.
• Provide tight volume protection through UIC-based protection.
• Encourage the use of the /ERASE qualifier when key files are purged or deleted through user participation or volume enforcement.
• Permit default highwater marking on your most valuable disks.

You can guard against data loss or corruption by creating copies of your files, directories, and disks. In case of a problem, you can restore the backup copy and continue your work. Secure media storage and controlled access to media are essential parts of the process. It is best to store backup media off site.

8.9.6.1 Backing Up Disks

Having an effective backup schedule is critical to protect your data. By performing regularly scheduled backup operations, you prevent the loss of accidentally deleted or damaged files.

Refer to the OpenVMS System Management Utilities Reference Manual for information about performing backups and setting up backup schedules. Be aware that the Backup utility (BACKUP) does not implement security policy; you must direct it explicitly. It runs with the security profile of the operator, which can often be privileged.

8.9.6.2 Protecting a Backup Save Set

Limiting access to backup save sets is an important part of system security. The file system treats a backup save set as a single file, whether it is stored on disk or on magnetic tape. Therefore, anyone with access to a save set can read any file in the save set. BACKUP does not check protection on individual files.

To maintain system security, it is crucial that you protect save sets adequately. Assign restrictive protection to save sets on disk and to magnetic tape volumes by using the output save-set qualifiers /BY_OWNER and /PROTECTION. Sufficient protection can prevent nonprivileged users from mounting a save-set volume or from reading files from a save set. You should also take physical security precautions with save sets stored off line by keeping backup media in locked cabinets.

When you write a save set to a Files--11 disk or a sequential disk and do not specify the /PROTECTION qualifier, BACKUP applies the process default protection to the save set. If you specify /PROTECTION, any protection categories that you do not specify default to your default process protection.

Protection information is written to the volume header record of a magnetic tape and applies to all save sets stored on the tape. Therefore, the output save-set qualifiers /BY_OWNER and /PROTECTION are effective on magnetic tape save sets only if you specify the output save-set qualifier /REWIND. This qualifier allows the tape to rewind to its beginning, to write the protection data to the volume header record, and to initialize the tape. If you specify /PROTECTION, any protection categories that you do not specify default to your default process protection. If you do not specify /REWIND with the /PROTECTION and /BY_OWNER qualifiers, the magnetic tape retains its existing protection. However, specifying /REWIND alone results in a magnetic tape without any protection.

The following example illustrates how a directory is backed up to tape:

$  BACKUP
_FROM:  [PAYROLL]  
_TO: MFA2:KNOX.BCK/LABEL=BANK01 - (1) 
_$ /REWIND/BY_OWNER_UIC=[030,003] -  (2) 
_$ /TAPE_EXPIRATION=15-JAN-1993 - (3)
_$ /PROTECTION=(S:RWE,O:RWED,G:RE,W) (4)

1. The contents of the directory [PAYROLL] is copied to file KNOX.BCK on the magnetic tape drive MFA2. The output save-set qualifier /LABEL provides the label BANK01 for the tape.
2. The output save-set qualifier /BY_OWNER assigns an owner UIC of [030,003] to the save set.
3. The output save-set qualifier /TAPE_EXPIRATION assigns an expiration date of January 15, 1993 to the tape.
4. The output save-set qualifier /PROTECTION assigns the owner of the volume read, write, execute, and delete access. System users are assigned read, write, and execute access; group users are assigned read and execute access; world users are assigned no access.

Anyone who has access to a save set can read any file in the save set. Never give a copy of your backup media to a user; a malicious user could restore the files from the tape or disk and compromise the security of the system.

When a nonprivileged user wants to restore a particular file, do not lend the volume containing the save set. You could give away access to all the files on the volume. The safest way to restore a particular file is to restore the file selectively, as shown in the following example:

$ BACKUP MTA0:JULY.BCK/SELECT=[JONES.TEXTPROC]LASTMONTH.DAT -
_$ [*...]/BY_OWNER=ORIGINAL

The selected file is restored with its original directory, ownership, and protection. In this way, the file system determines if the user is permitted access to the file.

8.9.7 Protecting Terminals

The next sections describe the controls available for restricting the use of terminals.

8.9.7.1 Restricting Terminal Use

Through the device object class template TERMINAL, the operating system sets up terminals to be accessible to the SYSTEM account only. When a user logs in, the operating system transfers ownership from a system UIC to the UIC of the current process.

You can limit logins on specific terminals in the following ways:

• Assign a system password.
• Set the terminal to /NOTYPE_AHEAD, making it impossible to log in.

The application of system passwords limits the use of those terminals to users who know the system password.

8.9.7.2 Restricting Applications Terminals and Miscellaneous Devices

To make terminals accessible to certain users as applications terminals, you may want to change any or all of the device's security characteristics. You can include the DCL command SET SECURITY/CLASS=DEVICE for specific terminals (with appropriate protection codes) in the command procedure SYS$MANAGER:SYSTARTUP_VMS.COM. This DCL command can limit access to any device that is not file structured. You might also place an ACL on the device to limit user access.

8.9.7.3 Configuring Terminal Lines for Modems

When configuring terminal lines for modems, never set the /COMMSYNC qualifier to the DCL command SET TERMINAL (or the TT$M_COMMSYNC characteristic for the TTDRIVER interface) on a line with a modem hookup that is intended for interactive use.

The qualifier disables the modem terminal characteristic that disconnects a user process from the terminal line in case of a modem phone line failure. With the /COMMSYNCH qualifier enabled, the next call on the terminal line could be attached to the previous user's process. The /COMMSYNC qualifier is intended to allow connection of asynchronous printers and other devices to terminal ports by using modem signals as flow control.

This chapter describes how to use and manage the OpenVMS auditing system. It explains how you can monitor security-relevant activity on your system by recording events as they occur on the system and subsequently analyzing this audit log.

9.1 Overview of the Auditing Process

Auditing is the recording of security-relevant activity as it occurs on the system and the subsequent analysis of this audit log. With auditing, you can monitor users' activity on the system and, if necessary, reconstruct events leading up to attempts to compromise the security of your system. Thus, it is not as much a method of protecting the system and its data as a method of analyzing and recording system use.

Anything that has to do with a user's access to the system or to a protected object within the system is considered a security-relevant activity. Such activities are called events. Typical events include the following:

• Logins, logouts, or login failures
• Changes to the authorization database
• Access to a protected object, such as a file, device, or global section
• Changes in privileges or the security attributes of protected objects

The operating system can record both successful and unsuccessful events. Sometimes the unsuccessful can be more revealing. For example, it is less important to record that a programmer displayed a file to which he had access than that the same programmer tried to but was prevented from displaying a protected file.

The event message itself can be written to two places: an audit log file or an operator terminal that is enabled to receive security class messages. As Example 9-1 shows, a message contains the following data:

1. Date and time of the message
2. Type of event
3. Date and time the event occurred
4. The process identification (PID) of the user who caused the event

Additional information in auditing messages is specific to the type of event. See Appendix D for examples of different messages.

Example 9-1 Sample Alarm Message

%%%%%%%%%%%  OPCOM  25-JUL-1995 16:07:09.20  %%%%%%%%%%%     (1)
Message from user AUDIT$SERVER on GILMORE 
Security alarm (SECURITY) on GILMORE, system id: 20300       
Auditable event:          Process suspended ($SUSPND)        (2)
Event time:               25-JUL-1995 16:07:08.77            (3)
PID:                      30C00119                           (4)
Process name:             Hobbit 
Username:                 HUBERT                            
Process owner:            [LEGAL,HUBERT]                    
Terminal name:            RTA1: 
Image name:               $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE 
Status:                   %SYSTEM-S-NORMAL, normal successful completion 
Target PID:               30C00126 
Target process name:      SMISERVER 
Target username:          SYSTEM 
Target process owner:     [SYSTEM] 

Beyond a certain set of default reporting (see Table 9-1), the kind of security event information you receive depends on the kind of information you select from a long list of possible events. This section explains how to enable the reporting of security event information. Specifically, it discusses the following topics:

• Ways to generate event messages
• Types of events the system can report
• Sources of event information

Whenever you install or upgrade your system, the OpenVMS operating system automatically audits a limited number of events. These event categories, which are shown in Table 9-1, represent major changes in the security of your system. Depending on your site's requirements, you may want to enable other forms of reporting.

You can have the operating system report on security-related activity in three different ways:

• By enabling a category of events for auditing. For example, all login failures or all changes to system parameters can be reported.
• By attaching an access control entry (ACE) to a protected object. For example, any time a user modifies a particular file, a message can be generated.
• By modifying a user's authorization record so the system audits all operations performed from the account.

Security-relevant events are divided into a number of categories called event classes. The operating system audits several event classes by default (see Table 9-1). If the security requirements at your site justify additional auditing, you enable security auditing for additional event classes by using the DCL command SET AUDIT.

To enable auditing for different event classes, use the following command format:

SET AUDIT /ENABLE=event-class[,...] {/ALARM | /AUDIT} 

The command requires two qualifiers to enable events:

• The /ENABLE qualifier defines which event classes you want audited. See Table 9-3 for a list of event classes.
• The /AUDIT qualifier or the /ALARM qualifier defines the destination for the event message.
  The /AUDIT qualifier directs the message to the audit log file, whereas the /ALARM qualifier directs the message to an operator terminal that has been enabled to receive security event messages. Critical events should be reported as both audits and alarms; less critical events can be written to a log file for later examination. The default event classes listed in Table 9-1 are audited as both alarms and audits.

The operating system begins auditing the new events on all nodes of the cluster as soon as you enable them. It continues auditing until you explicitly disable the classes with the /DISABLE qualifier. The current auditing configuration is recorded in SYS$MANAGER:VMS$AUDIT_SERVER.DAT and so it is preserved across system boots.

For more information about the SET AUDIT command, see the OpenVMS DCL Dictionary.

Table 9-1 Event Classes Audited by Default

Class	Description
ACL	Access to any object holding a security-auditing ACE.
Audit	All uses of the SET AUDIT command. This category cannot be disabled.
Authorization	All changes to the authorization database: System user authorization file (SYSUAF.DAT) Network proxy authorization file (NETPROXY.DAT or NET$PROXY.DAT) Rights database (RIGHTSLIST.DAT)
Break-in	All intrusion attempts: batch, detached, dialup, local, network, remote.
Logfailure	All login failures: batch, dialup, local, remote, network, subprocess, detached.

To see which event classes your site currently audits, enter the DCL command SHOW AUDIT. Example 9-3 displays the audit settings for a site with moderate security requirements.

Example of Enabling Event Classes

Although you can enable auditing for every possible class of security activity (/ENABLE=ALL), such an approach can result in an excessive number of auditing messages and generates too much information to analyze in a meaningful way. Therefore, Digital suggests that you evaluate your needs, as described in Section 9.3.1, and selectively audit system activity.

You can enable auditing of event classes with different levels of granularity. You can use the following methods:

• Enable a class
  To enable auditing for all login failures, for example, you enable the logfailure class by entering the following command:

  $ SET AUDIT/AUDIT/ENABLE=LOGFAILURE=ALL
  

  
  As a result of this command, the audit server reports all login failures in the security audit log file.
• Enable a subset of a class
  With certain events, you may want to be more selective in the kinds of reporting you enable. For example, it makes more sense to enable network and remote login events rather than to enable all login events.
  To enable auditing of only the network and remote logins, enter the following command:

  $ SET AUDIT/AUDIT/ENABLE=LOGIN=(NETWORK,REMOTE)
  

• Enable successful, unsuccessful, or privileged events
  Event messages that report on normal system use can easily be eliminated if you enable only unsuccessful event reports or reports for activity performed through a certain privilege.
  When auditing access events to protected objects, in particular, you need to define your information requirements more finely than you would with event classes like logins or use of the Install utility. Files and certain other protected objects are accessed so often that full enabling of the related access event class can result in an overwhelming number of event messages---so many that they can possibly mask the unusual events that do require investigation. For this reason, it is recommended that you enable access auditing only for unusual conditions, such as unsuccessful or privileged access events.
  To enable auditing of unsuccessful file access events, enter the following command:

  $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE
  

  
  Notice that the previous command enables auditing for all failed file accesses, not just failed read or write access attempts. This is recommended because access operations can be quite involved: what appears to be a simple write operation can involve several types of access. (For example, before writing to the file, the operation requires access to the volume and read access to the directory as well as access to the file within it.)
  Example 9-2 displays an event message from a file access failure. User Robinson tried to delete the file FOO.BAR, but an ACE on the file prevented it. Apparently, Robinson holds the identifier MINDCRIME, and an Identifier ACE on FOO.BAR denies access to those holding such an identifier. Furthermore, because the system owns the file, Robinson cannot gain delete access to the file through the protection code either.

Example 9-2 Audit Generated by an Object Access Event

Message from user AUDIT$SERVER on BILBO 
Security alarm (SECURITY) and security audit (SECURITY) on BILBO, system id: 19662 
Auditable event:          Object deletion 
Event information:        file deletion request (IO$_DELETE) 
Event time:               24-APR-1992 13:17:24.59 
PID:                      47400085 
Process name:             Hobbit 
Username:                 ROBINSON 
Process owner:            [ACCOUNTING,ROBINSON] 
Terminal name:            OPA0: 
Image name:               DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE 
Object class name:        FILE 
Object owner:             [SYSTEM] 
Object protection:        SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE 
File name:                _DSA2200:[ROBINSON]FOO.BAR;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 

As Section 9.2.1.1 describes, auditing access to protected objects requires careful thought because this type of event occurs so frequently. Too many event messages can overwhelm you and possibly mask the unusual events that do require investigation.

A more selective method of auditing protected objects is to include an auditing ACE in an object's access control list (ACL) and enable the ACL event class. With this approach, only access to objects with security-auditing ACEs results in an event message, not all objects of a class.

You can use two different types of auditing ACEs, depending on where you want the event reported. Alarm ACEs direct event messages to the operator terminal, whereas Audit ACEs direct event messages to the audit log file. Table 9-2 summarizes the auditing ACEs, and the OpenVMS System Management Utilities Reference Manual provides a full description of them. See Table 10-1 for a list of system files benefiting from auditing ACEs.

Table 9-2 Access Control Entries (ACEs) for Security Auditing

ACE Type	Description
Alarm ACE	Writes an event message to the operator terminal whenever the object is accessed in the specified manner. It has the following syntax: (ALARM=SECURITY[,OPTIONS=options],ACCESS=access-type[+access-type.. .])
Audit ACE	Writes an event message to the security audit log file whenever the object is accessed in the specified manner. It has the following syntax: (AUDIT=SECURITY [,OPTIONS=options],ACCESS=access-type[+access-type...])

You attach an ACE to sensitive objects by using the DCL command SET SECURITY/ACL or the access control list editor (ACL editor). Always include the SUCCESS or FAILURE keyword (or both) in the ACCESS statement of an auditing ACE.

It is a good idea to define auditing ACEs for critical system files that are not automatically audited, such as the automatic login file SYSALF.DAT, the operator log file OPERATOR.LOG, or the system accounting file ACCOUNTING.DAT. Do not monitor all access conditions, however, because such an approach can generate a large volume of messages, many of which are not useful. For example, tracking successful write operations to OPERATOR.LOG probably will not produce interesting information, but tracking unsuccessful attempts probably will.

You can add auditing ACEs to any protected object, although files are the most common objects to audit. You may want to add an auditing ACE to a print queue that is handing sensitive documents or add one to a terminal to catch attempted password grabbers (see Section 3.8).

Example of Adding an Auditing ACE

To establish an Alarm ACE for the file ACCOUNTING.DAT, enter the following command:

$ SET SECURITY/ACL=(ALARM=SECURITY,ACCESS=DELETE+CONTROL+SUCCESS+FAILURE)-
_$  SYS$MANAGER:ACCOUNTING.DAT

The ACL event class is enabled by default, but if it has been disabled at a site, you must enter the following command to reenable the use of auditing ACEs:

$ SET AUDIT/ALARM/AUDIT/ENABLE=ACL

Sometimes you may see users acting in a suspicious way. Perhaps they are logging in from a number of terminals or logging in at unusual times of the day or the week. You can monitor users' actions by modifying the auditing attribute in their user authorization records. Run the AUTHORIZE utility and set the Audit flag.

Note that setting the AUDIT flag generates an extremely large number of audit messages. The following command sequence modifies the account of user Robin:

$ RUN SYS$SYSTEM:AUTHORIZE
UAF> MODIFY ROBIN/FLAGS=AUDIT
%UAF-I-MDFYMSG, user record(s) updated

With the Audit flag set, the operating system audits the user's process. The audit log file contains a report of any action the user performs that the operating system is capable of auditing (see Section 9.2.2). You can use the Audit Analysis utility to review the user's actions. For example, to get a report on the activities of user Robin, enter the following command:

$ ANALYZE/AUDIT/SELECT=(FLAGS=MANDATORY,USERNAME=ROBIN) -
_$ SECURITY.AUDIT$JOURNAL

See Section 9.5 for a full description of the Audit Analysis utility.

9.2.2 Kinds of System Activity the Operating System Can Report

With the DCL command SET AUDIT, you can enable auditing for one or more of the event classes shown in Table 9-3. Many of the events classes have keywords permitting you to define a subset of the event class.

Table 9-3 Kinds of Security Events the System Can Report

Event Class	Description
Access	Access requests to all objects in a class. You can audit selected types of access, both privileged and nonprivileged, to all protected objects of a particular class.
ACL	Events requested by a security Audit or Alarm ACE in the ACL of an object.
Authorization	Modification of any portion of SYSUAF.DAT, NETPROXY.DAT, NET$PROXY.DAT, or RIGHTSLIST.DAT.
Breakin	Intrusion attempts.
Connection	Logical link connections or terminations through SYSMAN, DECnet Phase IV,+ DECwindows, or an interprocess communication (IPC) call.
Create	Creation of a protected object.
Deaccess	Deaccess from a protected object.
Delete	Deletion of a protected object.
Identifier	Use of identifiers as privileges.
Install	Modifications made to the known file list through the Install utility.
Logfailure	Unsuccessful login attempts.
Login	Successful login attempts.
Logout	Logouts.
Mount	Volume mounts and dismounts.
NCP	Modification to the network configuration database, using the network control program (NCP).
Privilege	Successful or unsuccessful use of privilege.
Process	Use of one or more of the process control system services.
SYSGEN	Modification of a system parameter with the System Generation utility (SYSGEN) or AUTOGEN.
Time	Modification of system time.

Although a site may enable the privilege event class, the operating system does not report every event in this class. It suppresses the following types of audits:

• Successful use of privileges with which an image is installed For example, the image SHOW.EXE is installed with WORLD privilege. When unprivileged users enter the SHOW SYSTEM command, SHOW.EXE uses WORLD privilege to perform wildcard $GETJPI system service calls. This use of WORLD privilege is not audited. However, if the same unprivileged users attempt to use the SHOW PROCESS command to display process attributes for a process that they do not have access to, the operation fails. This lack of WORLD privilege is audited even though SHOW.EXE is installed with WORLD privilege.
• Successful use of a lesser privilege than installed with the image When an image is installed with a greater privilege than used, the lesser privilege is not audited if the request is successful. For example, if an image installed with CMKRNL privilege successfully executes a $CMEXEC system service call, the use of the CMEXEC privilege is not audited. The following relationships exist:

  Greater Privilege	Privilege It Implies
  PRMMBX	TMPMBX
  CMKRNL	CMEXEC
  SYSNAM	GRPNAM
  WORLD	GROUP
  SYSPRV	GRPPRV
  BYPASS	SYSPRV, GRPPRV, READALL, DOWNGRADE, UPGRADE

• Any use of SETPRV privilege by an image installed with SETPRV Although the operating system does not audit use of SETPRV, it does audit the use of any privilege enabled with SETPRV. Digital recommends that you install an image with the privileges that it actually needs and avoid installing images with SETPRV.
• With protected subsystems, successful access by using a subsystem identifier

Although a site may enable the process event class, the operating system does not report every event in this class. It suppresses the following types of audits:

• Server processes created with the DCL command RUN/TRUSTED or the Create Process system service ($CREPRC) with the PRC$M_TCB flag set Server applications that do need to audit information regarding their clients can set the auditing flags NSA$M_SERVER or CHP$M_SERVER, which override the process no-audit setting for the duration of the auditing call.
• Process control events inside your process's job tree that have the same UIC as the requestor You do not see any process control audits when granting or revoking identifiers to or from your own process. However, events related to the use of $CREPRC and $DELPRC are always audited.

Applications and system programs can contribute security event information by calling the following system services:

• $AUDIT_EVENT
• $CHECK_PRIVILEGE
• $CHKPRO and $CHECK_ACCESS

Audit Event ($AUDIT_EVENT) System Service

The operating system calls the $AUDIT_EVENT system service every time a security-relevant event occurs on the system. By looking at the SET AUDIT settings, the system service determines whether you enabled auditing for the event. When the event is enabled for alarms or audits, $AUDIT_EVENT generates an audit record that identifies the process (subject) involved and lists event information supplied by its caller.

Check Privilege ($CHECK_PRIVILEGE) System Service

The operating system calls the $CHECK_PRIVILEGE system service any time a user attempts to perform a privileged function. (The current set of OpenVMS privileges is listed in Appendix A.) The system service performs the privilege check and looks at the SET AUDIT settings to determine whether you enabled privilege auditing. When privilege auditing is enabled, $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 the DCL command line or system service name associated with the privilege check.

Check Protection ($CHKPRO) and Check Access ($CHECK_ACCESS) System Services

  6346P016.HTM
  OSSG Documentation
  22-NOV-1996 13:05:14.66

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal