Security Management Guide (G06.24+, H06.03+)

Guardian System Security
Security Management Guide—522283-008
2-28
Possible Security Concerns
Improper Handling of Requests
Without sufficient checking of the input data range and form, an incompletely
debugged PROGID program can unintentionally provide unauthorized access to
restricted data.
For example, a PROGID program might display the home address from an employee’s
payroll record. The employee numbers range from 1 through 100, the database
contains home address information in records 1 through 100, and the corresponding
salary information resides in records 101 through 200. If the program does not properly
validate a requested employee number, it might unintentionally display the salary of
employee 50 when asked for the address of employee 150. The program could avoid
divulging this sensitive information by checking requests for information to verify that
an employee number is in the range 1 through 100.
Created Processes
The privileges of a PROGID program propagate to any processes created by the
program. This situation can create a serious security risk.
For example, some programs, such as TEDIT and TACL, provide a user interface that
allows the user to arbitrarily execute other programs. If a PROGID program starts
TEDIT, the invoker of the PROGID program can use the TEDIT RUN command to
perform any operation allowed to the PROGID program owner.
System Programs
As a general rule, system files should remain as distributed and not enabled as
PROGID programs. A system utility enabled as a PROGID program can provide
excessive and easily subverted capabilities.
Loss of Accountability
If a process with the PROGID attribute starts another process, accesses made by the
descendent process are logged to the owner of the PROGID program. The ID of the
person who started the original PROGID program is lost.
Entering DEBUG or INSPECT
PROGID programs do not allow a user other than the program owner to run the
program in debug mode from TACL. However, after a PROGID program is running,
and if the program enters DEBUG (or INSPECT), the person running the program
assumes the privileges of the program owner. By patching the program data, it might
be possible to defeat whatever security is built into the program. Therefore, PROGID
programs should be constructed to never enter DEBUG.