The widespread availability of source code for UNIX operating systems and programs has been a boon for security administrators. Providing source code for programs is an old tradition in computing; recently, with the increasing popularity of open source operating systems like Linux and programs like Apache, the tradition has been formalized. A group of free software evangelists lead by Eric S. Raymond have formed a non-profit organization that, among other things, has trademarked the term "Open Source" (see http://www.opensource.org/1).
Almost all of the security tools covered in this book are open source, as is the Red Hat Linux reference platform I'm using. The benefits of open source security software are numerous. In a process similar to peer review in the scientific community, open source code can be analyzed, audited, and vetted by dozens, hundreds, or even thousands of concerned practitioners. Bugs and other aberrations can be quickly discovered and patched, creating a substantial disincentive for programmers to place back doors, Trojan Horses, and other kinds of malicious code in their programs. In this way, open source software can be more trustworthy than proprietary software, illustrating what Raymond calls "Linus's Law" (after Linux inventor Linus Torvalds): "Given enough eyeballs, all bugs are shallow."2 Given open source, security problems can be characterized quickly and the fix will be obvious to someone.
In January 1999, attackers were able to plant a Trojan Horse version of the TCP/Wrappers tool on a well-known FTP site -- since source code is available, the back door was quickly noticed and removed. Contrast this with a monolithic operating system like Windows 2000, which has tens of millions of lines of secret, bug-ridden code. Without access to the source code, customers are 100% reliant on the good will and competence of the Microsoft Corporation, an entity with a well-documented record of malicious behavior.3
Naturally, just because a program's source is available doesn't necessarily means it's secure -- what I'll call "security through disclosure" isn't foolproof (though it's usually stronger than "security through obscurity" [see Rule 1: Security Through Obscurity Doesn't Work]). It's theoretically possibly for a programmer to create clean source code that nonetheless includes a Trojan Horse (see Rule 10: Trust is a Relative Concept). In general, source code needs to be widely distributed, reviewed, and fixed in order for its openness to be a security benefit. There have been cases in which popular UNIX utilities with available source have stumbled along for years with significant vulnerabilities4 -- perhaps people assume that a program that's been around for a while must be safe, or perhaps people were just too lazy or busy to fix it. Conversely, some of the most secure programs are probably deployed by national security organizations, with top-secret source code.
In some ways, open source can make it easier for the "bad guys" to find security holes in the first place, creating an ongoing "cat-and-mouse" game in which cooperating developers attempt to find and patch holes before they can be exploited. This is where the "sunshine effect" comes into play. Karsten M. Self describes this:5
There's still what I call the sunshine effect -- the good guys can act overtly, the bad guys must act covertly. Everyone -- good guy or bad -- has an interest in seeing that their own systems are secure. Hacks will happen, but both alerts and fixes will be communicated rapidly. While crackers operate behind pseudonyms, anonymous remailers, owned systems, and IRC, legitimate operators can communicate openly and to authoritative information channels (e.g.: CERT).
Community plays a large role in open source software. As Self points out, every UNIX operator has an interest in security. This communal interest gets played out in the open source community space, where good will and the free exchange of ideas and code benefits everyone. If you have a problem with an open source tool, you have a good shot at finding a solution online.
There are additional benefits of open source security tools. Most of them are more or less "free"; the solutions are available to anyone with the time and need to install them. This helps put the "little guys" on the same footing as large corporations, security-wise. An open source tool puts the system administrator in control of the level of risk assumed in deploying the tool. Perhaps you don't trust the open source developer any more than the proprietary vendor. Then you can audit the code yourself, or hire someone to do it for you. Finally, open source solutions are by their nature dynamic. Perhaps a tool doesn't do exactly what you need -- you can break open the code and fix it yourself. Open source provides a flexibility not available in closed products. Hopefully, if you do make improvements to an open tool you'll offer them back to the original developer and community at large. The give-and-take of the gift economy benefits everyone.
4. For an example of this phenomena, see Chapter 14 of Unix System Security Tools.
Copyright © 1999 by The McGraw-Hill Companies. Used with permission.
HTML Copyright © 1999 Albion.com.