Here I'll focus on Unix for a while (because it gives me opportunities for cheap shots, I guess).
This document is an overlay of multiple edits, because there's always a new breach of security. Some of the text here goes back to 1995, so I try to identify the "vintage" of each incident). When I've revised this document, I always worry that Unix and PCs will finally provide reasonable security, and that I'll have to remove this section, in which Unix and PCs compare very poorly compared to VM. Fortunately, they never disappoints me in this regard, and there's always a public, fresh assault on a Unix system to refute the claims that Unix has achieved some degree of safety. In fact, it's far too much work to keep adding the latest incidents to this discussion; they keep recurring at the most recent Unix and Windows levels. In just this week (March 1996) I've read about new security attacks against Unix using traditional holes. Lest PC owners feel smug, there have also been recent breaches in Java and Javascript, new series of viruses, and a new risk: viruses embedded in Microsoft Word documents. (Updating this in 1999 - the situation has not changed fundamentally, except that it's now ActiveX controls and macro viruses causing more grief).
The problem is that Unix has fundamental weaknesses in security and data integrity, perhaps unimportant in research and academia, but critical everywhere else. Most operating systems provide much better support in this area than Unix. Security problems with Unix have been well-publicized, especially by the famous Internet virus. For example, December 1991, Unix systems were penetrated in the supposedly secure U.S. Department of Defense military network, as reported in the national news. Military computers running Unix were even penetrated during the war with Iraq, by Dutch teenagers.
To quote from Unix security specialist Dr. Frederick Cohen, in Workstation News, February 1992:
One of the major US telephone companies was in an ongoing 24-hour-a-day battle with international crackers who continued to break into Unix systems despite concerted efforts to stop them. One of the major US workstation manufacturers recently released a computer virus in one of its Unix operating system distributions.
To a large extent, Unix's security problems derive from its history as an open programmer's system. Explicit action must be taken to protect Unix files and data. Even main storage is treated as a device, and can be accessed by C programs. Systems administrators and privileged programs must take special care to avoid invoking Trojan horse programs in user directories: a most common way of breaching Unix defenses. Again quoting Workstation News: Basic design flaws in Unix allow a host of attacks to go unchecked. PCs, of course, were never really designed with security in mind, and present a fertile playground for hackers.
Trivial mistakes, like including the current directory in the command search PATH make it possible for root shell scripts (suid scripts) to unsuspectingly run Trojan horse programs from a user's directory, with terrible consequences. Worse, there's no systematic way to assure oneself that this hasn't happened. There is a well-known, widely distributed list of Unix security exposures that hackers use to attack Unix systems. Some of them are very easy to deploy.
You will occasionally hear Unix weenies claim that all systems are the same in this regard, and that MVS and VM only offer "security through obscurity", that is, they are so little used and unknown that nobody knows how to penetrate them. This is nonsense. I am just old enough to remember when IBM's mainframe operating systems were open to attack, in the OS/360 days, and my undergraduate friends (surely not I!) had lots of fun penetrating and crashing systems. As soon as IBM moved to the virtual storage versions of their operating systems, system crash attacks beyond boring "denial of resource" became far too hard to attempt, and the culture of crackers moved to other more fruitful platforms. Unix weenies will also say that Unix really is very secure. This is equally nonsense. If you don't like the reasoning or examples presented here, I recommend you visit the white papers published at Cybersoft website at www.cyber.com. I especially recommend The Plausibility of UNIX Virus Attacks, by Cybersoft's Peter V. Radatti. This paper begins with
I am still amazed at the number of people who somehow believe that UNIX is immune to software attack. Recently I was the subject of a heckler at a conference in which I was speaking on this subject. It appears that this is a subject that still angers some people so much that they become obnoxious.... ... I can only state that those individuals who work hard and diligently at remaining ignorant of the world around them have themselves as their most appropriate punishment.Does this sound familiar?
We should definitely consider Unix's lack of proven security (or rather, proven lack of security) a liability and risk that needs to be considered. The breakins on MilNet (military net) indicate that even the armed forces are easily, and repeatedly, penetrated.
Cliff Stoll, the author of The Cuckoo's Egg, an account of how he tracked down hackers penetrating his system (and many other academic, research, and military sites), is widely considered an expert in Unix security, yet is repeatedly trashed by revenge-seeking hackers that penetrate his system. He is apparently unable to prevent this.
The Free Software Foundation, which is dedicated to open systems and free distribution of software, had to disconnect (at least briefly) from Internet when it was continuously being cracked and its files destroyed. That's really a shame, because FSF is devoted to the idea of truly open systems and distribution of ideas and software - burning their system really is a sin.
Unix systems are also subject to a number of denial of resource and self-inflicted system crash situations that are cured or preventable on mainframes. For example, a Unix system has a fixed number of both file handles (allocated for each open file) and processes. One of our competitors had recurrent problems simply taking nightly backups because application programs opened too many files, preventing the backup software from opening its files.
A program can easily crash Unix simply by opening too many files or starting too many processes. Almost every seasoned Unix programmer can tell you a number of legitimate program actions that, if done in excess or incorrectly, can crash a Unix system or make it unusable for themselves or others. PC operating systems are prey to a myriad of constantly evolving viruses, making it unsafe to run any software whose provenance is unknown.
It astounds me that people would tolerate Unix and PCs for commercial applications for this one reason alone. This lack of security and robustness would never be tolerated in an MIS-provided VM or MVS system. People just tolerate this obscene flaw of PCs and Unix as a normal occurrence; a quirk to put up with. I didn't have to turn my VM systems off on Michaelangelo's birthday to avoid a virus.
This problem is not going to go away, and we should stop deluding ourselves that it will. Security exposures are always being discovered, followed by jumbo patches to try once again to close them up. Whenever I look at the appropriate ftp sites, I see reports of different security exposures in Sun's Solaris dialect of Unix, as well as IBM's AIX.
I'm writing this paragraph in March, 1996, and just read New York Times reviews of books like Takedown about Kevin Mitnick and his penetration of computers owned by Tsutomu Shimomura. These books paint Mitnick as a master criminal, and Shimomura as the computer genius who tracked his adversary down. Very James Bond.
I have to admit that my first thought was If Shimomura is so darn smart, then how come his system got penetrated?. That's not quite fair, I suppose. Shimomura is smart, but Unix is so stupid that even experts get penetrated all the time.
I was going to stop here, but today's (March 31, 1996) New York Times has yet another article, about an Argentinean student, Julio Ardita, who penetrated computers at Harvard University, NASA's Jet Propulsion Laboratory, Ames and Los Alamos, the Defense Department, the Navy's Naval Command, Control and Ocean Surveillance Center, and Naval Research Laboratory. How nice that he was unable to penetrate Army computers. NASA alone spent over $100,000 on the investigation and added security precautions to block future illegal entries. Isn't that reassuring? I don't see why anybody should think that this problem has been solved, even for the computers in question. The Times article noted that this was the first court-ordered wiretap on a computer network; surely there will be more to come.
The saddest thing about this sorry aspect of modern computing is that our expectations have been lowered to the level provided by Unix and PCs. People no longer expect that a computer system, reasonably administered and with suitable precautions, can actually be exposed to public networks with a high (but not complete level of security). Because Unix is so bad, and PCs are so bad, the popular impression is that no computer systems are capable of defending themselves against attack, and we must shield them with expensive layers of firewalls, or disable valuable services. Those of us who grew up on more robust systems, such as MVS, VMS, and definitely VM, know better, but it's hard to convince anyone that this sad state of affairs is unnecessary. That's what we get for letting Unix and PCs win...
This is a prosaic but unique capability: VM systems have no problem setting up multiple copies of services that can only appear once in other environments. For example, unlike MVS, VM lets multiple copies of VTAM and NetView be in operation. This can be used to provide redundancy for failure toleration, to provide performance gains or to provide application isolation. We also run multiple copies of TCP/IP and their services, including FTP, SMTP, and World Wide Web.
An even more fundamental usage is providing multiple versions of the same product, with equivalent performance and equal software access. MVS provides a single name space for its link pack area (LPA) of shared reentrant programs, so you can't execute both shared and test versions of a program with equivalent performance. Moving the new version into production (or backing it out) requires at least an IPL. In VM, we casually create separate, shared copies of CMS and program products like SQL/DS, FOCUS, VSAM, C/370, APL2, FORTRAN, GDDM, OfficeVision, XMENU, SAS, and so forth without these concerns. At our site, we keep both old and new versions available in parallel for extended testing, and then make the new one the default whenever we're satisfied, usually by replacing an EXEC. The comparable task is much more difficult in MVS. One of my MVS friends complains to me about the difficulty and risk he has to face putting LE/370 into production. Don't even think about concurrently running parallel versions of OS/2, MS-DOS, Windows or Unix on the same workstation! (A capability I often miss), or even multiple levels of MS Office!
The previous sections discuss consequences of VM design that make it a safer computing environment. VM's good design, component isolation, and the significant effort IBM has expended, make today's VM systems highly reliable as well.
VM is an extremely reliable environment, which may be a shock to those of us who remember VM's earlier days, and the reputation it (often unfairly) had. VM was designed to crash and burn when it detected an internal error, compared to the MVS keep running at all costs method of error percolation with individual component failure. Crash and burn is actually a quite legitimate method for producing reliable systems because bugs surface quickly. By taking a dump at the earliest point of discovery, VM produces good failure documentation that helps identify the problem. The MVS method sometimes leaves you with a system that is technically up, but in a state where you can't do anything useful. When you finally take a dump the trail has been impossibly muddied by events between the true failure and the storage dump.
I would have to claim, based on the MVS and VM systems to which I have access, that VM has been as reliable (or more) than MVS since at least 1987. IBM reports remarkable improvements in reliability in each of its VM/XA and VM/ESA releases. I believe these reports, and think IBM should be highly commended for their accomplishments here.
In fact, VM is by far the most reliable operating system at my company (knock on wood!). We have far fewer crashes or service-breaking outages than MVS. Merrill Lynch's longest ever availability record belongs to VM, not MVS.
One Merrill Lynch VM system spanned 319 business days without an unscheduled IPL, and went over a year without a software crash. This is many times better than any competing system in the company. I used to buy the VM systems group lunch at an expensive place when we broke the previous record by 5 days, and they don't get free lunches from me very frequently any more.
Nobody even suggests that Unix or PC systems can achieve this level of reliability. Some of my colleagues have experienced multi-day duration LAN outages, rendering their desktop systems useless, and making them powerless to do their jobs. There's an attitude of If it crashes we just reboot that I find distressing, but they really can't do much better than that.
I've recently been involved in efforts of a leading Unix vendor to provide higher reliability, availability, and serviceability (RAS) for their product line. Without saying who they are, let me assure you they acknowledge that their products are very immature compared to mainframes with much lower levels of RAS. There are a wide range of systemic problems on Unix and PCs that make them susceptible to failure. I live in this world, and I'm very frustrated at how hard it is to make Unix and NT adequately reliable. They don't understand serviceability either - you can't back off a major upgrade of the OS (or, on NT, even packages like Office) without multiple hour outages. To their credit, they're embarked on trying to solve these problems, but they will take years to fix: you can't just add RAS to a system like a condiment. VM enjoys a dramatic advantage.
Reliability is a key attribute of an operating system, and we should advertise VM's strengths in this area. Years ago, MVS advocates would say Yeah, VM's fast, but MVS is reliable. This was sufficient to keep VM out of many sites. Now that VM is unquestionably both fast and reliable, we should make sure that everybody knows about it, and compare it to the less reliable NT and Unix. A system is of no value when its down.
I'll also mention that there's no need to reIPL VM on a weekly basis, a common practice on MVS systems (to relieve storage fragmentation). VM doesn't need to be IPLed for application level "core cancers" either! With VM/ESA Release 2 and dynamic reconfiguration, VM provides IBM's best support for continuous availability.
It's worth remembering that a distributed system has many more single points of failure (single component failures that make applications or systems unavailable) and is inherently less reliable. Butler W. Lampson, winner of the prestigious A. M. Turing award of the Association for Computing Machinery, for his work on distributed computing at Xerox's Palo Alto Research Center, defines distributed systems this way:
A distributed system is a system in which I can't get my work done because a computer has failed that I've never even heard of(Cited in Computerworld, April 5, 1993)
This can be addressed by adding redundant servers, networking, and workstations, but at an extremely high cost in money and complexity. Nonetheless, the mainframes are still far more reliable and robust, even after expending the effort for distributed systems. Since the most unreliable part of a computing environment is necessarily the network (because it has to deal with physical objects of lower reliability than those imbedded in a single CPU), network-oriented computing must struggle to attain the reliability we now expect of our mainframes.
[ Prior page | Next page | Top page ]