Guardian Process Security

A process is defined as "a particular program running within a defined environment that includes an independent set of registers, code-addressing space, and data-addressing space." By default, processes are managed by the Guardian environment. They are created via Guardian procedure calls (See Figure 5-1).

Figure 5.1: Executing Process Structure

A process is created when a user executes a disk file containing object code. The user must have EXECUTE authority for the object file in order to create the process.

To fully protect processes, access to both the object files and the running processes must be protected.

Protecting the object files will be discussed in the chapters on File Security. This chapter concentrates on protecting running processes.

Programs

A program is a sequence of instructions and data that become a process when executed.

A program file is an executable object file. It contains primarily executable code, but may also contain other components such as initial or read-only data and linkage information. Unlike other object files, a program file has a main procedure.

Object files can be produced in two ways:

By compilers that translate the source program, written in a language such as TAL or C, into object code.

By linkers, such as the BINDER and NLD utilities, which link object files together.

Process Identifiers

Each process has multiple attributes:

Creator Accessor ID (CAID)

Process Accessor ID (PAID)

Process Name (optional)

Process Identification Number (PIN)

Process Identifier (PID)

When a process is created, it adopts the creator's userid as its CAID and the PAID of its creator as its PAID. This ensures that processes operate using the creating process's privileges and are able to access only those resources to which that process has been granted access.

RISK Note that a process' PAID can be altered with USER_AUTHENTICATE_ procedure calls or by executing a PROGID'd object file. Please refer to the Gazette section on PROGID.

BP-POLICY-PROCESS-01 Processes should not run PROGID'd unless authorized by appropriate management and documented by the Security Administration Group .

Process Names

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 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.

Example:

  $S.#LP  

 

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. The numeric value for a process is known as the Process Identification Number (PIN), which is the index to the process in a CPU. The combination of a CPU number and PIN is a Process Identification (PID).

Syntax:

  <cpu #>,<process #>  

 

Examples:

  03,211   12,377  

 

The first example shows process number 211 running in CPU 03. The second example shows process number 377 running in CPU 12.

Process Identification Number (PIN)

The PIN can be High or Low:

A Low PIN ranges from 0 through 254.

A High PIN ranges from 256 through the maximum number supported for the CPU.

C-series systems only utilize Low PINs (represented in an 8-bit field).

D-series systems utilize both High and Low

Caution

PIN 255 is a special case low PIN used by high-PIN processes to communicate with an unconverted C-series process. The range of usable low PINs is therefore 0 through 254.

Process Properties

The following properties can be specified for a new process:

Named or unnamed

Waited or nowaited

High PIN or low PIN

Home terminal

Library file to be included in the process, if any

CPU where the process is to run

Priority

Only the following properties are of concern to security administrators:

Unnamed Processes

Priority

Defines

Unnamed Processes

Processes can be named or unnamed.

A NAMED process is one which had a name assigned when it was created.

An UNNAMED process had no name assigned when it was created.

Names can be created by the user or assigned by the operating system.

By default programs like EDIT and FUP run as UNNAMED processes.

RISK Safeguard software can only have one Protection Record for UNNAMED processes, so the same Safeguard security will be applied to all UNNAMED processes.

AP-ADVICE-UNNAMED-01 Avoid UNNAMED processes.

BP-POLICY-PROCESS-02 Application programs should not run UNNAMED.

PRIORITY

Processing order is determined by the priority of processes in a READY state.

Application process priorities range from 0 to 199. System priorities range from 200 to 255, so any system processes that are READY will always execute before any application processes.

Processes of the same priority are executed in the order they become ready on the Ready List of the CPU.

New processes with high priorities execute before any processes of lesser priority that were already in the queue.

RISK All processes on a processor, including system processes and application processes, share the same priority structure, so it is very important that each process runs at an appropriate priority, one which permits necessary system operations when needed.

When Priorities Are Set

When priorities are set depends on the type of process:

System process priorities are set during system generation.

I/O processes (but not disk processes) can have their priorities dynamically changed using the Dynamic System Configuration (DSC) utility on D-series systems or SCF on G-series systems.

User and Application process priorities are set during process creation. Processor- bound processes may have their priority reduced automatically to allow other processes to gain access to the processor. This is necessary to lessen the risk of a process taking over a CPU and pre-empting all other activity.

3P-CMON-PROCESS-01 CMON can be configured to manage which CPU and priority new processes will use.

3P-PROCESS-ADVICE-01 Third party process control software can be used to manage which CPU and priority the processes will use.

STATE

During its life, a process will pass back and forth between several process states (See Figure 5-2).

Starting	A temporary state occurring as the process starts up.
Ready	The process is either executing, ready to execute, or waiting for service from the memory manager (because of a page fault).
Suspended	The process has been suspended as a result of the a PROCESS_SUSPEND_call and will remain in this state until the PROCESS_ACTIVATE_ call makes the process runnable again.
Activating	A temporary state occurring as the result of PROCESS_ACTIVATE_ call that makes the process runnable again. Available only for suspended processes.
DEBUG and INSPECT	Either the DEBUG program or the INSPECT debugger has the process open . This state has several substates : Memory Access Breakpoint (MAB) breakpoint (BKPT) trap (TRAP) request (REQ)
Saveabend	The process is waiting for the INSPECT program to create a SAVEABEND file.
Stopping	A temporary state occurring while the process is being deleted.

Figure 5.2: Process States

Only processes that are in the READY state are capable of using the processor and only one process, the ACTIVE process, can use the processor at a time. The ACTIVE process will always be the one with the highest priority that is ready and not waiting for some external event such as a disk IO.

The ACTIVE process will go into a temporary WAIT substate when, during execution, it has to wait for an external event. Processes in the WAIT substate move back to the READY substate when their wait conditions are satisfied.

An ACTIVE process can be preempted by a higher priority process. When this happens, it goes to the READY substate. The highest priority READY process goes into the

ACTIVE state immediately if its priority is higher than the current ACTIVE process, otherwise , it becomes ACTIVE when the current ACTIVE process goes into its WAIT substate.

Process Structure

When a process is created, it occupies space in virtual memory.

Each application or system process has physical CPU memory space allocated for object code, libraries, and data. The space where system code exists is separate from the space where application code exists. So, the operating system environment can be thought of as being divided into six sections:

System Code Space

System Data Space

System Library Space

Application Code Space

Application Data Space

Application Library Space

Code Space

The CODE SPACE contains program instructions and constants from the object file. Only READ access is permitted to the object code in the code space of a running process. This prevents modification of code during execution.

To maximize disk space efficiency, multiple copies of a process, even when running in different CPUs, can share the same object code on the disk.

To maximize memory efficiency, if multiple copies of a process are running in the same CPU, the processes all share one code space in memory.

Data Space

DATA SPACE is used by a process to store and manipulate data. Each running process maintains its own private data space, modifying the data as required during execution.

Library Space

LIBRARY SPACE is used by a process to store any routines loaded from libraries.

Securing Processes

The HP NonStop server provides many tools for managing processes on the system, both at the Command-Interpreter level and the procedure-call level. To prevent users from using these tools to interfere with another user's process (for example, to delete someone else's process) or access privileged data, the operating system provides tools for protecting processes from each other and for protecting data from indiscriminate access.

Each Guardian process is assigned a creator access ID (CAID), a process access ID (PAID), and a STOP MODE.

Three levels of process security exist:

Object file security

Process ownership controls

STOP MODE controls

The PAID is used to determine whether restricted actions against a process (such as stopping the process or invoking the debugger) are possible. Normally, the users who can stop a process are:

The process owner

The process owner's Group Manager

SUPER.SUPER

However, the STOP MODE can be set within a program to enforce various levels of security against stopping the process.

STOP MODE can restrict the ability to stop a process to one of the following:

Any process on the system can stop the configured process

A process with a PAID equal to that of SUPER.SUPER, the group manager of the target process, or the target process itself can stop the configured process

Only the configured process can stop itself

Safeguard software can override the first two STOP MODES when Protection Records are in place.

RISK If a user creates a process configured so that only that process can stop itself, Safeguard software cannot override it. Even SUPER.SUPER cannot stop such processes.

With CMON

CMON can perform load-balancing tasks . If configured, CMON can control:

The CPU a process will start in

The initital process priority

ALTPRI requests

AP-ADVICE-CMON-01 CMON can be configured to manage which CPU and priority new processes will use. See the chapter on CMON for more information.

Without the Safeguard Subsystem

Actions that a process (or user) can attempt on another process:

ABEND

ACTIVATE

ALTPRI

DEBUG

OPEN

STOP

SUSPEND

How the Guardian System Evaluates Process Access Attempts

When a process is created, the PAID of the creating process becomes the CAID of the new process.

The PAID of any process attempting to affect another running process is compared with the CAID of the target process. If they do not match, the attempt will be denied .

The only exceptions to this rule are:

RISK Processes owned by Group Manager IDs can manipulate any processes owned by members of their own groups.

BP-USER-PRIVLEGE-03 No users should be assigned a Group Manager ID as a personal userid.

RISK Processes owned by SUPER.SUPER can manipulate any other processes.

BP-USER-PRIVLEGE-05 No user should be assigned SUPER.SUPER as a personal userid.

3P-PROCESS-PRIVLEGE-01 Third party process control software should be used to grant granular management of processes running as any Privileged ID for users who require these privileges in order to perform their jobs. These products generally also provide comprehensive auditing of the activities they secure.