Binder Subsystem

Binding (the TNS term) or linking (the native term ) is the operation of examining, collecting, and modifying code and data blocks from one or more object files to produce a single object file. Two important aspects of binding or linking a program are validating and resolving references to other routines.

Validating a reference to another routine means determining whether or not the actual parameters of the calling routine correspond to the formal parameters of the called routine.

Resolving a reference to another routine means generating the code that will transfer control from the calling routine to the called routine at execution time.

All Binder operations are performed on program files. Binder uses the following terms when discussing object files:

Block The smallest unit of code or data that can be relocated as a single entity.

Source File Code and data blocks, compiled and bound together.

Program An executable object file. It must contain an entry point with the MAIN attribute.

Target File BINDER output file, always an object file.

The components of BINDER are:

BINSERV

BIND

VPROC

BINSERV

The BINSERV form of BINDER is only used by language compilers; it cannot be executed by users directly. It executes as a separate process during a compilation, accepts commands from the compiler, builds lists of references that need to be resolved, and finally creates the target file.

BINSERV (See Figure 6-2) builds executable program files for C, COBOL85, FORTRAN, and TAL. (The Pascal compiler uses BINSERV but does not produce an executable program file.)

Figure 6.2: BINSERV

BIND

BIND is the interactive version of the BINDER. It can be used as an independent, standalone program to query, update and link program files interactively.

BIND can be used to update and link program files written in C, COBOL85, FORTRAN, Pascal, and TAL. BIND is the only form of Binder that produces executable program files for Pascal programs (See Figure 6-3).

Figure 6.3: BIND

BIND is used to:

Build a single object file from separate object modules.

Build a target file of procedures in a shareable library.

Modify the values of code and data blocks in the target file.

Reorder code blocks in a target file.

Specify a user run-time library.

Display program file contents.

Specify external references not to be resolved by Binder.

Produce load maps and cross-reference listings.

Strip the program file of the BINDER and INSPECT regions .

RISK BIND can be destructive because it can make the following changes to program code files. Programs could be directed to libraries containing malicious procedures and variables and data could be modified.

Build a single object file from separate source files.

Build a target file of procedures in a shareable library.

Modify the values in the code and data blocks of the target file.

Reorder code blocks in a target file.

Specify a user run-time library.

The security requirements for BIND and BINSERV differ greatly between a system used for development and a secure environment. The risks for a secure system require stronger security of the BIND command and the compilation function, in general.

VPROC

The VPROC (Version Procedure) program will display the version number for program files developed by HP or third-party vendors and a timestamp that is either the time when the object file was compiled or the time when the object was processed by the BIND program.

VPROC is the generally accepted way to easily determine the version information for an object program.

Securing BINDER Components

BP-FILE-BINDER-01 BIND should be secured "UUNU".

BP-OPSYS-OWNER-02 BIND should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-02 BIND must reside in $SYSTEM.SYSTEM.

BP-FILE-BINDER-02 BINSERV should be secured "UUNU".

BP-OPSYS-OWNER-02 BINSERV should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-02 BINSERV must reside in $SYSTEM.SYSTEM.

BP-FILE-BINDER-03 VPROC should be secured "UUNU".

BP-OPSYS-OWNER-02 VPROC should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-02 VPROC must reside in $SYSTEM.SYSTEM.

If available, use Safeguard software or a third party object security product to grant access to BINDER components only to users who require access in order to perform their jobs.

BP-SAFE-BINDER-01 Add a Safeguard Protection Record to grant appropriate access to the BIND object file.

BIND Commands With Security Implications

This section lists only the BIND commands that pose security risks.

RISK BIND poses a security risk in a secure environment only if the users authorized to execute BIND have WRITE access to application object files. All of the commands in the list manipulate the creation or contents of a program.

ADD

ALTER

BUILD

CHANGE

DELETE

STRIP

3P-OBJSEC-BINDER-01 If a third party product is used to grant access to BIND running as a privileged userid such as the application object code owner, these commands should be denied to all users other than the system managers.

Application Controls

Only members of the group (if any) responsible for compiling programs on the secure system should have WRITE access to secure object files.

AP-ADVICE-BINDER-01 On secure systems, BIND should be restricted to use by Application Support staff and those responsible for managing object files.

AP-ADVICE-BINDER-02 In secure environments BIND should be used only to research and report on object parameters, not alter them.

BINDER respects file security. If users run BIND under their own userid, they can only BIND object files that they have been granted access to via the Guardian or Safeguard system.

AP-ADVICE-BINDER-03 Users should run BIND under their own userid.

AP-ADVICE-BINDER-04 The application support staff should not have WRITE access to secure object code.

AP-ADVICE-BINDER-05 To safeguard the secure databases, the group (if any) responsible for compiling programs on secure systems should not have READ access to secure database files.

	Discovery Questions	Look here:
OPSYS-OWNER-02	Who owns the BIND object file?	Fileinfo
OPSYS-OWNER-02	Who owns the BINSERV object file?	Fileinfo
OPSYS-OWNER-02	Who owns the VPROC object file?	Fileinfo
OPSYS-OWNER-02	Who is allowed to execute VPROC on the system?	Fileinfo
FILE-POLICY	Who is allowed to execute BIND on the system?	Policy
FILE-BINDER-01 SAFE-BINDER-01	Is the BIND object file correctly secured with the Guardian or Safeguard system?	Fileinfo Safecom
FILE-BINDER-02	Is the BINSERV object file secured correctly?	Fileinfo
FILE-BINDER-03	Is the VPROC object file secured correctly?	Fileinfo

Related Topics

Compilers

Securing Applications

PASSWORD

TACL