At 8/20/2006 11:04 AM, PGilmartin wrote:
In a recent note, David Cole said:
DCole wrote:
Authorized programs can breach security.
There are too many reasons why authorized programs have to be written.
There are too many people who write authorized programs.
There are too many people (both inside a Corp. and outside[!]) who
have the right to install authorized programs into authorized libraries.
If I were responsible for security, I would be concerned.
What are the authorization requirements of software your company
markets? I perceive you wish they could be less.
I wrote my article without regard to my own personal "wishes" or XDC's needs.
Since z/XDC is designed to be useful for debugging all kinds of
programs, including authorized ones, it makes extensive use of a
large number of authorized interfaces.
When used to debug nonauthorized programs, z/XDC runs nonauthorized,
so when it needs to perform something authorized, it invokes a
private service SVC to perform that operation.
Our customers have to be willing to trust Cole Software that z/XDC's
service SVC is written both competently and without malicious intent.
Fortunately for us, our customers are willing to extent that trust.
Why? Well, we've been around for a long time and we've got a good reputation.
However, at the risk of cutting my own throat, I will go ahead and
state the obvious: I doubt that longevity and reputation alone would
be considered by a security professional to be sufficient criteria
for extending trust. And I don't think that even our security
conscious customers examine either myself or my employees with the
same level of diligence that they might examine their own employees.
VM is better in z/OS in this respect. I know utilities that require
APF authorization on z/OS, but operate comfortably in class G
virtual machines in VM production environments. VM CP can restrict
the set of devices a server can manipulate, and provide interprocess
communication to that server without giving that server higher privileges.
My experience with VM is only a little bit greater than nil. That
being said, however, ...
I think you're missing the point here. I'm talking about security,
not integrity. Security focuses on the protection of business process
and data. Integrity focuses on the protection of the software.
Violating integrity is only one tool by which security can be
breached. Sure, VM may be well designed to protect its own integrity.
But what about the business process/data being manipulated by the
program(s) running within the virtual machine? What does VM do to
protect the integrity of those programs?
In any case, I'm guessing that there are plenty of programs, both
customer written, vendor written, and IBM written, that have good
reasons to run within virtual machines that have higher privileges.
And I'm guessing that that's a lot of programs to trust. So think may
not be a whole lot of difference between z/VM and z/OS with respect
to this issue.
Dave Cole REPLY TO: [EMAIL PROTECTED]
Cole Software WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
