James H. H. Lampert wrote:
<<SNIP>>
At any rate, I would argue that the ability to disable a trigger
without removing it, precisely because it DOESN'T show up in a
PRTTRGPGM report, makes CHGPFTRG more dangerous than ADDPFTRG or
RMVPFTRG. So much so that I would say that it's the first example
I've ever encountered of an OS revision from IBM that CREATED a
security hole, rather than REMOVING one.
PRTTRGPGM is a feature of the /security component/ for which
their reporting intent might purposely not include [maybe not of
interest] in the status of the trigger; i.e. perhaps only the
existence of its definition might be relevant to the intent of the
report.? The help text does suggest that the command only "lists
the programs which have been /defined as a trigger program/ for the
physical files in the specified library." No mention of
active\enabled nor operable\operative. If the output from the
security report is in error, not useful [for lack of the trigger
status], or for another concern the report is considered
problematic, then that concern would best be reported to IBM.
I think in this case the PRTTRGPGM is simply the wrong tool for
the job if status is not shown, but is required; full or changed
report. I would suggest to use either a database interface such as
query of SYSTRIGGERS catalog or the /where used/ interface [DSPFD]
to review the trigger status, for details beyond just the
definitional aspect of a trigger program being /associated with/ a file.
There is nothing about the existence of CHGPFTRG, by itself, that
defeats the security of the database [file\data]. Either RNMM or
OVRDBF command could enable some trickery with regard to the outcome
of both direct & triggered I/O, just as could the [mis]use of
CHGPFTRG. However the existence of any of those other commands also
does not /create/ a security hole.
Think about it: you have a trigger program that, instead of just
propagating data, enforces some business rule. Maybe even one
required for compliance with the law. Somebody with a priv'd
account and malicious intentions goes in and quietly disables the
trigger. Suddenly, changes that would ordinarily be vetoed can
sail right through, and yet the only way anybody would notice
that the trigger isn't getting invoked would be if they either
(1) did a WRKOBJLCK on the trigger program, or (2) did a DSPFD on
the file, things they wouldn't do unless they suspected that the
trigger was being bypassed, strongly enough to disbelieve what
the PRTTRGPGM report says.
Think about it, the same issue exists for use of RMVPFTRG & then
ADDPFTRG, by\or just replacing the existing trigger program, by the
same privileged account, as accessed by the malicious person. The
auditing and the file journal both log the /change trigger/ event,
as well as logging both remove and add of a trigger. There is no
assurance that any malicious actions would be generally preventable
by a privileged user; there is only the ability to track the
activity [in part, depending on how thorough the super-user was able
to cover their tracks]. So if there is fear of misuse of CHGPFTRG,
then there is a much bigger problem for both the other way(s) to
effectively defeat a trigger and more importantly that the problem
is actually for having entrusted nefarious person(s) with too much
access.
IIRC CHGPFTRG came in v5r1 along with named triggers [required to
enable its use], SQL triggers, and huge increase in the number of
allowed triggers. I believe ADDPFTRG was originally limited to six
triggers per file, one for each event [i\u\d] and time
[before\after], prior to v5r1.
If the CHGPFTRG did not exist, then complaints would have led to
the eventual implementation anyhow, for lack of ability to easily
/temporarily/ bypass trigger program(s) on a file without having to
remove and\or re-add some or all of the trigger(s) [in the proper
order]. Typically the trigger bypass would be for batch\mass load
or updates of data, from trusted or already validated data [perhaps
by the same trigger on another file; merging its data]. If there is
a file altered from CHAR(10) to CHAR(12) for an account number, and
the account naming changes the first two bytes of the newer\longer
field to be prefixed by '00', performing the trigger for each row
updated by the statement SET ACCOUNTNO=CONCAT('00',ACCOUNTNO) is
probably not very desirable; i.e. such that bypassing the trigger
program is best effected by CHGPFTRG STATE(*DISABLED) before issuing
that UPDATE statement affecting every row in the altered table.
Regards, Chuck
midrange.com
