Sep 00 Viewpoint
Volume Number: 16
Issue Number: 9
Column Tag: 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.
Secure by Default
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. :-)