Tom,
I agree with you - the devil is always in the details.
-----Original Message-----
date: Wed, 03 Dec 2008 15:59:44 -0800
from: Tom Liotta <qsrvbas@xxxxxxxxxxxx>
subject: Re: Exit Point Protection and Monitoring
Ketzes, Larry wrote:
Does anyone have a rough idea on the % of shops that write their own exit
point programs to monitor and protect their exit points as opposed to
buying
3rd party products?
Also, what would be the best argument to buy instead of writing your
own exit programs. How often does IBM release ptf's or other updates that
would necessitate testing home grown exit programs?
Larry:
I have no idea of percentages. Every AS/400 site I've ever worked
(before PowerTech) had at least some home-grown basic exit programs.
As for PTFs, they _can_ be a real irritant. During one series of DB2
group PTFs a few years ago, each subsequent DB2 group would
alternately break and then fix one specific type of problem. It was
driving us a little batty trying to keep up.
One type of problem that seems to creep in every once in a while is
that some simple IBM fix will have a null-terminator left in one of
the parameters sent to an exit program. Not a big deal to work
around, but irritating when you don't expect it.
New releases can be easier to accommodate than PTFs. We work with
early-release versions to try to stay up-to-date with new behavior
(which happens pretty much every release). But PTFs are much harder
to stay ahead of. Early-release isn't much of an option there. And
as many of us know, not all PTFs apply to all systems. If a PTF
doesn't install on SystemA, you don't know that it might cause a
break on SystemB.
Regardless, PTFs and releases aren't the truly serious problems. The
serious problems are in the details.
Some four or five years ago, I contacted one author of an open
source exit program to point out a logic issue. The logic didn't
quite handle a particular implication of one of the more or less
'documented' capabilities of exit programs and their interactions
with the servers. By not properly interpreting a value in a data
structure that came in as a parameter, the exit program effectively
opened the system up totally. It became possible to sign on remotely
even as QSECOFR while using an invalid password. The author quickly
and quietly made the appropriate changes.
Ouch! Opening your system to the world by installing a 'security'
control?
That's an example of the more serious side. It was handled as
quietly as possible and all seems well now. As far as I know, the
fairly simple method of exploiting the flaw wasn't made public, at
least not widely if at all; so whatever few sites that might have
been using the earlier program or related derivatives were no more
at risk than they already were. Anyone who uses the later version is
covered.
Exit programs for servers need to be deeply vetted, especially when
they are used for deciding to allow or to reject transactions. An
exit program that merely logs activity or reports it, is clearly safer.
But whenever the exit program has the power to "ALLOW", things get
serious.
Further, some of the most trivial things can potentially and
essentially shut a server down. Sites that _rely_ on network access
to host servers often can't afford to have ODBC go dead. The exit
programming better be as fail-safe as possible.
It's one thing to display interactive error messages or to write
messages to joblogs and terminate. But it's a little trickier doing
it without interfering with the next transaction in a re-used server
job or while still sending an appropriate "REJECT" or "ALLOW" response.
Also, performance can be a killer. Exit program initiation, file
opens/closes, object locks, message handling (wrapping job logs),...
plenty of things can interfere when a transaction is supposed to do
nothing but insert a single simple row in a table and let the client
continue in a split second.
For SQL (ODBC), determining a characteristic of a given statement to
be "read" rather than "update" can get tricky. What about a UDF or
stored proc? How does an exit program know? How much and what
parsing should it do? If PAYROLL is a restricted table, what about
an ALIAS? What if the statement starts with [WITH my_CTE AS...]?
What if a compound statement arrives? Parse a megabyte SQL string?
Quickly? Even though various things are going to slip past no matter
what?
There are techniques, of course; but individual sites generally
won't go that far. Vendors have less choice in the matter.
Overall, it can be fun stuff. Keeping up with releases and PTFs can
be the easy parts.
Tom Liotta
midrange.com
