Guardian Personality

Guardian operating system security is a matrix composed of subject, object and access rules defined at the object level. Extensions have been made over time to accommodate a more sophisticated access control system. In Guardian terminology, subjects are users, objects are diskfiles and the access is defined by the diskfile security vector.

The command interpreter is called Tandem Advanced Command Language (TACL). It is both a command interpreter and the interpreter for the TACL Control Language, which supports a job control language. There are two security issues presented in TACL. First, TACL can be used to write job control language programs called "macros" that can change underlying command interpreter basics such as the act of logging off or the act of starting a program. Second, during the logon process, TACL executes existing TACL macros named according to a certain standard.

Security and Audit Controls in Guardian Systems

Security Components

The Guardian security components are:

Users (Subjects)

Objects

File Security

Users

Guardian defines users (subjects) by assigning a unique user name and number to each user:

<GroupName>.<MemberName>

< Group Number>,<Member Number>

The combination of GroupName.MemberName must be unique for a single system and unique over the network of Guardian systems if the user will have access to any system other than that user's local system.

There is also an alphanumeric user name assigned based on the group and user number combination. The group numbers range from 0 to 255. Group 255 is reserved and has many inherent privileges. This group is usually called the "SUPER" group. User numbers range from 0 to 255, also. The user number 255 is referred to as the "group manager" and has many inherent privileges. The userid 255,255 is commonly referred to as the "SUPER.SUPER" userid and has full and unrestricted access to the system.

Userids	User Names	Notes
0,0	NULL.NULL	Used for command interpreters that have not been authorized for any user ("logged off")
*,*	<groupname>.<username>	A standard userid
*,255	<groupname>.<manager>	The manager of the group with many inherent privileges
255,*	SUPER.<username>	A userid in the SUPER group with many inherent privileges
255,255	SUPER.SUPER	The super or root userid for the system

A userid is "local" to the system where it is created. It can be "networked" with the same userid on another system by means of the "remote password," which is not really a password, but instead, a simple yes/no permission to use another Guardian system in the network. A userid that was created on a different system and has traversed the Expand network to use the local system is called a "remote" user.

There are privileges inherent in certain userids. These, and all aspects of secure user management are discussed in detail in the section on User Administration in Part Three.

Objects

All devices, processes and diskfiles are considered objects on the HP NonStop server, but the basic operating system, known as the Guardian system, only provides user definable security for diskfile objects. This section contains only a brief overview. All aspects of securing NonStop objects are discussed in the section on Object Security in Part Five.

Diskfiles

DISKFILES have four-part names.

Standard NonStop Diskfile Naming Convention:

\SYSTEM.$DISKVOL.SUBVOLUM.DISKFILE *

\SYSTEM Up to 7 characters , name of Guardian system where disk is physically attached

$VOLUME Up to 7 characters, logical name of the disk where file is physically located.

SUBVOLUME Up to 8 characters, a collection of diskfiles

DISKFILE Up to 8 characters, the final component of the filename.

Example:

  \CUST1.$DATA3.MYAPP.MYFILE  

 

* Partially qualified names are assumed to be located on the current default location of any part that is not explicitly qualified.

The Guardian Diskfile Security String

DISKFILES have an owner, that is, the userid of the user who created or is assigned ownership of the diskfile.

Each diskfile has a security vector. By default, the security vector is the owner's default security as defined in the owner's User Record.

Note

A file owner or the owner's group manager or SUPER.SUPER can give his or her files to another user, using the FUP GIVE command, and can also change the file's security vector using the FUP SECURE command.

The security vectors control the following:

READ	Determines who can read or copy any kind of file or who can execute a macro or OBEY an obey file.
WRITE	Determines who can modify the contents of a file.
EXECUTE	Determines who can execute a code 100 or 700 (object) file with the TACL RUN command.
PURGE	Determines who can delete, rename or FUP ALTER a file.

The operations are always displayed in this order: READ, WRITE, EXECUTE, PURGE sometimes abbreviated as RWEP.

There are seven possible values for each vector. These values reflect who is allowed to perform the operation and whether or not the operation can be performed by someone on a remote node. The value is always a single character. The values are:

WHO CAN PERFORM THE OPERATION	LOCAL	REMOTE
File Owner	O (owner)	U (user)
File Owner's Group	G (group)	C (community)
Everyone	A (all local users)	N (all network users)
Local SUPER.SUPER only	- (hyphen)

A ”All local users can access the file.

N ”All network users can access the file.

G ”Only local members of the owner's group can access the file.

C ”Only network members of the owner's group can access the file.

O ”Only the local file owner or group manager can access the file.

U ”Only the remote and local file owner or group manager can access the U ”file.

- ”Only the local SUPER.SUPER.

Example:

  $SYSTEM.SYS00   CODE      EOF  LAST MODIFIED  OWNER  RWEP PExt SExt   LOGON    100    435254 17APR2001 7:53 255,255 UUNU  74  16   DEFAULT  100    559588 17APR2001 7:53 255,255 UUNU 188  32  

 

This example shows two of Safeguard software's object files. They are both owned by SUPER.SUPER. The security strings are the same:

  RWEP   UUNU  

Only SUPER.SUPER can READ, WRITE or PURGE these files. Everyone, whether logged onto a remote node or the local node, can EXECUTE the file.

Processes

All running processes have an owner. In most cases the owner is the userid of the user who executed the object file. This is true unless the object file is PROGID'd. For a PROGID'd process, the owner of the process is the owner of the object file. See the section on PROGID in the Gazette portion of this book.

On the HP NonStop server, most objects, including processes, are considered to be files. The file name for a process is known as a process file name. The process file name can be used to communicate with the process. Process file names must begin with a dollar sign ( $ ). Subprocess names must begin with a hash or pound sign ( # ) and be preceded by the parent process name.

Running processes are also identified numerically on a list known as the Process Control Table, which is allocated in the system data space and protected.

Caution

The process' PIN (Process Identification Number) is its number within a CPU. The process' PID (Process ID) is a combination of the CPU number and the PIN, separated by a comma.

Syntax:

 <cpu #>,<process #> 

 

Examples:

 03,211 12,377 

 

The example shows process number 211 running in CPU 03. This is a LOW PIN process. The second example shows process number 377 running in CPU 12, which is a HIGH PIN process (>255).

Process Security

Each Guardian process is assigned a creator access ID (sometimes known as the CAID), a process access ID (or PAID), and a stop mode. The following paragraphs describe how the creator access ID, process access ID, and stop mode work together to provide process security.

The CAID is the userid from the process or TACL that started this process.

The security of processes is not configurable in the Guardian system. Only the following users are able to stop, suspend, activate or alter the priority of a process:

The owner

The owner's Group manager

SUPER.SUPER

For more detailed information, refer to the section on Guardian Process Security in Part Five.

Devices

In the Guardian environment, any process can open any device for input or output. All devices are addressed in the same way that a diskfile is addressed, by name.

The process' PIN (Process Identification Number) is its number within a CPU. The process' PID (Process ID) is a combination of the CPU number and the PIN, separated by a comma.

Standard NonStop Device Naming Convention:

\SYSTEM.$DEVICE.#SUBDEV

Example:

  \CUST1.$TAPE  

 

For more detailed information, refer to Guardian Object Security in Part Five.

Authentication

Basic Guardian authenticates a user by prompting a user for a userid and the password for that userid when logging on to the TACL command interpreter. The password can be up to 8 characters long, has no restrictions on value and is stored using a one-way encryption algorithm in the system's USERID file.

In the Guardian personality, a user attempting access to a file or process on a remote node must pass at least three levels of security.

The first level authenticates the user as they log onto the local node. The target userid or alias must exist on the node, it must not be frozen or expired . (If Safeguard software is present, it performs this authentication. If Safeguard software is not present, the Guardian environment performs the authentication.)

The second level authenticates the userid on the remote node. The user name and user number must both be the same on both the originating node and the target node. (If Safeguard software is present, it performs this authentication. If Safeguard software is not present, the Guardian environment performs the authentication.)

The third level validates the REMOTEPASSWORDs on each node. The Guardian environment performs the validation.

In the Safeguard personality, an additional level of security is evaluated.

If all three security checks are passed, in the fourth level of security, the file or process access request is passed to the Safeguard Monitor process on the target node which then grants or denies the access based on the Safeguard Protection Record securing the file or process. If there is no Safeguard Protection Record, then the Guardian security vector determines whether or not the remote user is granted access to the file. The access request is only sent to the Monitor at the destination node NOT the originating or any intermediary nodes.

Authorization

Authorization is based on the Guardian diskfile security string. The combination of user, object and access requested is granted or denied based solely on the Guardian security string, without regard to context or history. Part Five of this handbook includes topics on authorizing access to all types of NonStop objects.

Auditing and Controls

Basic Guardian operating system security has no intrinsic auditing available. There is an exit available for the implementation of custom software that can monitor user logons and logoffs, process run commands and process priority alteration. This exit communicates with a process named $CMON. HP does not supply $CMON. There is a limited, unsupported implementation available free with a membership in ITUG, international user group for the HP NonStop server. This version can be modified in-house.

3P-CMON-PROCESS-01 Several third party software suppliers offer supported and enhanced versions of a program to run as $CMON.

Controls for the Guardian personality are limited solely to the userid, security vector, PROGID and LICENSE for each diskfile.

RISK No controls are available to limit the activities of any group manager or SUPER.SUPER users.

RISK No auditing is available on what actions have been taken by these users.

Audits and controls are discussed throughout this handbook in Parts 3, 4, and 5 where they apply.

Sanitizing an HP NonStop System

This section is concerned with preparing the HP NonStop server for use. Many aspects of security will be covered in much greater detail in later sections on specific objects or programs.

By sanitize , we mean putting adequate security measures into place to keep the system secure as it evolves. Security policies and procedures should be followed from the moment the HP software is installed and while applications are being developed, tested , and put into production.

It must be assumed that any newly delivered system is not secure. General access should not be allowed until the security administrator and the system manager have put security measures into place.

User Management

The user community should be set up so that users who need to share certain files are in the same administrative groups.

No individuals should have a userid in the SUPER group. SUPER group privileges should be granted sparingly, limited to a small set of trusted users who must perform the privileged tasks associated with the SUPER group.

Delete the NULL.NULL userid.

Delete all SUPER group members. Delete the SUPER.SUPER and re-add the 255,255 userid under a different name, such as SYS.SYS. Then re-add SYS group ids. This reduces the risk of users knowing the SUPER.SUPER name combination and guessing the password. This can most easily be done when the system is being sanitized.

Secure the Operating System Software

Securing the operating system involves the protection of the software provided by its manufacturer, including the operating system, utilities, compilers, libraries and other such programs.

The Corporate Security Policy and Standards should specify how the HP software is to be secured. HP makes the following general recommendations:

HP Recommended Security of System Files

Security	Description
?OOO	General libraries (including runtime libraries, sourced files, error message files)
OO?O	User tools (including editors and compilers)
OO?O	System tools (including FUP, NETMON, DSAP, TACL, BACKUP,RESTORE,PATHWAY, TMFCOM, TRANSFER, MAIL)
?OOO	Microcode (macro) files
- - - -	Special files (including TANDUMP, DIVER, USERID, and USERIDAK)
Owner	Description
255,255	SUPER.SUPER should own all the operating system files

Reserve the System Disk for HP Operating System Files

No unauthorized and undocumented files, especially object files, should reside in $SYSTEM.SYSTEM or $SYSTEM.SYSnn subvolumes. Files that reside in 'system' subvolumes are generally included in the program search list. Programs that reside in subvolumes within the search list do not need to be fully qualified in order to be invoked.

Any non-HP programs that must reside on $SYSTEM should not be located in $SYSTEM.SYSnn. This is the subvolume containing the operating system that will be replaced upon upgrades.