OpenBSD 3.5: a peek at another free Unix

Initiated by Theo de Raadt back in 1996, OpenBSD's primary goal is to build a free and highly secure operating system. The developers pride themselves for a remarkable achievement of eight years with only a single remote hole in the default install. Although OpenBSD doesn't support nearly as many processor architectures as NetBSD, its original parent, the latest release of OpenBSD is available for 13 platforms, including Alpha, AMD64, PowerPC, SPARC, as well as i386. But despite fundamental technical differences between Linux and BSD, a system administrator familiar with Linux will find it relatively easy to administer an OpenBSD box, especially after reading the project's online manual (which includes a section about migrating from Linux to OpenBSD), or the superb Absolute OpenBSD by Michael W. Lucas.

How is security in OpenBSD better than in other UNIXes? Let's take a look at some of the more interesting features found this BSD flavor: file flags, securelevels and systrace.

• File flags. File flags are an OpenBSD concept enhancing the traditional UNIX file system permissions. Once applied to a file, the flag will either prevent a user, including root, from removing or modifying the file in any way (the schg flag), or will only allow appending new lines to the file (the sappnd flag). A good example of the effectiveness of this concept is making the the entire /bin directory recursively immutable with the schg flag; once applied, it will be very hard for an attacker to place a trojan into the directory. On the other hand, the append-only sappnd flag is often used on log files to prevent potential intruders from covering their tracks. Besides system-level flags available to root only, similarly structured user-level flags allow users to set append-only or immutable flags on files they own.

• Securelevels. The concept of file flags works in conjunction with OpenBSD's securelevels, of which there are four: -1, 0, 1 and 2. As soon as a file flag is set, it cannot be removed unless the system is in securelevel 0 or -1. To extend the example from the previous paragraph about making the /bin directory immutable, what happens if an executable file in the same directory needs to get a security patch, but the system is in securelevel 1 or 2? In this case, the system administrator will have to lower the securelevel in the BSD kernel by rebooting the system (while the system is running, the securelevel can be raised, but not lowered). As this example illustrates, the introduction of securelevels can prevent some common security exploits, but as a trade-off, it makes the system less flexible, especially when it comes to patching or upgrading applications.

• Systrace. OpenBSD's systrace, a policy-based system call access manager, is conceptually similar to SELinux. Like SELinux policies, the systrace policies define which users and programs can access which files and devices in a manner completely independent of UNIX permissions. Proper use of systrace can greatly reduce risks associated with poorly written or exploitable applications. While defining systrace policies is not a simple task, it has been made more palatable by the fact that systrace has been around for a long time and there are many online repositories with systrace sample policies (see the interestingly named Project Hairy Eyeball as an example). Also, systrace includes a policy-generation tool listing every system call available to the application for which the policy is being generated. Although an experienced system administrator could probably still tighten the security of the system by refining the default policy generated by the tool, the defaults are often secure enough for most uses.

In many ways, OpenBSD is one of the most remarkable projects in the history of UNIX. With support for 13 architectures and its emphasis on security and integrated cryptography, any system administrator that overlooks OpenBSD where server security is of paramount importance is not doing a proper job. Even if most of us prefer to run Linux on our servers and desktop, there is no doubt that OpenBSD has a rightful place in the OS ecosystem, and a rightful place in every UNIX sysadmin's toolbox.

  echo 0xFFFEFFFF ?> /proc/sys/kernel/cap-bound

  http://lwn.net/1999/1202/kernel.php3

> With a Linux kernel, you can prevent clearing these flags by
> dropping CAP_LINUX_IMMUTABLE from the Capability Bounding Set
> by doing:
>
>  echo 0xFFFEFFFF ?> /proc/sys/kernel/cap-bound

  echo 0xFFFFFDFF ?> /proc/sys/kernel/cap-bound