Why to BSD in a Linux World
From: http://alfa.mas.bg.ac.yu/~ggajic/pub/bsd.txt
Computer Bits Online Free one-on-one computer help!
Internet Gateway Advertise with Computer Bits Browse our Archives
Subscribe to our Mailing List About Us Table of Contents
March 1999 Volume 9 o Number 3
Why to BSD in a Linux World
There are alternatives ... by Jason Downs
Linux may very well be the most popular "open source" operating system
at the moment, but it is certainly not the only one. It wasn't even
the first one. There are alternatives, ones whose roots lead directly
back to one of the most advanced and widely used UNIX operating
systems in existence.
Some History
To make a long story far shorter, the source code to various versions
of the original UNIX was licensed to a few universities. Probably the
one with the most impact on the world of computer operating systems
was the University of California at Berkeley. Building on the base
provided by Ken Thompson, Dennis Ritchie, and the other programmers at
Bell Labs, what would be known as the Computer Systems Research Group
(CSRG) at Berkeley added extensions and features that have defined
what UNIX is today. They added the first implementation of TCP/IP, job
control, virtual memory, new file systems, the text editor vi, and
countless others.
The only thing holding them back was the very strict proprietary
license covering the original UNIX source code. Getting a copy of the
Berkeley Software Distribution required a license from AT&T. Although
many organizations received such licenses, and development of the BSD
system spread, it wasn't enough.
The release notes of a version of 4.3BSD distributed by the University
of Utah contained a rather short list of what they felt needed to be
rewritten before the source would be free of license restrictions. It
turned out that there was much more, but, eventually, the source code
for the modern BSD system was released. Named Net2, it contained
almost everything required to build a functioning BSD operating
system.
Unfortunately, not everyone agreed that Net2 was free of old UNIX
source code. After a lawsuit, a countersuit or two, and a lot of bad
blood, the CSRG and Berkeley made what they said would be their last
release. With a stamp of approval from the owners of the original
code, 4.4BSD-Lite was released. Eventually a number of improvements
and fixes would be consolidated in a very limited release called
4.4BSD-Lite2.
When Net2 was produced, it was quickly snagged and turned into a
mostly fully-functioning operating system. Much of this original work
was done by William Jolitz, who used his previously encumbered 386BSD
as a base. After he stopped maintaining it, the Net2-based 386BSD
evolved into FreeBSD. Meanwhile, NetBSD formed as a separate project
and, rather than focus on the PC, it followed the footsteps of 4.4BSD
more closely and eventually ran on several different architectures.
Just as political reasons kept FreeBSD and NetBSD apart, political
problems caused the spawning of OpenBSD.
Three Versions
Now we have three different freeware versions of BSD, all currently
based on 4.4BSD-Lite and Lite2. The developers of all three believe
strongly that BSD source code must be free of restrictive licenses.
Each offers its own advantages: Open-BSD's focus is on security,
FreeBSD's goal is to be easier to use and to have better performance,
while NetBSD is mostly an academic research platform. Both OpenBSD and
NetBSD run on machines other than Intel-based PCs; FreeBSD still does
not fully support any other architectures. All of them, to various
degrees, share code with each other. Since I am an OpenBSD developer,
this article will focus primarily on OpenBSD, but many of the things I
say will apply to the others.
OpenBSD and Linux
From the user's viewpoint, OpenBSD and Linux are a lot alike. Both run
XFree86 (the X Window server that supports the PC and associated video
cards); both come with the GNU C Compiler (GCC) and associated
utilities; and both support multimedia applications, such as TV
viewers and MPEG3 players. Most portable UNIX and X Window programs
will compile under either one.
Because Linux has more users, it has more commercial applications like
Netscape and WordPerfect. Fortunately, most of these applications also
run under OpenBSD using its built-in Linux binary emulation. Even
Quake2 runs under OpenBSD; several of the Portland-area Quake2
dedicated Internet servers are OpenBSD systems.
Most of Linux is licensed under the GNU General Public License
(usually referred to as the GPL). Of course, the BSD projects do not
believe that an entire operating system needs to be distributed under
the GPL. Since the GPL, in the name of being free, limits the overall
freedom of a developer to do what she likes with the source code, it
is considered to be a restrictive license. Some components included in
the various versions of BSD, like GCC, are in fact licensed under the
GPL since they are developed separately and no BSD-licensed equivalent
exists, but most of the system is not. Rather than always requiring
the distribution of source code, the typical BSD license permits
software derivatives to be proprietary. While the goals behind the GPL
are certainly noble ones, in practice there is very little proprietary
development of BSD software that doesn't eventually get released as
free source code.
Licensing aside, there is another major philosophical difference
between Linux and BSD: how each is developed, or "the development
model."
Linux itself is actually only a kernel: the portion of an operating
system that handles devices, manages memory, runs programs and does
other things like provide an interface between the computer and its
network. Everything else that makes up the Linux operating system is
contained in separate programs, usually written by different
programmers than those who work on the kernel. The entire system is
integrated and packaged by yet another person or company and sold or
given to users as a distribution. The distributor has little or
nothing to do with the actual development of the kernel or of the
other programs that they're packaging: they just make a few changes,
compile everything and create installation tools.
Different Approaches
OpenBSD and the other BSD systems are not developed like this. All
user programs are developed in conjunction with the kernel, from the
same collective source tree, using the revision control software named
CVS. This allows a much higher level of system quality control and
better overall integration: If an internal API is added or changed,
all programs using it will be changed at the same time, without the
system having to remain compatible with previous interfaces. When a
security feature is added to the kernel, all of the user programs that
should be using it will be modified at the same time. Conversely, no
single person or organization has complete oversight of every program
that makes up what is considered the Linux operating system.
Every change to any part of OpenBSD or FreeBSD can be reviewed by
anyone over the Web or by using CVS directly. Instead of downloading
huge archives of kernel source or fighting to apply patches, anyone
with a source tree can update the entire thing, both the kernel and
all user programs, with a single CVS command. Kernels are configured
by a command that reads a text configuration file, instead of an
interactive script, while the entire userland (everything except the
kernel itself) can be compiled and installed with a single run of
"make." This level of system integration is the most fundamental
aspect of BSD, and, because of it, one of the most important
differences between Linux and OpenBSD is possible: system security.
A More Secure System
Almost two years ago, the OpenBSD project developers began a full
security audit. Extra effort was put into examining the entire source
tree for previously undiscovered bugs and security holes. Countless
bugs were fixed, mostly of the type that lead to program crashes and
security compromises called "buffer overflows." Although the technical
description of a buffer overflow and related problems is too lengthy
to detail here, the short description is that too much or unexpected
input from a user or another program can cause a buggy program to
overwrite certain portions of memory. If done in a specific way, this
can cause the buggy program to execute instructions embedded into the
input before it crashes.
The concept of setuid programs is familiar to many UNIX users, as they
have been around since very nearly the birth of the original UNIX
system. These are programs that run with the privileges of another
user, usually a system account and, in particular, the superuser
(root) account. These privileges are required to do things like allow
users to change their passwords; without setuid root programs, the
multi-user UNIX system would be chaotic and far less secure. When
buffer overflows occur in a setuid root program, it becomes possible
to compromise the system and gain superuser access. In fact, there are
often pre-made scripts called "exploits" thaat do nothing but take
advantage of system bugs to compromise security. These are used by
malicious "script kiddies" to gain access to unprotected systems. ISPs
that offer shell access are particularly at risk.
Buffer overflows are only one example, of course. There are many more
types of bugs, like race conditions, where a program can be tricked
into over-writing system files. Denial of service attacks are also
common these days, usually involving network protocol bugs that cause
attacked systems to stop responding, or to crash.
Because of the BSD development model, OpenBSD in particular has been
able to avoid many security problems over the past couple of years.
The network code has remained running through several denial of
service attacks that have crashed Linux and Microsoft systems across
the Internet, and it has remained secure when many other (both free
and commercial) systems have been compromised by widely publicized
buffer overflows and other setuid program exploits. In fact, some of
the common exploits in use today were created because bugs that were
fixed in OpenBSD highlighted the problem in other systems.
Since BSD code is often shared between different platforms, such bugs
have also been fixed in the other BSD systems. The commercial
platforms have also begun to fix their own problems, although at a
much slower pace than their "open source" alternatives, and usually
not until the bugs have become public knowledge on Internet mailing
lists such as a BUGTRAQ.
Linux's Role
Where does Linux fit into this? Well, Linux developers certainly do
fix bugs. Individu-ally, one a time, in separate sets of source files.
Perhaps some day most of them will be fixed. The Linux development
model (or, rather, lack of one) simply doesn't support a tightly
integrated or secure system. Everyone is off doing his or her own
thing, while outside of the kernel, there is no real, overall,
coordination, and the Linux distributors have shown repeatedly (by the
number of bugs that they let get by) that they can't make the system
secure.
For single-user PCs without dedicated connections to the Internet, and
which don't contain sensitive data, Linux is probably an appealing
alternative to the latest offering from Microsoft. It's certainly easy
for the average user to get and install.
For other users, there are alternatives.
Resources
The following are URLs for some of the software mentioned in this
article.
OpenBSD: http://www.openbsd.org
FreeBSD: http://www.freebsd.org
NetBSD: http://www.netbsd.org
CVS: http://www.cyclic.com
For the security inclined, the Internet mailing list BUGTRAQ is
recommended. Archives can be found at
http://www.geek-girl.com/bugtraq/index.html (among other places).
About the Author
Jason Downs is a long time user and developer of OpenBSD. He and his
cat, "bit", collect old computers. He is also the Senior Systems
Administrator for Pacifier Online. E-mail to [email protected].
_________________________________________________________________
Search our archives: _____________________________________________ Go!
You can also get a listing of articles by Jason Downs
If you need instructions for our search engine, go to our main search
page.
_________________________________________________________________
This article was originally published in the March 1999 issue of
Computer Bits magazine, and is copyright Š 1999 by Bitwise
Productions, Inc., Forest Grove, OR, (503) 359-9107. All rights
reserved. Archival material is provided as-is. Links are not
necessarily maintained. Recent events compel us, sadly, to emphasize
that your rights to this article are limited to viewing it and
printing it for personal use only. You must receive explicit
permission from Computer Bits and the author(s) before reprinting or
redistributing this article in any medium.
 |  |
 |
