The term "install" has two distinct meanings in OpenVMS. The first relates to "installing a product", which is done with either the SYS$UPDATE:VMSINSTAL.COM command procedure or the POLYCENTER Software Installation (PCSI) utility (PRODUCT command). The second meaning relates to the use of the INSTALL utility, which is what concerns us here.
The INSTALL utility is used to identify to OpenVMS a specific copy of an image, either executable or shareable, which is to be given some set of enhanced properties. For example, when you issue the SET PASSWORD command, the image SYS$SYSTEM:SETP0.EXE is run. That image needs to have elevated privileges to perform its function.
The other important attribute is /SHARED. This means that shareable parts of the image (typically read-only code and data) are loaded into memory only once and are shared among all users on a system. Executable images can be installed /SHARED as well as shareable library images. (The term "shareable" has dual meanings here, too. See the OpenVMS Programming Concepts Manual for further details.)
It's important to note that there is no such thing as
"installing a shareable image with privileges". The INSTALL
utility will let you do it, but the privileges you specify will be
ignored. To have a callable routine run with enhanced privileges that
are not available to its caller, you must construct your routines as
"user-written system services" (UWSS) and install the
image with the /PROTECT qualifier. See the OpenVMS Programming
Concepts Manual for more information on user-written system
services. Note also that in many cases the need to grant privileges to
an image can be replaced with the use of the
"Protected Subsystems" feature that grants a rights
identifier to an image. See the OpenVMS Guide to System
Security for information on Protected Subsystems.
5.2 Are there any known viruses for OpenVMS?
Viruses and worms are common on personal computers because the operating systems involved, such as the Microsoft MS-DOS, Windows 95, Windows 98 and Windows ME variants, do not particularly protect the operating system or the file system against hostile action by programs. Microsoft Windows NT, Windows 2000 and Windows XP do implement protections for specific configurations and do implement memory protection models, but many users of these systems choose to operate with full adminstrator access and thus the available protections are entirely defeated and entirely not relevent, and any program that can activate itself or can cause the user to activate the code can subvert the operating system and take over the hardware, at which point the malicious code can do most anything it wishes, including hiding copies of itself in other programs or in the file system, redistributing itself via mail, IM, or network connections, or can be used as a zombie in staging attacks on other systems.
This is less likely with multi-user systems such as OpenVMS, Unix, Linux, MVS and other platforms for various reasons. First, the operating system runs in a privileged mode in memory that is protected against modification by normal user programs. Any program cannot simply take over the hardware as it can on operating systems without security and particularly without memory page protections. Secondly, multi-user systems can be set up so that non-privileged programs cannot modify system programs and files on disk, and this is normal for most installations. Both of these protection schemes mean that traditional viral infections don't work on these OSes. Third, typical applications and configurations tend to prevent the uncontrolled execution of untrusted code as part of received mail messages or web access; one of the central vulnerabilities of the Microsoft Windows platform involves its intentionally easy ability to dynamically (and transparently) activate code and macros that are embedded within mail messages and within data files.
It is possible for OpenVMS and other multi-user systems to become infected by viruses or worms, but to do so, the program containing the virus must be run from a user account that has amplified privileges. So long as the system administrator is careful that only trusted applications are run from such accounts (and this is generally the case) and so long as there are no OpenVMS system security breaches (due to malicious operator activity, OpenVMS errors, or errors within trusted and privileged product packages) there is no of modifications to the operating system or other protected files from the virus or the worm.
The FAQ maintainer is aware of a few (and very old) DECnet worms that have affected OpenVMS systems on DECnet networks ("WANK" was one), but is aware of no OpenVMS viruses that are loose in the field.
To protect against viruses and other attempts at system interference or misuse, please follow the security recommendations in the OpenVMS Guide to System Security. Additionally, you will want to keep your OpenVMS ECOs current and you will want to apply all mandatory ECO kits and any security MUPs for OpenVMS and OpenVMS products, and you will want to keep to OpenVMS releases with Prior Version Support (PVS) or with Current Version Support. (This is obviously a general system maintenance recommendation, in addition to being a good system security recommendation---new security features and capabilities are implemented in more recent OpenVMS releases, for instance. Details on PVS releases are available over in Section 5.10.6.) You may also want to consider optional software products which can monitor your system for intrusion or infection attempts. Computer Associates (CA) offers various products in this area, as to other vendors.
Rocksoft offers the Veracity data integrity tool (for info, send mail to email@example.com). MD5 tools are also available; see Section 5.30 for details on MD5.
Tools to scan OpenVMS file systems for Microsoft Windows infections are and have been available, including a commercial package from Sophos , and a port of the open source Clam Antivirus scanner at http://www.clamav.net/ and with an OpenVMS port at http://fafner.dyndns.org/~alexey/clamav.zip .
These scanning tools are particularly useful for systems running Samba
or Advanced Server (PATHWORKS), as these servers tend to have a higher
population of files intended for Microsoft Windows systems users, and
as common virus and worm attacks can find and infect files on the file
shares that these products can provide.
These infections do not target OpenVMS itself, though the OpenVMS
server (and any other platform and any other server capable of storing
files for Windows systems) can silently host files containing common
Microsoft Windows infections.
5.3 Sources of OpenVMS security information?
Where can I get information on OpenVMS system security?
ISO-9660 support was added in the following releases:
An add-on ISO-9660 kit was also available for OpenVMS VAX V5.5, V5.5-1, V5.5-2, and V5.5-2H4. This requires the installation of the F11CD kit from the InfoServer CD, from the Consolidated Distribution CD under the InfoServer area, or the F11CD ECO kit. (Upgrades to V6 and later are strongly recommended.)
By default, OpenVMS senses the specific type of media. If you are working with dual-format media---media that uses both the ODS-2 and ISO-9660 formats on the same CD-ROM---then MOUNT will first detect and then default to the ODS-2 format. If you wish to override this and explicitly mount the media using ISO-9660, use the command:
$ MOUNT/MEDIA_FORMAT=CDROM device-name[:] [volume-label]
In most circumstances, you will not need nor will you want to include an explicit /MEDIA_FORMAT specification. For further information, please refer to the OpenVMS MOUNT Utility Manual. Particularly note the information on the MOUNT /MEDIA_FORMAT and /UNDEFINED_FAT qualifiers.
The MOUNT /UNDEFINED_FAT qualifier is of interest because ISO-9660 media can be mastered on a wide variety of operating system platforms, and these platforms do not necessarily support the semantics needed for files containing predefined record formats. The /UNDEFINED_FAT allows you to specify the default attributes for files accessed from volumes using the ISO-9660 format.
An example which works for most CD-ROMs is:
$ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_FAT=STREAM:2048 DUA0: FREEWARE
This particular MOUNT command forces access to the CD-ROM media using the ISO-9660 volume structure, and the use of the MOUNT /UNDEFINED_FAT qualifier causes any file whose file attributes are "undefined" to be returned with "stream" attributes with a maximum record length 2048.
On OpenVMS, the ISO-9660 format is (internally) considered to be the ODS-3 file structure, while the High Sierra extensions to the standard are considered to be the ODS-4 file structure. The Rock Ridge extensions are not currently available on OpenVMS.
For details on ODS-1 and ODS-2 file specifications, see Kirby McCoy's VMS File System Internals Manual (published by Digital Press, but potentially out of print), and see:
A growing number of OpenVMS products are being provided in PCSI (POLYCENTER Software Installation) kits which are installed using the PRODUCT INSTALL command. These are alternatives to or replacement for VMSINSTAL kits which were BACKUP savesets. PCSI kits are not BACKUP savesets and are structured differently from VMSINSTAL kits.
If you want to extract product files from a PCSI kit, create a directory into which the kit should be expanded and use the following command:
$ PRODUCT COPY prodname /SOURCE=[where-the-kit-is] - /DEST=[destination-directory] /FORMAT=REFERENCE
A PCSI kit file has a file specification of the following form:
In this example, "FORTRAN" is the "prodname". PCSI
will expand the kit files into the directory you specify and
subdirectories beneath such as [SYSEXE], [SYSLIB], etc., reflecting the
eventual destination of files found there. Most of the actual product
files (images, etc.) will be in the subdirectories. In the top-level
directory will be a file with the file type PCSI$DESCRIPTION that
specifies where various files should go. For more details, see the
POLYCENTER Software Installation Developer's Guide for
OpenVMS, which can be found in the OpenVMS documentation on the
Consolidated Online Documentation CD-ROM.
5.6 Emergency (Conversational) System Startup?
If you need to perform system management operations on an OpenVMS system and cannot access the system through normal means---the password on the SYSTEM username was forgetten and no other privileged usernames are available, or one or more core system product authorization key (PAK) software licenses are unavailable or expired---then you must perform a conversational (emergency) bootstrap.
Here are the steps:
B/R5:1 B/1 @GENBOO
b -flags 0,1
B/E0000001 B/R5:E0000001 @<console media procedure name varies widely>
b -flags e,1
fsn:\efi\vms\vms_loader.efi -flags e,1
SET/STARTUP OPA0: SET WINDOW_SYSTEM 0 SET WRITESYSPARAMS 0 CONTINUE
$ SPAWN $ @SYS$SYSTEM:STARTUP
Some system managers will suggest a method using the UAFALTERNATE system parameter rather than the SET/STARTUP OPA0: command shown. This approach is not always available and is accordingly less commonly recommended, as there can easily be an alternate user authorization database (SYS$SYSTEM:SYSUAFALT.DAT) configured on the system. With a system manager that has configured an alternate SYSUAFALT.DAT file, the UAFALTERNATE method will fail---well, assuming you do not know the password of a privileged username stored within SYSUAFALT.DAT, of course.
The UAFALTERNATE system parameter is used to trigger what is sometimes known as the console backdoor. The OPA0: system console is critical to system operations and system security, and will allow access when the SYSUAF system authorization database is unavailable or corrupted, when core product license PAKs are not registered, expired or disabled (NOLICENSE errors), or in various other cases of system failures. All this is in addition to the role of the console in the display of certain system-critical event messages. Access to the OPA0: console has a security exposure that is equivalent to direct access to the system hardware.
When LOGINOUT detects an error (such as a SYSUAF corruption, by a missing SYSUAF, missing product licenses, or other trigger), it will prevent access to the OpenVMS system from all terminals except the system console. The OPA0: system console will be allowed access, and the resulting process will be fully privileged. Resetting the UAFALTERNATE system parameter---in the absence of an alternate SYSUAF system authorization database---will cause the console backdoor to be opened simply because LOGINOUT cannot locate SYS$SYSTEM:SYSUAFALT.DAT. When the authorization database cannot be located, access will be granted from the console only.
For further information on emergency startup and shutdown, as well as for the official OpenVMS documentation on how to change the SYSTEM password from the console in an emergency, please see the OpenVMS System Manager's Manual in the OpenVMS documentation set.
For information and recommendations on setting up OpenVMS system security, please see the NCSC Class C2 appendix of the Guide to OpenVMS System Security manual, also in the OpenVMS documentation set.
You can also use the conversational bootstrap technique shown earlier (the steps until SET/STARTUP) to alter various system parameters, as well. At the SYSBOOT prompt, you can enter new parameters values:
SHOW MAXPROCESSCNT SET . 64 CONTINUE
The [.] is a shorthand notation used for the last parameter
examined within SYSGEN and SYSBOOT.
5.6.1 I've forgotten the SYSTEM password - what can I do?
If you have forgotten or do not have the password for the SYSTEM username, you must perform the conversational bootstrap as described in Section 5.6, and must enter the following commands once you have reached the dollar ($) prompt:
$ SET DEFAULT SYS$SYSTEM: ! or wherever your SYSUAF.DAT resides $ RUN SYS$SYSTEM:AUTHORIZE MODIFY SYSTEM /PASSWORD=newpassword EXIT
You have now reset the password on the SYSTEM username.
5.6.2 My product licenses have expired - what can I do?
If you have a system with no licenses for OpenVMS or for OpenVMS users and thus cannot log into the OpenVMS system normally, you should be able to log into the console serial terminal---this is the terminal device known as OPA0:---and perform the commands necessary.
For systems that are not configured with an accessable console serial terminal---as can be the case with how some DECwindows workstations are configured---you must log in over the network or from a local serial connection. If you cannot log in over a network connection (SET HOST, telnet, etc) or from another local serial terminal connection, you will have to halt the system and perform a conversational bootstrap as described in Section 5.6. You must then enter licensing-related commands once the conversational bootstrap has reached the dollar ($) prompt.
Use the following DCL command to invoke a menu that allows you to manage and to register new or replacement license PAKs:
You have now registered the license PAKs. Direct use of the DCL commands LICENSE and SHOW LICENSE and such is also obviously available.
If you wish to connect a serial console on your DECwindows workstation, please see Section 184.108.40.206, Section 14.3.6, Section 11.10, and Section 14.17.
For information on troubleshooting DECwindows, please see Section 11.5.
5.7 How do I change the node name of an OpenVMS System?
The first step is to get a BACKUP of the system disk before making any changes---use the system disk backup procedures as documented in the OpenVMS System Management Manual, making sure to use the procedures and commands appropriate for the system disk.
Changing the node name involves a number of steps---the node name tends to be imbedded in a number of different data files around the system.
There are likely a few other areas where the nodename will be stored. Local procedures and data files are one such example, and various sites will have the system name loaded in the operator control panel via the OCP_TEXT console environment variable available at the SRM prompt on some Alpha systems is another.
If the system is configured in a VMScluster and you change either the SCSNODE or the SCSSYSTEMID---but not both values---then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.)
To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase IV area number by 1024, and add the DECnet Phase IV node number. For example, the SCSSYSTEMID value for a DECnet node with address 19.22 is 19478. ((19 * 1024) + 22 = 19478)
This may well have missed one or two configuration tools (or more!) that are needed at your site---the node name tends to get stored all over the place, in layered products, and in local software...
Also see Section 15.6.3 and Section 15.6.4.