Security and Mac OS X is never an easy topic to write about. There's so much emotion, advocacy, and arguing going on that getting to the heart of the matter can sometimes seem impossible. However, once you sort past those issues, the state of security on Mac OS X isn't terribly complicated, nor bad at all. It's not perfect, but it's not the final world in Quake, with pitfalls and monsters behind every corner.

Even with the recent QuickTime Java vulnerability discovered by Dino Dai Zovi at the CanSecWest contest, the Mac isn't suddenly a kitten in a shark tank, waiting to be devoured. There always have been, and always shall be, vulnerabilities in this, or any other operating system and platform. It's a fact of life, and one that Mac users in particular, should approach with more of a sense of equanimity and awareness.

When we're talking about the state of security on Mac OS X, it's useful to use the kinds of threats we hear about or have heard about in the past as a guide to help us focus our discussion. I'll do the same here, moving from the more "human-based" issues to the more "human-excluded" issues. I'm also going to, in the interests of clarity and space, stay out of larger security issues like firewalls, NAC, etc. This article is focusing on Mac OS X and the Mac user as much as possible.

Mac users are exactly as vulnerable to phishing and social engineering attacks as any other platform. If you voluntarily give out personal data, passwords, user ids, etc., there's nothing an operating system can do to protect you from the results of those actions. Browsers and e-mail clients are starting to try to incorporate various antiphishing measures, but at the end of the day, this isn't something that can be solved via a purely technical solution. If you give out the keys to the kingdom, as it were, you will have some rather severe barbarian problems.

The best way to deal with these problems is awareness and avoidance.

Be aware of the people and entities that would have a legitimate reason to get various kinds of information from you. In the case of passwords, there's no IT department that is even vaguely competent that needs your password to run any kind of test, upgrade, or what have you. Unless you are the sole possessor of the root/directory administrator password, there's no reason for IT or anyone else to need "your" password.

On the networks I run, I can do anything I need without needing a user password. If I need a user to log in as themselves, then I have them do that. I don't know, nor do I wish to know, anyone's password but the ones I have to know to do my job. It's a bad idea on every level to know other people's passwords unless you have a hard, unavoidable reason to do so. I've yet to run into one.

If you give someone your login credentials, especially if they're admin-level access credentials, then there's little the operating system can do to stop them, as they'll not be "hacking" into the box at all. They'll be signing on as a legitimate user: You.

At that point, the operating system is going to let them do whatever those credentials allow for, because that's how it's supposed to work. Even worse, any action they take will look like you took it, because it's happening under your credentials.

The same thing goes for phishing. If you click on a link and give someone at random your credit card numbers, Social Security, tax ID, or government ID number, there's nothing the operating system can do to stop them from using that information in a way you don't like. Remember: No operating system in the world can stop someone determined to do something silly.