This chapter is from the book
This chapter is from the book
This chapter is from the book
2.2 OpenBSD Security
OpenBSD’s top priority is to be secure, and it was designed with security in mind throughout every stage of development. OpenBSD has remained immune to most of the exploits and attacks that have surfaced during its lifespan. The code for the core OS and the packages required for its installation have been carefully audited, and are generally considered to be secure. An additional constraint placed on the OpenBSD secure development model is that the base system must attempt to be cohesive with the original BSD model, preventing applications from breaking when possible.
This can all change, of course, when the next insecurity paradigm arises—for example, with the discovery of format string attacks in the summer of 2000. The OpenBSD group tries to stay ahead of the curve and implement preventive security measures; so far, it has proved successful. The code undergoes continual scrutiny and audits, and apparently innocuous bugs are fixed on the chance that they may be deemed exploitable at some later date. The OpenBSD team can typically provide a vendor response along the lines of “This was fixed at some earlier date.” By remaining an open development model (everyone can view the CVS change logs), OpenBSD is constantly sharing its experiences with the larger community. Additionally, some developers within the project work on other software projects and incorporate OpenBSD security fixes into their own software; OpenBSD also benefits from these other projects by incorporating some of their code or ideas.
The OpenBSD team was one of the first large-scale development teams to adopt the now basic software engineering standard: Fix bugs, and classes of bugs, rather than just vulnerabilities. This means that system security can be enhanced by ensuring code correctness. Handling error conditions wisely is another part of correct development. Lastly, OpenBSD attempts to operate with as little privilege when possible, by having programs drop privileges as soon as feasible or by increasingly using the privilege separation mechanism. By applying these principles throughout the system, OpenBSD enhances overall system security.
2.2.1 The OpenBSD Security Model
One of the major goals of OpenBSD is to be a secure BSD-based UNIX system, and remaining BSD-centric is important to the project. For example, the developers have decided against incorporating features such as POSIX.1e capabilities, commonly referred to as “Orange Book” features. The system is to remain as generic a UNIX version as possible, but as hardened as possible within that constraint. Enough room exists within the traditional UNIX model to allow for a very secure and reliable system.
To accomplish this goal, facets of security have been incorporated into the system in a variety of places. Within the kernel, for example, subtle changes have been in place for years, such as randomized process IDs. This may seem unimportant, but it is a useful measure. Several applications use process IDs as security markers, and their predictability can be exploited to abuse the system. The kernel also has a strong random number generator, which it employs to hand out “entropy” to processes. Likewise, TCP initial sequence numbers are extremely random—far more unpredictable than on any other operating system available.1
Cryptography has been extensively developed and fully incorporated into the system as well, including the Blowfish and Advanced Encryption Standard (AES) algorithms (the latter is based on Rijndael). This feature is available to applications through the regular APIs. The advantages of this approach are numerous. An example is the ability to encrypt pages of swapped memory. If an attacker is able to obtain access to pages of swap that contain sensitive information, he or she would have to decrypt the data first before using it for nefarious purposes.
2.2.2 The Audit
Most people know about the full code audit of OpenBSD that began in the summer of 1996 and found thousands of bugs, including new types of software bugs leading other OSs to perform further security audits. This effort has produced a system well known for its reliability and correctness, plus an overall reputation of security throughout.
What few people realize is that the audit is continual. Almost every line of code is thoroughly audited, bugs are fixed, and many security vulnerabilities are eliminated.
One of the key facets of the OpenBSD approach to code auditing is the idea that “Bugs are what lead to security vulnerabilities, so bugs should befixed.”This is in contrast to many development efforts, which focus on vulnerabilities ahead of bugs. In taking its approach, the OpenBSD team has found that classes of programming errors produce a common bug pattern. This immediately leads to the notion that it is important to scour the source code for similar bugs, which the team periodically does when new classes of bugs are found.
This isn’t to say that every bug that could be fixed is. In several cases OpenBSD has fallen victim to security problems, and in a few cases this OS has been the only one with a security bug. The development team is a group of humans and makes mistakes. Bugs get fixed and everyone moves on.
2.2.3 Cryptography
Along with strong security comes the use of cryptography wherever possible. A very secure operating system is useless unless you can do work securely with it. This is where cryptographic tools come into play. OpenSSH is used to allow secure connections and file transfers over the Internet. A strong random number generator is used throughout the system for everything from process numbers to salts for password generation. String hash transformations are used for the generation of MD5 hashes, S/Key passwords, and other items. The default cryptographic scheme of DES has been replaced with Blowfish to create much stronger user and system passwords. OpenBSD even supports a wide range of encryption hardware.
2.2.4 Proactive Security
OpenBSD is unique among operating systems because of its pervasive security goal; it has proactive security. OpenBSD developers are constantly working to find new security problems before they appear in the wild, and to apply these findings to current and future sources in the form of audits. In addition to making extensive use of tools and techniques such as chroot and privilege separation, everything is designed in such a way that problems are prevented and circumvented even before they came into being.