Libraries, SRLs and Common Routines

Libraries are sets of common utility routines that are called by other programs. A library is a set of procedures that the operating system can link to a program file at run time or a set of TACL commands that are loaded via the TACL LOAD command. Libraries are used for the following reasons:

To reduce the storage space required for object code on disk and in main memory

To share a set of common procedures among applications

To extend a single application's code space

TACL command libraries are referenced in TACLLOCL, TACLCSTM and OBEY files. Utility libraries may be referred to in compile macros or OBEY files used to run BIND, NLD or as part of the run command.

RISK There is a chance that a library of non-authorized routines could be substituted for an existing library of the same name . Unauthorized libraries could also be attached to executable objects. In either case however, an individual must have WRITE access to the library or executable object in question to make the changes.

System Libraries

Each language has system libraries available for standard routines distributed with the language product from HP. These libraries are located in the same subvolume as the language compiler, usually $SYSTEM.SYSTEM. System libraries are included into a user program in whole or part during the BIND phase of the compilation.

AP-ADVICE-SYSLIBR-01 The Security staff should be aware of the languages that are used in the application programs. Each language has system libraries available for standard routines. These libraries are located in the same subvolume as the language compiler. Any system library should be secured for READ access only.

Resolving System Libraries with BINDSERV

Compilers resolve system libraries during the compilation phase of generating executables using the BINSERV utility.

User Libraries

Libraries are attached to objects via the BIND program or via NLD or using a RUN command.

RISK Changes in the library routines could be used to breach sensitive data or allow unauthorized changes to the program. Run-time binding does not include copying the procedure into the program file; it is a linking function only. Allowing run-time libraries to be linked reduces the ability to monitor potential code changes in the program.

The first time a program is executed after being compiled, the system searches the optional user library to resolve each unresolved external reference, and then it searches the system code and system library. A program file can have one (and only one) user

library associated with it. The Guardian environment resolves any external reference by changing the call in the program file to point to either the user library or the system library, as appropriate. Once the external references are resolved in this manner, the program can be run repeatedly without satisfying the references again.

If the operating system cannot find a user or system library procedure to satisfy a run-time external reference, it displays a message as the process starts. When the process makes a call to an unresolved procedure, the process changes the reference into a call to the Debug routine, and the process enters the debug state.

RISK Processes entering the debug state become vulnerable to run-time modification or stoppage. In either case, the processing is affected.

AP-ADVICE-USERLIBR-01 The Security staff should be aware of any user libraries present on the system. Any user libraries should be secured so that they can only be read, altered or purged by the appropriate users. Only the users responsible for maintaining the libraries should have WRITE and PURGE access.

AP-ADVICE-USERLIBR-02 Each library should be secured so that they are accessible only to the appropriate application(s).

Shared Run-Time Libraries (SRLs)

SRL libraries are special user libraries that contain global system variables . There are two types of SRLs:

Public SRL

Private SRL

Public SRLs

Only HP can supply public SRLs. Users cannot create their own public SRLs. NLD resolves references to the Shared Run-time Libraries that are specified when building an executable program in native languages. Public SRLs are located in the $SYSTEM.SYSnn subvolume.

Private SRLs

Programmers and system managers can create private SRLs. An SRL contains code present in virtual memory at run time, to be shared by processes, rather than linked into object files.

	System Library	Public SRLs	Private SRLs
Who can create?	HP	HP	Users
How many libraries per process?	One	Multiple	Multiple
Can contain global data?	No	Yes	Yes
Does each process get its own copy of the SRL?	No	Yes	Yes

AP-ADVICE-SRLLIBR-01 The Security staff should be aware of any SRLs used on the system.

Resolving SRLs with NLD

NLD resolves references to the SRLs that are specified when building an executable program.

Loading SRLs with LTILT

Run LTILT to determine whether there are any Shared Run-time Libraries (SRLs) in use. If there are SRLs, LTILT displays informational output, as shown below:

TILT Public SRLs were found in CPU 00 \LONDON.$SYSTEM.SYS01:

#	SRL Name Filename	Flags
01	ZATMSRL	ZATMSRL Licensed, CallableProcs
02	ZCMASRL	ZCMASRL HighPin
03	ZCOBSRL	ZCOBSRL HighPin
04	ZCPLGSRL	ZCPLGSRL HighPin
05	ZOSSCSRL	ZOSSCSRL HighPin
06	ZTDM_T9228_FSLIBZOSSF	SRL HighPin
07	ZTDM_T9627_OSSLIBZOSSESRL	HighPin

RISK LTILT is strictly a reporting tool and, therefore, poses no security risks.

Verifying SRLs with VTILT

The VTILT process verifies the SRLs and determines if any require loading. If any SRLs need loading, they are displayed.

  $SYSTEM SYS01 106> vtilt   VTilt - Verify TILT Libraries - T7898G09 - (01NOV02) - System \LONDON   Copyright Tandem Computers Incorporated 1995, 1996   \LONDON.$SYSTEM.SYS01.ZTILT and its subvolume-associated TILT SRLs   should load.  

RISK VTILT poses no security risk.

Loading SRLs with ZTILT

The ZTILT process loads the SRLs in each processor at startup (cold load) from the active SYSnn subvolume.

A shared run-time library (SRL) is in many ways similar to the system library. An SRL contains code present in virtual memory at run time, to be shared by processes, rather than linked into object files. Unlike code in the system library, an SRL can also contain global data, and each process using the SRL automatically gets its own runtime copy of the data, called instance data.

RISK ZTILT is loaded and run automatically by the operating and has no user risk.

Securing Libraries Components

BP-FILE-LTILT-01 LTILT should be secured "UUNU".

BP-OPSYS-LICENSE-01 LTILT must be LICENSED.

BP-OPSYS-OWNER-01 LTILT should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 LTILT must reside in $SYSTEM.SYSnn.

BP-FILE-VTILT-01 VTILT should be secured "UUNU".

BP-OPSYS-OWNER-01 VTILT should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 VTILT must reside in $SYSTEM.SYSnn.

BP-FILE-ZTILT-02 ZTILT should be secured "UUNU".

BP-OPSYS-OWNER-01 ZTILT should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 ZTILT must reside in $SYSTEM.SYSnn.

BP-FILE-SRLS-01 $SYSTEM.Z*SRL should be secured "NUNU".

BP-OPSYS-OWNER-01 $SYSTEM.Z*SRL should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-01 $SYSTEM.Z*SRL must reside in $SYSTEM.SYSnn.

Some SRLs have to be licensed. Refer to the section on licensed files.

	Discovery Questions	Look here:
OPSYS-OWNER-01	Who owns the LTILT object file?	Fileinfo
OPSYS-OWNER-01	Who owns the VTILT object file?	Fileinfo
OPSYS-OWNER-01	Who owns the ZTILT object file?	Fileinfo
OPSYS-OWNER-01	Who owns the $SYSTEM.Z*SRL SRL files?	Fileinfo
OPSYS-LICENSE-01	Is the LTILT object file licensed?	Fileinfo
FILE-POLICY	Are private SRLs used on the system?	Policy
FILE-POLICY	Who is allowed to maintain private SRLs on the system?	Policy
FILE-LTILT-01	Is the LTILT object file secured correctly?	Fileinfo
FILE-VTILT-01	Is the VTILT object file secured correctly?	Fileinfo
FILE-ZTILT-01	Is the ZTILT object file secured correctly?	Fileinfo
FILE-SRLS-01	Are the $SYSTEM.Z*SRL SRL files secured correctly?	Fileinfo

Related Topics

Compilers

Securing applications

Operating system