Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
OpenBSD
OpenBSD claims to be "secure by default," and anyone who runs it gets a warm fuzzy feeling reading security advisories in popular programs with "does not affect OpenBSD" written at the bottom of the list of affected platforms.
The entire base system—kernel and userland—in OpenBSD undergoes a constant process of code review. When a new bug is discovered, the next step is to categorize it and search the rest of the tree for occurrences of the same type of bug.
This stringent checking is nice, but it applies only to the base system. Any third-party applications installed are not checked. To help reduce the problems, OpenBSD includes a number of security features.
No memory allocated by an OpenBSD program can be both writable and executable at the same time. Most operating systems support this on the x86 latest chips that support the NX bit, but OpenBSD supports it using the segment based protection mechanisms that have been available in all x86 chips for over a decade—and on other architectures.
A random gap is inserted between stack frames, making stack-smashing exploits much harder. This is combined with a "canary" value that is placed at the bottom of each stack frame and checked before returning to ensure that it has not been tampered with.
Allocated memory is inserted at a random location in a process’s address space, making it much harder for an attacker to guess where something interesting lies. There are many other mechanisms provided, and enabled by default, for ensuring an OpenBSD box remains secure.
Besides these features, OpenBSD pioneered a number of security features now found on other systems, such as SSH and sudo. The OpenBSD version of Apache, for example, runs in a chroot jail by default, so attackers who compromise Apache cannot do anything other than break the web server—they can’t even modify the contents of the web site on disk.
The downside is that badly written applications are more likely to crash on OpenBSD—something the authors consider vastly better than being exploited. Recent security enhancements to the memory allocation system resulted in X crashing regularly on OpenBSD. Further investigation revealed a bug that had existed for more than a decade in the X code, which had undoubtedly caused countless unexplained crashes.
OpenBSD, like NetBSD, is a very clean system and is designed to be easy to administer from the command line. While all of the BSDs have good documentation (the FreeBSD handbook in particular), the OpenBSD man pages are first rate. Nothing is allowed into the OpenBSD system that is user-visible unless it is accompanied by documentation, and the man pages are considered authoritative. The first place to look for documentation on OpenBSD is the manual; if it’s not there, there’s probably a bug.
The superb documentation available in the BSD community tends to make people who ask questions that are easily answered very unpopular. It is common for a question posted about a BSD system to be answered with a one-line reply instructing the asker to read the manual, This is good advice; the answer is usually there.
The OpenBSD packages system is currently the worst of the bunch. For a long time, upgrading the base system (a new release of which comes around every six months) meant deleting all installed packages and starting again. OpenBSD 3.7 added support for upgrading, but only of individual packages. OpenBSD 3.8 provided a full update facility, although it is considered experimental. OpenBSD 3.9 is expected to bring the package management system up to a more competitive level.