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 downsj@downsj.com. _________________________________________________________________ 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.