Traditional Mac OS Versus Mac OS X | Maximum Mac OS X Security

If you've come to Mac OS X from traditional Mac OS, you might be wondering what all the fuss is about security. Your machine has never been broken into, and you've barely even had to worry about viruses. Over the years , various groups have hosted "Crack-a-Mac" contests, and even with tens of thousands of dollars in prize money at stake, and having publicly and vociferously thumbed their noses at the cracker community, the target Macintoshes mostly survived intact. What could you, with no incentive to crackers, and no reason for them to single your machine out of the crowd , possibly have to worry about? Now that you're running Mac OS X, plenty!

Mac OS X may have some of the same user interface fundamentals as traditional Mac OS, and the skills you use to get around and make use of software may translate between the two, but fundamentally, traditional Mac OS and Mac OS X are very different operating systems.

One of the biggest differences is that as interesting and useful as traditional Mac OS is, there just isn't much to it; it is a monolithic system. A single piece of software provides almost all the functionality that you, the user, experience as the operating system. This might appear to be a security impediment for traditional Mac OS. If that single piece of software is compromised, the entire system is compromised. For this reason, some security experts argue that traditional Mac OS is actually a very insecure operating system: It has almost no real protections , and if you managed to break into it, you'd have complete control over all it had to offer. Thankfully, traditional Mac OS is insecure like a brick. A brick has no network security features, and if you could manage to access it remotely, it wouldn't put up a fight, but generally , a brick can't be accessed remotely. Traditional Mac OS presented only a few opportunities for a malicious individual to do harm. If they couldn't get to the keyboard, and you weren't running software that explicitly allowed remote control of your machine, Macintosh, or brick, all that crackers were going to manage to do was beat their heads against the wall.

There are larger issues, however, with an operating system such as Mac OS X in which the OS is made up of many small, cooperating pieces of software. Instead of a single avenue of attack against a monolithic OS, Mac OS X (and Unix in general) provides a plethora of attack opportunities, as each independent program must be guarded against attack. More critically, to function together, these small programs need to be able to communicate with each other. Each line of communication is a point at which an attacker can possibly insert false information, co-opting the behavior of some fragment of the system into believing that it's performing a task requested by its proper peer, when instead it's acting on behalf of an attacker.

Compounding the problem is the fact that Unix is an inherently multiuser, multitasking system. Because it's designed to allow multiple users to use the machine at the same time, and even requires that multiple virtual users operate simultaneously just in the running of the bare OS, it's inherently less obvious when something that's not under your control is happening to your machine.

Despite our wanting to instill in you a sense that you have to take greater precautions with your new OS, historically speaking, Unix-based operating systems have been relatively secure, at least by comparison with some other operating systems you might be familiar with. Because security flaws in all software arises from the same general causes ”human malice or human error ”you might expect that all operating systems would have security issue experiences with a similar frequency.

To a large extent, the trend against the exploitation of major security holes in Unix is due to a history of Unix administrators and users taking a relatively inflexible stance toward security issues. If a security flaw is discovered in a software feature, that flaw is examined, probed, explained, and fixed, just as quickly as the Unix hacking community can fix it.

NOTE

>Crackers, not hackers: There seems to be a popular misconception that the term hacker means someone who breaks into computers. This hasn't always been the case, and annoys the hackers out there who do not break into computers. To many hackers, the term hacker means a person who hacks on code to make it do new and different things ”frequently with little regard to corporate-standard good programming, but also frequently with a Rube Goldberg-like, elegant-but-twisted logic. A decent hacker-approved definition is available from the Jargon file, http://catb.org/jargon/html/, specifically http://catb.org/jargon/html/entry/hacker.html. (This site has moved recently from its longstanding host, and we can't be sure this URL will work for long, either. If Jargon file entries can't be found here, please use Sherlock, Google, or your favorite search engine to track down a copy. The Jargon file is a wonderful reference to the way that large segments of the hackish crowd think and speak. Another possible linking source, should this one not work, is http://jargon.watson-net.com/).

Hackers, to those who don't break into computers, are some of the true programming wizards ”the guys who can make a computer do almost anything. These are people you want on your side, and dirtying their good name by associating them with the average scum that try to break into your machine isn't a good way to accomplish this.

Though crackers often seem to describe themselves as hackers, most true hackers consider them to be a separate and lower form of life (http://catb.org/jargon/html/entry/cracker.html).

So, to keep the real hackers happy, we refer to the people who compromise your machine's security as crackers in this book. We hope you follow our lead in your interactions with the programmers around you.

One of the primary reasons this has been possible is that the majority of the software that made the Unix networked community work was developed in an open -source fashion, where nobody in particular owned the code, and everybody had access to it. This community-based development and testing is the result of a culture of sharing and cooperation that has existed in the Unix community from the start. In this culture, nobody stands to profit from the existence of errors, and anybody who might be harmed can take the source, find the error, and publish a fix. It's usually considered a moral imperative that recipients of such open software will increase the value of what they have received by improving it, and returning these improvements to the community, whenever they are able. Unix users, historically, have done very well by working together, and looking out for each other.

With commercial software and operating systems, users don't have this security advantage. In some situations with other operating systems, security flaws that are product features are maintained for years, despite knowledge of the flaw and the required fix. For example, the feature of automatically opening and executing attachments in an email client seems attractive to certain vendors , probably because they believe that they can sell more copies of an "easy-to-use email client" ”which is also capable of wiping users' computers out if they receive the wrong email ”than they can of a more secure email client that requires users to think for themselves. A program that automatically executed unknown code on a Unix machine would have historically been laughed out of existence. To those who are conscious of and concerned about security, the very presence of such a feature is an unacceptable security risk.

Unfortunately for the security outlook for OS X, mainstream commercial software is a necessity for creating the seamless, convenient interface and software collection that Mac users have come to expect over the years. Some of this software comes from the same companies that take the inexcusable position of believing their users are so gullible as to buy blatantly flawed software because it's "easy." Protecting your machine in the face of this is not going to be as easy as protecting older Mac OS versions where the flaws they could introduce were not as critical, and it is not going to be as easy as protecting traditional Unix installations where commercial software is almost unheard of. We're delighted to see that Apple has made the core of OS X available as the open-source Darwin project, but to maintain the high level of ongoing security that has come to be expected from Unix, you, the user, are going to have to be as steadfast in your demand for secure software as traditional Unix users have been. If a product is simply a bad risk, for your machine, your users, or your network neighbors, tell the manufacturer, tell the world, and refuse to buy it. Because you don't have access to the source code, your caution and good sense in choosing software will be one of your machine's first lines of protection ”and your voice online, speaking as one with the rest of your new network neighbors and peers, will be your best shield against and best redress toward companies that display a malicious lack of concern for your security.

Top