VSI OpenVMS Wiki - User contributions [en]

Security Auditing

2026-02-11T17:29:37Z

Michaelohare: /* Audit Server Database */

'''Security Auditing''' is a feature in OpenVMS that allows the system manager to track certain system events such as logins and access to resources for security purposes. Each time an audited event occurs, a record is made in the security audit log file that contains information about that event and/or an alarm is displayed on an [[REPLY/ENABLE|operator terminal]].

The [[ANALYZE/AUDIT]] utility allows you to view the audit log file. The [[SET AUDIT]] command defines the classes of events that are tracked in the audit log file.

=Events=
The full list of events can be found [[SET AUDIT#Keywords|here]]. Applications and system programs can contribute security event information by calling the following [[System Service|system services]]:
* [[$AUDIT_EVENT]]: the operating system calls the [[$AUDIT_EVENT]] system service every time a security-relevant event occurs n the system. By looking at the [[SET AUDIT]] settings, the system service determines whether you enabled uditing for the event. When the event is enabled for alarms or audits, [[$AUDIT_EVENT]] generates an audit ecord that identifies the process (subject) involved and lists event information supplied by its caller.
* [[$CHECK_PRIVILEGE]]: the operating system calls the $CHECK_PRIVILEGE system service any time a user attempts to perform a [[Privileges|privileged]] function. 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.
* [[$CHKPRO]]: the operating system calls the $CHKPRO system service any time a process (subject) attempts to access aprotected object. By looking at the [[SET AUDIT]] settings for the associated object class, the service determines whether you enabled auditing for the associated object access event. When an alarm or an audit is required, [[$CHKPRO]] generates an audit record that identifies the process (subject) and object involved and includes the final outcome and any supplemental event information supplied by its caller.
* [[$CHECK_ACCESS]]: privileged server processes use the [[$CHECK_ACCESS]] system service to determine whether their clients should be allowed access to the protected objects being served. The [[$CHECK_ACCESS]] system service provides a calling interface appropriate for servers and is layered on top of the $CHKPRO service. As a result, it performs object access auditing in the same manner as [[$CHKPRO]].

=Security Audit=
Messages of events enabled for security audit (with the [[SET AUDIT]]/ENABLE=events /AUDIT command or by setting the AUDIT [[Account flags|account flag]]) are written to the security audit log file.

=Security Alarms=
Messages of events enabled for security alarms (with the [[SET AUDIT]]/ENABLE=events /ALARM command) are written to [[REPLY/ENABLE|operator terminal]]. It is recommended that real-time events or events that should be treated immediately be enabled as both alarms and audits. To enable a terminal to receive security alarms, use [[REPLY/ENABLE]]=SECURITY.

=Security Audit Log File=
The operating system writes all security event messages to the latest version of the security audit log file. This log file is created by default during system startup in the SYS$COMMON:[SYSMGR] directory and named SECURITY.AUDIT$JOURNAL. The current file name can be viewed with [[SHOW AUDIT]]/JOURNAL. Typically, sites rename each day's log file and create a new one with [[SET AUDIT]]/SERVER=NEW_LOG.

To change the location of the security audit log file, use [[SET AUDIT]]/JOURNAL=SECURITY /DESTINATION=filespec. This should be done in [[SYSSECURITY.COM]] hefore the [[AUDIT_SERVER|audit server]] is started. Make sure that the file name you assign resolves to the same file throughout the cluster, not a file unique to each node.

Copies of audit messages can be sent to a remote log file (called an archive file) or a listener [[Mailbox|mailbox]]. This can be done with [[SET AUDIT]]/ARCHIVE and [[SET AUDIT]]/LISTENER respectively; full instructions can be found in {{Template:Sec}}.

To analyze the security audit log file, use [[ANALYZE/AUDIT]]. {{Template:Sec}} contains relevant instructions and useful tips.

=Audit Server Database=
Settings of the audit server established with the [[SET AUDIT]] command including the location of the security audit log file are stored in the audit server database, VMS$AUDIT_SERVER.DAT in SYS$COMMON:[SYSMGR]. To move the audit server database, redefine the VMS$AUDIT_SERVER logical name in the system logical name table in executive mode - this should be done in [[SYSECURITY.COM]] before the [[AUDIT_SERVER|audit server]] starts.

[[Category:Security]]
[[Category:Utilities]]

OPCOM

2025-06-18T19:21:49Z

Michaelohare: /* Privileges */ spelling

'''OPCOM''', or the Operator Communication Manager, is a tool for communicating with users and operators on an OpenVMS system. It displays messages and events on terminals designated as operator terminals and writes them to a log file.

=Event Classes=
The following event classes can be enabled for OPCOM:
* CENTRAL
* PRINTER
* TAPES
* DISKS
* CARDS
* NETWORK
* SECURITY
* LICENSE
* OPER1 through OPER12

=Related Logicals=
* OPC$OPA0_ENABLE enables or disables [[OPA0:]] as the operator terminal by default
* OPC$OPA0_CLASSES specifies the classes enabled for OPCOM on OPA0:
* OPC$LOGFILE_NAME specifies the location of the log file
* OPC$LOGFILE_ENABLE enables the creation of OPERATOR.LOG
* OPC$ALLOW_INBOUND enables the inbound traffic from a node
* OPC$ALLOW_OUTBOUND enables the outbound traffic to a node

=Commands=
REPLY/LOG enables a terminal as an operator and opens a new version of [[OPERATOR.LOG]]
REPLY/ENABLE enables a terminal as an operator for the classes specified as keywords
REPLY/DISABLE disables a terminal as an operator for the classes specified as keywords

=Privileges=
Using OPCOM requires the following privileges:
* [[OPER]] to enable or disable the operator terminal (for all classes of events)
* [[SHARE]] to log into the designated operator's terminal as another process
* [[SECURITY]] to enable or disable security events in the terminal
* none to send messages to an operator

=Operator Log=
By default, the operator log is stored in SYS$MANAGER:OPERATOR.LOG. The logfile is created if OPC$LOGFILE_ENABLE is defined as "TRUE" every time the system is rebooted. The classes are taken from OPC$LOGFILE_CLASSES or, if a log file is already open, from the current log file. If the logical does not exist, all classes are enabled. If OPC$LOGFILE_CLASSES contains an invalid class, all classes are enabled. In a clustered environment, this file is node specific.
Messages that get into the log file can be controlled with REPLY/LOG/ENABLE and REPLY/LOG/DISABLE. Generally, messages that are logged to OPA0: also go to the operator log except the following:

* System SECURITY alarms and audits enabled using SET AUDIT command. These SECURITY messages are either logged to operator terminal and/or to [[SECURITY.AUDIT$JOURNAL|SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL]].
* Messages generated by the [[LANACP]] LAN Server process when a device status changes. These messages are displayed on the operator terminal and included in the log file written by LANACP, SYS$MANAGER:LAN$ACP.LOG.

=See also=
* {{SysmanI}}

DEVOUR privileges

2025-04-01T15:28:51Z

Michaelohare: sp

'''DEVOUR''' is a group of [[Privileges|privileges]] that contains privileges with a potential to control noncritical systemwide resources:

* [[ACNT]] allows a process to create processes in which [[Accounting|accounting]] is disabled
* [[ALLSPOOL]] allows a process to allocate a spooled device
* [[BUGCHK]] allows a process to make bugcheck error log entries from user, supervisor, or compatibility mode or to send messages to the system error logger
* [[EXQUOTA]] allows a process to exceed any disk volume usage quotas set by the user's [[SYSUAF|account]]
* [[GRPNAM]] allows a process to bypass discretionary access controls on the system logical name tables in order to insert names into the [[Logical Name Table|logical name table]] for the group that the process belongs to or delete names from it
* [[PRMCEB]] allows a process to create or delete permanent common event flag clusters
* [[PRMGBL]] allows a process to create or delete permanent global sections
* [[PRMMBX]] allows a process to create or delete a permanent [[Mailbox|mailbox]]
* [[SHMEM]] allows a process to create global sections and [[Mailbox|mailboxes]] in memory shared by multiple processors if the process also has appropriate [[PRMGBL]], [[PRMMBX]], [[SYSGBL]] and [[TMPMBX]] privileges.

[[Category:Devour Privileges]]

OBJECT privileges

2025-04-01T15:28:07Z

Michaelohare: sp

'''OBJECT''' is a group of [[Privileges|privileges]] that has potential to compromise the security of [[Object Class|protected objects]] such as [[File|files]] or [[Logical Name Table|logical name tables]]. It includes:

* [[DIAGNOSE]] allows a process to run online diagnostic programs and intercept and copy messages written to the error log file
* [[READALL]] allows a process to bypass existing restrictions that would otherwise prevent the process from reading an object (such as [[UIC Protection]] or [[ACL|ACLS]])
* [[VOLPRO]] allows a process to affect [[Volume|volumes]]

[[Category:Object Privileges]]

Privileges

2025-04-01T14:24:22Z

Michaelohare: /* Types of process privileges */

'''Privileges''' are permissions that a process can have on an OpenVMS system to access system objects and resources. Privileges are stored in each user's [[User record|user record]] in the [[SYSUAF]] file.

=Types of process privileges=
A process can have default and authorized privileges. Default privileges are granted as soon as the user logs in and can be used immediately. Authorized privileges need to be enabled with the SET PROCESS/PRIVILEGE command.

=Categories of privilege=
Privileges are divided into the following seven categories according to the damage that the user possessing them could cause the system:

* None: No privileges
* [[NORMAL privileges|Normal]]: Minimum privileges to effectively use the system
* [[GROUP privileges|Group]]: Potential to interfere with members of the same group
* [[DEVOUR privileges|Devour]]: Potential to consume noncritical systemwide resources
* [[SYSTEM privileges|System]]: Potential to interfere with normal system operation
* [[OBJECT privileges|Object]]: Potential to compromise object security
* [[ALL privileges|All]]: Potential to control the system