At 8/19/2006 12:37 PM, you wrote:
In a recent note, john gilmore said:
> Date: Sat, 19 Aug 2006 15:14:20 +0000
>
> There are ways to do what you want to do. They would be APARable as z/OS
> security breaches if they werje described in sufficient detail to
be usable.
Yeah there are. All he has to do is have the right to write and
install authorized programs.
If there are ways for nonauthorized programming to breach security,
than (a) I for one do not know of them, and (b) they certainly would
be APARable.
However, for authorized programming, the rules change completely.
Yes, it certainly would be possible to manually build a DEB, and no,
it would not be APARable because it is acknowledged by both IBM and
by the mainframe community at large that authorized programs have the
power to corrupt the operating system in arbitrary ways, and so
authorized programs have to be trusted.
When a data center gives someone the right to add programs to
authorized libraries, just about any and all security can be breached
by that person. All it takes is knowledge, and there are probably
thousands of programmers who have both the access and the knowledge.
And thousands more, being unemployed, who have the knowledge but not
(for now) the access.
For nonauthorized programming, the MVS system is pretty much
bulletproof. (Am I right? I am not, by any means, a security expert,
but I think I'm right about this.)
But for authorized programming, the security is about as robust as
moldy cheese. (And I know I'm right about this!)
Security is both a technological problem and a managerial problem.
Both are essential to good security, but neither, by themselves, is
sufficient.
For any computer system, someone has to be trusted. At the very
least, the developers of a system, the developers of products for a
system, and anyone who needs to write authorized applications for a
system, these are all people who have to be trusted.
It is up to management to decide who needs to be trusted, and it is
important for them to make these decisions intelligently. But even
good management has full control only over their own employees. They
have no control over who IBM decides to trust, and only limited
control with respect to 3rd party vendors. (They can decide, within
the limits of available choices, which products to buy and which not to buy.)
Once management has decided who is to have what level of trust, then
it is important for technology to supply bulletproof tools that allow
management to implement their decisions with confidence. The problem
is, with respect to programming, there are only two security levels
available: authorized programming and nonauthorized programming.
With respect to nonauthorized programming, I expect that RACF is
about as good as it can be.
But in order to believe that MVS is a highly secure system, you would
also have to believe that everyone who has the ability to install
programs into authorized libraries is totally trustworthy. I dunno.
When you consider how many programmers there are at IBM, at 3rd party
vendors, and in house, that's an awful lot of people to trust.
That's a consequence of authorization being essentially a two tiered
construct. A program either is authorized or it is not. If it is
authorized, then it can corrupt any storage anywhere in any way that
it sees fit. All it takes is knowledge.
Also, IBM has made way too many useful services authorized-only
services. This unnecessarily increases the need for programs to be
made authorized.
It seems to me that there is something of a NASA mentality here. If
we were all honest, objective and thoughtful, we'd all know that
there is a huge problem here. But this two tiered authority system
has been with us for 35 years or so, were all comfortable with it, to
change it would be a huge and disruptive undertaking, and so let's
just sweep it under the rug and hope that nothing really bad happens.
In fact, I'm kinda surprised that nobody's yet written a root kit for
MVS. (Or have they? Nah... I think not. MVS is just too small a
segment of the industry for it to be worth it.)
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
PS: As for the notion of not talking about it lest somebody bad is
listening ... Well, this is a problem that's been ignored for 35
years, and so somebody bad probably already knows quite a bit about
it. Maybe if we do start talking about it, something will actually get done.
----------------------------------------------------------------------
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
