Re: [fw-wiz] Mainframes on the Net?

From: Paul Robertson (proberts@patriot.net)
Date: 11/13/02


From: Paul Robertson <proberts@patriot.net>
To: Don Kendrick <don@netspys.com>
Date: Wed Nov 13 12:04:01 2002

On Wed, 13 Nov 2002, Don Kendrick wrote:

> OK...maybe a little of topic but this is the group that would know :)
>
> There is quite a push from our IBM friends to use the S/390 box for a
> web server using Websphere or Apache running under Linux (either as a
> VM or in it's own LPAR).
>
> Needless to say, I considered this to be a joke....putting the crown
> jewels on the net? Where's the multi-tiered architecture? Where's the
> "defense in depth?" Sure the S/390 has "never been hacked" (their
> words) but who has ever put it in a position to be hacked?
>
> They tell me that I don't understand LPARs. They're separate machines.
> You can still do your multi-tiered. It's just all on the same box. My
> fear, they are separate because of software, written by humans. If that
> is breeched, it's game, set and match.
>
> If they were separate boxes, they would have to communicate via some
> interface that I can monitor. This isn't true all on one box.
>
> Anyone have any experience with this fight? Am I out of line?

Caveat: It's been a fair number of years since I was a mainframe systems
programmer, and even longer since I was a mainframe assembly language
developer. They don't even make the boxes blue anymore.

I do have around 10 years of mainframe experience (not exclusively
mainframes, but mainframes for all of that, from s/360s, to 43xx and 93xx
models. I've been a systems programmer and assembly/PL/1 developer on
VM/CMS, MVS/TSO/e and MVS/CICS from the base 360 up through XA and ESA.)

The virtualization scheme in VM is my favorite ever. It made one heck of
a development environment. LPARs are probably better evolved, but I
wasn't as comfortable developing in that environment (mostly people ran
MVS there, back when, and I much preferred VM.) While you *might*
be able to break out of the virtual environment, it sure won't be a
trivial task. I started out on IBM mainframes, and spent a fair ammount
of time on VM and MVS- I can't recall a single time I saw a virtual
machine or even an address space cause a supervisor or hosting OS issue
that executed code, even when the SVC code was our own. (SVCs are
Supervisor Calls, like syscalls.)

The only real major issue I've ever seen is that TSO/E's Virtual
Telecommunications Access Method (VTAM) had some order-of-execution issues
with OS terminal services macros (SVC 93 and SVC 94) where calling them
from a Terminal Monitor Program (which AIR wasn't a user-space installable
kind of thing anyway) would change order of execution despite execution
order in the TMP depending on some parameters and what got called first
(it was a fullscreen/linemode switching issue that I spent about two
months proving to IBM existed- because they wouldn't touch that code and
couldn't believe you could diagnose it to that level without the source.
Rather than fixing it, they chose to document around it.)

The CPU, OS, and machine architecture are evolved for this- this isn't
trying to play games with an x86- VMWare is cool, but it's a hack because
the architecture doesn't support virtualization well.

The virtualization is complete enough that I've never been able to write a
program that could tell what level it was running at. In fact, I'd be
interested in what anyone would use to do that. We used to put
"troublesome" users in 3rd level virtual machines (that is a VM running
under a VM running under a VM which was either running VM/CMS or MVS-
depending on their normal environment) just to make their performance suck
until they woke up and smelled the coffee. Never had one figure it out.

You can monitor inter-machine communication of virtual machines, and I'd
suppose LPARs at the host OS level. The guest OS' don't get real
hardware, everything is virtual to them, and that's the real power there.
VM was originally designed by IBM to develop their other OS' in, so that
they didn't need a new mainframe for each development group. Guests think
they're on real hardware, and there's nothing that's not abstracted
through a virtual device layer. Absent some silly subsystem stuff (and
that would require an evaluation and reading lots of those big red books,)
I'd trust VM as a base OS before I'd trust a firewall running on almost
anything.

The documentation level used to be astounding, I'd really recommend
looking at the "Red Books" approrpriate to whichever environments and
subsystems worry you.

LPARs should be better than that- I've just never dealt with them, so my
personal level of comfort is with VM as the only host OS and running lots
of guests.

I think you *can* set things up poorly, but you really have to try. I'm
sure there are ways to get through things, but I'd probably only really
worry about a serious audit if I were a significant target of choice, then
I'd probably go ask either Bill Murray or Bob Abbott who'd be a good
auditor for that environment.

VM's been out for what- ~30 years? Unless they've been doing weird things
lately, most of the work has probably been in addressing extensions, and
POSIXey stuff, not in how the virtualization is handled.

IMO, the only real argument you have here is "trusted insider goes bad, or
hoses a configuration there's only one layer of control." The counter to
that is probably either regular strong audits, or a different
architecture.

If there's significant data on the machines that won't ever hit the Web
interface, then you've got a classic seperation argument that may or may
not fly. Outside of principle, I wouldn't be all that concerned about
running such an environment, though I'd want to spend a good deal of time
digging at things, poking, prodding and maybe even writing some code.
Though it's kind of the cat guarding the hen house, you could also get IBM
to come in and have someone technical interactively address your questions
until either you're happy or they're beaten into submission...

HTH,

Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts@patriot.net which may have no basis whatsoever in fact."
probertson@trusecure.com Director of Risk Assessment TruSecure Corporation