Operating System

The HP NonStop server operating system (OS) is the foundation for all functions on the system. Sometimes referred to as Guardian or NonStop Kernel operating system, the OS resides on the $SYSTEM volume in several subvolumes :

$SYSTEM.SYSTEM

$SYSTEM.SYSnn

$SYSTEM.CSSnn

$SYSTEM.Z< name > * (* can reside on other disk volumes )

Securing the SYSTEM Disk

AP-ADVICE-SYSDISK-01 All non-HP programs that must reside on $SYSTEM should be documented and moved from the system subvolumes to a separate location. The search list can be updated to include the new subvolume

location if these programs are of general interest, but only where there is a genuine need.

AP-ADVICE-SYSDISK-02 The $SYSTEM disk as a whole should be reserved for Operating System files. $SYSTEM resources should be conserved.

AP-ADVICE-SYSDISK-03 Only the group charged with creating and maintaining the operating system installation image and those responsible for maintaining certain of the configuration files, such as PORTCONF, TACLLOCL, etc. should have WRITE access to the system configuration files.

AP-ADVICE-SYSDISK-04 No personal files should reside on the $SYSTEM disk.

AP-ADVICE-SYSDISK-05 The subvolume $SYSTEM.SYSnn is reserved for files created by DSM/SCM. Any other files placed in this subvolume will be lost when a new operating system image is installed.

RISK By default, Safeguard software creates the current Audit Pool in $SYSTEM.SAFE. The audit pools can create disk space and performance issues on $SYSTEM.

BP-SAFEGARD-CONFIG-07 The Safeguard audit trail should be moved off $SYSTEM to another, less busy, volume.

If Safeguard software's current audit pool becomes unavailable, and RECOVERY Mode is configured to DENY GRANTS, Safeguard software will deny any authorization (object access attempts) and any authentication (logon) requests that require auditing. In this case:

RISK Only successful access attempts by members of the Security Groups will be granted.

RISK What auditing occurs will be redirected to $SYSTEM.SAFE. If there is no available space on $SYSTEM, no activity that requires auditing will be allowed. It will not even be possible to switch to another Audit Pool.

BP-SAFEGARD-CONFIG-12 If AUDIT SERVICE is configured to DENY GRANTS, make sure that $SYSTEM always has enough space for 'fallback' auditing or risk disruption of service.

BP-SAFEGARD-CONFIG-13 If AUDIT SERVICE is configured to DENY GRANTS, it is especially important to configure at least one secondary Audit Pool or risk disruption of service.

Temporary Files are files created as temporary workspace for a program. Temporary files are created programmatically and are deleted when the program finishes.

Safeguard software does not restrict the creation of temporary files, such as swap files. VOLUME and SUBVOLUME authorization records are not checked when a temporary file with a name beginning with the pound or hash sign ( # ) is created. Example: #A738902.

Safeguard software does restrict the creation of temporary files by the Virtual Screen Editor (XVS or VS), which are created in the subvolume where the user invoked XVS. Example: ZZVS82S.

RISK Audit trails and audit dumps to disk require extensive space and accessibility.

BP-TMF-CONFIG-01 The TMF audit trails should not be located on $SYSTEM to avoid contention . Configure the data files on another, less busy, volume.

RISK The spooler collector's data files requires extensive space and accessibility.

BP-SPOOLER-CONFIG-01 The spooler data files should not be located on $SYSTEM to avoid contention. Configure the data files on another, less busy, volume.

AP-ADVICE-SYSDISK-06 Many other programs, such as ENFORM, may create temporary files in the execution subvolume. Most can be configured to create their temporary files in another location and not on the $SYSTEM disk.

AP-ADVICE-SYSDISK-07 Configure NSKCOM and SORT to use swap space on a disk other than $SYSTEM.

AP-ADVICE-SYSDISK-08 Monitor the $SYSTEM disk for programs that place temporary files on the $SYSTEM disk.

Current Operating System - $SYSTEM.SYSnn

Operating system files located in $SYSTEM.SYSnn get created upon each revision of the operating system to a new SYSnn subvolume. This ensures that the OS set is cohesive and compatible.

Securing the $SYSTEM.SYSnn subvolume determines the accessibility to operating system files for all users. Multiple SYSnn subvolumes can be resident on the $SYSTEM disk at any time. Only one will be currently running the operating system. The other copies can be older or newer versions that are retained for backup or upgrade staging.

RISK Older versions of the OS retained online on as a fallback option following a COLDLOAD to a new OS should be removed or secured as soon as possible. They are not automatically removed by DSM/SCM.

RISK The current OS subvolume must be owned by SUPER.SUPER. Ownership by any other user might prevent the system from COLD LOADing.

RISK No personal or system obey files or any other type of file should reside in the SYSnn subvolume. Files in the SYSnn subvolume are assumed to be files belonging to the OS and only for the current version of the OS.

RISK Only the object programs that are listed in the CUSTFILE or in HP NonStop documentation should be licensed. Please refer to the Gazette section on LICENSED File and references throughout this Gazette.

BP-OPSYS-OWNER-01 Operating System files should be owned by SUPER.SUPER

BP-OPSYS-LICENSE-01 The appropriate object files in the SYSnn should LICENSED; all others should not.

BP-OPSYS-PROGID-01 Only the appropriate object files in $SYSTEM.SYSnn should PROGID'd; all others should not.

BP-SAFE-SYSNN-01 Secure the $SYSTEM.SYSnn subvolume with an appropriate Safeguard Subvolume Protection Record.

BP-SAFE-SYSNN-02 Secure the $SYSTEM.SYSnn files that require tighter securing than the SUBVOLUME Protection Record with appropriate DISKFILE Protection Records.

	Discovery Questions	Look here:
FILE-POLICY	What is the name of the current SYSnn subvolume?	FUP
OPSYS-OWNER-01	Who owns the files in the SYSnn subvolume?	Fileinfo
OPSYS-LICENSE-01	Are only the designated files licensed?	DSAP Fileinfo Safecom
OPSYS-PROGID-01	Are only the designated files PROGID'd? DSAP Fileinfo
SAFE-SYSNN-01 SAFE-SYSNN-02	Is the $SYSTEM.SYSnn subvolume correctly secured with the Guardian or Safeguard system?	Fileinfo Safecom
OPSYS-FILELLOC-01	Are there non-system files in the $SYSTEM.SYSnn subvolume?	Fileinfo

Communication OS - $SYSTEM.CSSnn

The subvolume that contains the files that handle I/O for the 3650/6100 family of communications controllers for the operating system is CSSnn. The numeric portion of the subvolume name is the same as that of the associated SYSnn subvolume.

The CSSnn subvolume is automatically created by the SYSGEN process while installing the operating system. Similar to the SYSnn subvolume, old versions of CSSnn may be present on the system.

RISK As of Release Version Update G06.08, all files in the current CSSnn subvolume need to be secured for network READ and EXECUTE access in order for communication processes to work properly.

RISK The CSSnn subvolume needs to be secured for network READ access for TFTP communications processing.

RISK Older versions of the CSSnn subvolume retained online on as a fallback option following a COLDLOAD to a new OS should be removed or secured as soon as possible. They are not automatically removed by DSM/SCM.

BP-FILE-CSSNN-01 CSSnn.* files should be secured "NUNU".

BP-OPSYS-OWNER-03 CSSnn.* files should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-03 CSSnn.* files resides on $SYSTEM in a matching CSSnn subvolume to the SYSnn subvolume.

If available, use Safeguard software or a third party object security product to grant appropriate access to $SYSTEM.CSSnn utilities only to users who require access in order to perform their jobs.

BP-SAFE-CSSNN-01 Secure the $SYSTEM.CSSnn with a Safeguard SUBVOLUME Protection Record.

	Discovery Questions	Look here:
OPSYS-OWNER-03	Who owns the current CSSnn.* object files?	Fileinfo
FILE-SYSNN-01 SAFE-SYSNN-01	Is the $SYSTEM.CSSnn subvolume correctly secured with the Guardian or Safeguard system?	Fileinfo Safecom

Old Operating System - $SYSTEM.SYS++

Multiple SYSnn subvolumes can be resident on the $SYSTEM disk at any time. Only one will be currently running the operating system. The other copies can be older or newer versions that are retained for backup or upgrade staging.

In this handbook, the old versions of these two subvolumes will be referred to as:

SYS++

CSS++

RISK Unless the SYS++ subvolume is strictly secured, users may be able to run old versions of the utilities. The programs can be run manually by users simply by referencing the full pathname of the object file. Assume that SYS02 is an older version of the OS still resident on the system:

  RUN $SYSTEM.SYS02.FUP  

BP-FILE-OLDSYS-01 All the files in the entire old SYS++ subvolume (containing old versions of the OS) should be secured so that only SUPER.SUPER can READ, WRITE, EXECUTE or PURGE.

RISK Unless the CSS++ subvolume is strictly secured, programs can be run manually by users simply by referencing the object file. Assume that SYS02 is an older version of the OS still resident on the system:

BP-FILE-OLDSYS-02 All the files in the entire old CSS++ subvolume (containing old versions of the OS) should be secured so that only SUPER.SUPER can READ, WRITE, EXECUTE or PURGE.

If available, use Safeguard software or a third party product to restrict access to old ++ subvolumes as SUPER.SUPER only, and deny access to all other users.

BP-SAFE-OLDSYS-01 Add a Safeguard SUBVOLUME Protection Record to grant appropriate access to the SYS++ subvolume.

BP-SAFE-OLDSYS-02 Add a Safeguard SUBVOLUME Protection Record to grant appropriate access to the CSS++ subvolume.

	Discovery Questions	Look here:
FILE-OLDSYS-01 FILE-OLDSYS-02	Are old OS SYS++ and CSS++ subvolumes maintained on the $SYSTEM disk?	FUP
FILE-OLDSYS-01 SAFE-OLDSYS-01	Have all the files in any SYS++ subvolumes been secured, with either the Guardian or Safeguard system, so that only SUPER.SUPER can access any of its files?	Fileinfo Safecom
FILE-OLDSYS-02 SAFE-OLDSYS-02	Have all the files in any CSS++ subvolumes been secured, with either the Guardian or Safeguard system, so that only SUPER.SUPER can access any of its files?	Fileinfo Safecom

$SYSTEM.SYSTEM

The $SYSTEM disk as a whole should be reserved for Operating System files.

Operating system files located on the $SYSTEM.SYSTEM subvolume get replaced upon an upgrade of the operating system. Existing files that either are not operating system files or are obsolete do not get replaced or removed.

RISK No unauthorized and undocumented files, especially object files, should reside in the $SYSTEM.SYSTEM subvolume. Files in the SYSTEM sub- volume are assumed to be files belonging to the operating system or system- related files.

RISK Only the object programs that are listed in the CUSTFILE or in HP NonStop documentation should be LICENSED. Please refer to the Gazette section on LICENSED Files and references throughout this Gazette.

BP-OPSYS-OWNER-02 Operating System files should be owned by SUPER.SUPER

BP-OPSYS-LICENSE-02 Only the appropriate object files in $SYSTEM.SYSTEM should LICENSED; all others should not.

BP-OPSYS-PROGID-02 Only the appropriate object files in $SYSTEM.SYSTEM should PROGID'd; all others should not.

If available, use Safeguard software or a third party object security product to grant access to $SYSTEM.SYSTEM operating system files only to users who require access in order to perform their jobs.

BP-SAFE-SYSTEM-01 Secure the $SYSTEM.SYSTEM subvolume with an appropriate Safeguard Subvolume Protection Record.

BP-SAFE-SYSTEM-02 Secure the $SYSTEM.SYSTEM files that require tighter securing than the SUBVOLUME Protection Record with appropriate DISKFILE Protection Records.

	Discovery Questions	Look here:
OPSYS-OWNER-02	Who owns the files in the SYSTEM subvolume?	Fileinfo
OPSYS-LICENSE-02	Are only the designated files licensed?	DSAP Fileinfo Safecom
OPSYS-PROGID-02	Are only the designated files PROGID'd?	DSAP Fileinfo
SAFE-SYSTEM-01 SAFE-SYSTEM-02	Is the $SYSTEM.SYSTEM subvolume correctly secured with the Guardian or Safeguard system?	Safecom

Z Subvolumes

To help keep files organized, HP puts certain files in subvolumes starting with Z<name> on the $SYSTEM disk. (Or other alternate disk name) The <name> corresponds to the subsystem, such as ZMEASURE. The type and usage of these files differs greatly by subsystem. General guidelines are given below, unless otherwise described in this manual.

These subvolumes should all be treated similarly.

BP-FILE-ZNAMED-01 Z<name>.* files should be secured "CUCU".

BP-OPSYS-OWNER-03 Z<name>.* files in $SYSTEM.<Zname> files should be owned by SUPER.SUPER.

BP-OPSYS-OWNER-04 Z<name>.* files in $<vol>.<Zname> files should be owned by SUPER.SUPER.

BP-OPSYS-LICENSE-02 Only the appropriate object files in $SYSTEM.<Zname> should LICENSED; all others should not.

BP-OPSYS-PROGID-02 Only the appropriate object files in $SYSTEM.SYSTEM should PROGID'd; all others should not.

BP-OPSYS-FILELOC-03 Z<name>.* files resides on $SYSTEM.Z<name>

BP-OPSYS-FILELOC-04 Z<name>.* files resides on $<vol>.Z<name>

	Discovery Questions	Look here:
OPSYS-OWNER-03-04	Who owns the current $SYSTEM.Z<name>.* object files?	Fileinfo
OPSYS-LICENSE-03-04	Are only the designated files licensed?	DSAP Fileinfo Safecom
OPSYS-PROGID-03-04	Are only the designated files PROGID'd?	DSAP Fileinfo Safecom
FILE-ZNAMED-01	Are the Z <name>.* object files correctly secured with the Guardian environment?	Fileinfo

Related Topics

DSMSCM Subsystem

Configuration Files

LICENSE

PROGID