Security Management Guide (G06.29+, H06.08+, J06.03+)

Guardian System Security
Security Management Guide — 522283-021
2 - 31
Detecting PROGID Programs
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 allow the following users to run the program in debug mode from
TACL:

SUPER.SUPER

Owner of the program file

Program file owner's group manager
When the program enters DEBUG (or INSPECT), the person running the program
assumes the privileges of the program owner
. By patching the program data, you can
overcome the security built into the program. Therefore, PROGID programs must be
constructed in a way that they never enter DEBUG.
Detecting PROGID Programs
To list the names of all PROGID programs residing on a disk volume, use the DSAP
command. For example, this command lists the PROGID programs residing on volume
$SYSTEM:
1> DSAP $SYSTEM,PROGID

Name/ID Filename Type Code ...

LIBRARY.USER
Note. This information is supported on all versions of Safeguard.