On Mon, 2002-09-09 at 10:55, Phil Payne wrote:
> > I suspect if you put the same number of people at z/OS as anything else
> > they would find lots of holes in it.
>
> I suspect you wouldn't.
Phil, when I first read Alan's assertion my knee-jerk was the same as
yours. Impugn my baby, will he? I thought about responding as you did,
and then slept on it.
Those of us in the 'biz' know about IBM's published security policies,
and their unconditional APAR acceptance and all that. Some of us also
remember a time when MVS nee OS/360 was trivially easy to break, and can
attest to the fact that IBM has done much to shore up the big nasty
holes. MVS goes to great trouble nowadays to ensure integrity and
recoverability. There sure is a lot of FRR code in MVS that wasn't
there in the beginning, a LOT more.
This is both good news and old news. But the more I thought about
Alan's comment, the more I realized that I couldn't refute it:
> > z/OS is secure because nobody cares about it.
I see this is partly true, if a little overstated. More to the point,
there are few opportunities for attackers to experiment with a live z/OS
system. In most places if you are caught running through the SVC list
while stress-testing parameter lists, you'll get life in the electric
chair. The stakes are high, and the systems are (not always, but more
likely to be) closely watched. As a logistics problem, it is harder to
hack a z/OS system surreptitiously than it is to step-debug a kernel
exploit at home. One little screwup and you take down a
mission-critical system that hasn't been IPLed for months or years; it
gets people's attention.
> z/OS is secure because it has been IBM's officially stated policy ever
> since OS/VS2 Version 2 first shipped that all APARs describing
> integrity exposures would be unconditionally accepted
And so who reports these problems? There are *far* fewer investigators
than there are for the ubiquitous desktop systems. Yet my gut feeling
is that there are plenty of opportunities left for the inquisitive
ne'er-do-well.
It hasn't been all that long since I caused my last SVC dump. Enough of
these and you have an irritating local DOS attack. Did your
installation code IEALIMIT or sysout-excession exits? If not, it's
trivially easy to fill up the SPOOL or deplete the local page datasets.
It's easy to eat up all the JES2 JQEs (i.e. use up all the job slots)
too, and no way to prevent it easily comes to mind.
If you're on the inside, privileged or not, you can wreak havoc.
Can you get into 'authorized' state? Maybe, or maybe not. But besides
the over-400 SYS1.LINKLIB modules that are marked authorized, you
probably have lots of non-IBM code that is also marked that way;
Computer Associates requires it for much of their stuff (and I
understand even installs a backdoor SVC). Is it secure? Beats me.
Leonard Woren's free-as-in-beer TAPEMAP program, which source is *not*
published, requires that it be marked 'authorized'. Your own MPF, SMF
and JES exits run in authorized state. Lots of useful CBT utilities run
authorized. Have you audited any of this? How much of this stuff do
you trust?
You only have to flip one bit, and MVS gives you the keys to the city.
In MVS, you're either authorized or not, pregnant or not.
Unfortunately, way too much useful stuff needs only a little privilege,
but all you can do is grant the Works. So you have a mess that is
equivalent to the Unix "suid" problem.
I read something the other day that said, paraphrased:
"Every security outfit issues regular press releases
that say 'trusted' this, 'trusted' that. Well let
me tell you something: trust is bad. Our systems are
insecure BECAUSE we trust."
I think it would be wise to *not* trust IBM, not because they are evil
or incompetent, but because it is impossible to verify their work. And
though we know a skosh more about MVS than Alan Cox, I'm not inclined to
discount his advice out of hand.
--
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]
