Volume Number: 16 (2000)
Issue Number: 9
Column Tag: Viewpoint

Viewpoint

By John C. "Hsoi" Daub, Contributing Editor. Austin, Texas USA

What We Can Learn From OpenBSD

Like the whole of the Mac community, I am eagerly awaiting the arrival of Mac OS X. Not only will we have the best user experience of any operating system available today, but we'll finally have the muscle under the hood to go places the Mac has never been before. Coupled with hardware like the dual processor Power Mac G4 and the Power Mac G4 Cube, we're now ready to tackle the big server and business markets, right? Well, almost.

During a particular daily pilgrimage to the Slashdot website, I happened upon a few articles about OpenBSD. From the OpenBSD.org web site: "The OpenBSD project produces a free, multi-platform, 4.4BSD-based Unix-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security, and integrated cryptography." The security aspect of OpenBSD is what sets it apart from other operating systems; the OpenBSD project aspires to be number one in the industry for security, if they're not already.

Mac users have long boasted about the Mac OS's "security by default". When the U.S. Army's websites were cracked June 28, 1999, the Army responded by switching to Macs. Events like these allow Mac users to put a feather in their cap. The Mac OS isn't uncrackable, but lacking a command line and not being Windows nor Unix-like, many of the potential vulnerabilities of an operating system simply don't exist. But wait a minute! Doesn't Mac OS X have a command line? And what about the BSD layer and other Unix-isms present in Mac OS X? Hrm. Perhaps it's time for the Mac community to pay more attention to security issues. A good place to start, especially for us developers, is to take a cue from the OpenBSD project.

One aspect of OpenBSD's security stances is to be "secure by default". That means the operating system is shipped with all non-essential services disabled. As a user becomes more familiar with the system and desires to utilize more services, he or she will have to learn about the process and what needs to be enabled. Hopefully by going through this process, the user is more likely to learn about security issues. By educating a user in a safe and forgiving environment, not only does it lead to a smarter user, but hopefully helps him or her avoid learning about security the hard way.

Granted OpenBSD's target audience is different than Mac OS's, so it's likely what services the two operating systems would provide by default would be different as well. But by the same token, the target audience for the Mac OS is more likely to be less computer savvy than your typical OpenBSD user. With broadband Internet access growing exponentially and more and more people getting online (recall those iMac sales numbers), it becomes even more critical to the Mac user experience to provide a safe and secure environment right out of the box. Remember, according to that iMac commercial there are only three (well, two) easy steps to get on the Internet: plug in, get connected; there's no step three. Being a security expert is not one of the steps.

Improve Code Quality

How many times in the past few years have you heard about security problems due to "buffer overflow?" Ultimately it's just a "simple coding error," but how many of these errors could have been caught and fixed if greater emphasis was placed on quality of code instead of hacking in twenty new features and shipping before the end of the quarter? The potential cost of that simple error could be far greater than the costs involved in having a solid code review and auditing process in place.

The proactive code auditing process utilized by the OpenBSD project isn't as much about looking for security holes as it is looking for coding bugs. They simply perform an extensive analysis of every source file. If new problems are found, then previously audited code gets reviewed again with the new problems in mind. Auditing the code multiple times by multiple people helps to improve not only the security of the code, but also the overall quality of the code. It's a nice double-benefit.

I understand the realities of software development: budgets, marketing requirements, schedules running over, being severely understaffed. Unfortunately due to these realities, quality of code is often sacrificed, which results in less than optimal product quality. And if you ship a shoddy product too many times, people will stop buying your products and lose faith in your company. The OpenBSD project's focus on quality allows them to proclaim at the top of their website that it's been three years without a remote hole and two years without a local hole in the default install. That's the sort of quality consumers are starting to expect these days. Instead of making a fuss over how Mac OS X won't crash if one application crashes, why don't we just have applications that don't crash in the first place? We won't be able to hide behind our disclaimers and licensing agreements forever.

So What Can We Learn?

The Mac OS X public beta should be released by the time you read this. If Apple has already taken steps towards being secure by default, all the better! If not, it is a beta, so that means there's time to fix it. But this isn't just a call for Apple to do something; this is a call to you to rethink your assumptions and consider the implications that come with our new OS paradigm. Every line of code needs to be written and reviewed with security and quality in mind.

If we want Apple, and hence our own businesses, to grow and flourish in the server and business markets, we need to think different from all the other players in that field. Except perhaps the OpenBSD project; their stance on security and quality is where we need to start thinking the same.

John C. Daub spends his days working as a developer for Aladdin Systems, Inc., currently working on the StuffIt Deluxe team. John spends his nights as he always does: playing with his wife and kids. You can contact John at hsoi@hsoi.com.

Thanx to James Chamberlain, Carl Constantine, Ron Davis, and Jim & Mary Ellen Lee for their input; and to Jessica for being such a sweetie. :-)