I think it all depends on how you set up the LPARs. You can assign a
fixed percentage of CPU, a fixed amount of memory, specific IO channels
and peripherals to an LPAR. And the LPARs can then be completely
invisible to the others. They are just like two physically separated
machines.
At one time, we have a powerful ES9000 mainframe with 4 LPARs on it. One
for testing, one for development and two for production use. All PTFs
must be tested in the testing LPAR first before migrating to production
use. I held an admin ID of RACF for one of the LPAR but have completely
no access to the other LPARs that I have no authority. Reconfiguration of
the LPARs require physical access to a dedicated hardware console which is
resided in an restricted area. We have encountered a case which one LPAR
is down because of insufficient virtual storage but yet the other one is
working perfectly OK. We re-IPL the LPAR without affecting the
other ! Another case was a hardware fault in the CPU
(which is very rare) that is allocated to a specific LPAR but again, the
other LPARs are just unaffected.
The workings of the LPARs are still amazing to me. I wonder why there is
no similar technology from UNIX vendors or for NT. A single runaway
process on UNIX or NT can bring the whole system down.
Of course, there are other ways to configure your LPARs and you can share
peripherals, but may need to offline it on one side before bringing it
online on the other side.
I guess many MVS admin working for years may still not be able to
circumvent the barrier imposed by the LPAR by exploiting bugs in the OS.
Of course, there are many other ways if you are an insider especailly if
you are an admin. But for an intruder from the Internet ? I can't think
of any mechanism that is possible. Maybe, some other more experienced MVS
admin listening on the list can shed some light on it.
But one thing to bear in mind. If you have any network connection between
the two LPARs, this is another story, especially if you installed
TCP/IP on your MVS. But it should be no worse than two physically
separate machines connected together through TCP/IP.
Lastly, I want to emphasize that, I did not say it is risk free. I just
meant my experience told me that LPARs are just like separate physical
machines even when I was an Admin. I wonder you would get any information
from this list of a way to compromise an LPAR even if this exist.
However, I wonder why you need to do that. Mainframe is much cheaper
nowadays. Why not use a small dedicated one in the DMZ ?
Vinci
On Mon, 13 Sep 1999, Bill Husler wrote:
> I have been asked to consider allowing the use of IBM's Domino Go Web Server
> (running on s390) for commercial (customer access through the Internet)
> applications. Our internet implementation dictates that any externally accessed web
> servers must reside on a DMZ and must make very restricted calls to database
> servers that reside within our network when data is required. This being the case,
> I expect the next question to be is it OK to connect one LPAR to the DMZ and
> another LPAR to the internal network within one single physical s390? I am looking
> for feedback (experiences, feelings, rumors and vague innuendoes). If one LPAR (the
> web server) is compromised would the other LPAR become "at risk"? could a DoS
> attack take down the entire box? Would it be possible for a suitably knowledgeable
> user to access data residing on one LPAR from a compromised one?
>
> Thanks in advance for your consideration.
>
> Bill Husler
>
> ps. I know this is not strictly a firewall question, but it's pretty darn close.
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
