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.
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.
Compilers resolve system libraries during the compilation phase of generating executables using the BINSERV utility.
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).
SRL libraries are special user libraries that contain global system variables . There are two types of SRLs:
Public SRL
Private SRL
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.
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.
NLD resolves references to the SRLs that are specified when building an executable program.
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.
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.
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.
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