Security by Correctness

OpenBSD has a reputation for being a secure operating system. In fact, its website boasts just two security holes in the default install "in a heck of a lot of time." That said, the development policies are not focused on producing a secure operating system as much as they are aimed at creating a correct operating system. Security is just a side effect.

OpenBSD has therefore an aggressive policy towards removing obsolete code. For example, libressl, the SSL/TLS library OpenBSD uses instead of the popular openssl, lacks many encryption algorithms deemed outdated. OpenBSD also has a zero tolerance against binary blobs or any software that cannot be audited, which is never included by default, because it cannot be trusted and it is harder to fix if problems arise.

OpenBSD also uses its own libc, which is not compatible with the popular glibc to be found in the Linux world. This makes running certain programs designed for Linux a bit troublesome at times. For example, some C programs that use the custom crypt() function in glibc won't work without patching. On the other hand, OpenBSD's libc has its own extra utilities, such as crypt_newhash() (for generating Blowfish hashes from passwords in a single step) or arc4random() (for generating random data when /dev/urandom is unavailable).

Security by Isolation

Linux has plenty of tricks up its sleeve in order to isolate processes from each other, just in case one of them was hacked by a nefarious actor. BSD has its own set of security tools (Figure 2). In the Linux world, tools such as SELinux, AppArmor, and seccomp are used to ensure that no process can access resources that it was never intended to access. This way, if a daemon such as the Apache web server is compromised, the attacker cannot easily access information managed by the cupsd printing service, for example.

Figure 2: Instead of Linux's netfilter, which is usually configured via iptables, OpenBSD uses the minimalist PF firewall.

For years, it was a common complaint against OpenBSD that it lacked a proper Mandatory Access Control (MAC) framework. Although there was some work done in this regard, it was abandoned because it was considered impractical and there was just not much interest in it. From the OpenBSD perspective, MAC frameworks such as SELinux are too unwieldy to use by regular administrators and are more likely to cause problems than to solve them.

The standard way in which processes used to be isolated in OpenBSD was by placing them in a chroot() jail and running them with reduced privileges. As security conscious administrators know, chroot() is not a great security feature, because a process running with root privileges inside of one can easily escape the chroot as per the POSIX standard. Although running the process with reduced privilege solves this problem for the most part, this approach had its drawbacks. Therefore, OpenBSD ended up creating two additional isolation techniques: unveil() and pledge().

Both unveil() and pledge() are system calls that reduce the privileges of a process. The idea is that when a trusted process is started, it will tell the kernel that it plans to access only a certain set of resources. Attackers often use a compromised process to access resources the process was never intended to use. Unveil() tells the kernel which parts of the filesystem the program intends to use (Figure 3), and pledge() which set of system calls. The unveil() and pledge() system gives the kernel the information necessary to stop a rogue process from accessing unauthorized resources and generate a warning for the logs to record.

Figure 3: A process may use the unveil() system call to place itself in a filesystem sandbox. If the process is compromised later on, it won't be able to access files outside of the sandbox.

The problem with this approach is that any given program must be patched to use these two system calls in order to be effective. However, the OpenBSD and ports maintainers seem to be doing a good job with patches for popular applications such as Mozilla Firefox. The advantage is huge: The user gets to run programs that put themselves in a virtual sandbox without the need of any configuration. The process is completely transparent to the user.

Userspace Goodies

OpenBSD is home to a number of outstanding userspace tools. OpenSSH [6] is indeed the most popular tool associated with the OpenBSD community. It has been ported to a number of other operating systems, and Linux administrators use it worldwide to access remote servers from their home. However, OpenBSD develops many other programs that are worth a closer look.

httpd, for example, is a compact web server that aims to be simple yet useful. It supports FastCGI (and slow CGI, for that matter), TLS, and request rewrites. It is easy to configure, and it is well documented. Its biggest drawback is that it is not compatible with htaccess files, which are often distributed with web applications such as Nextcloud and are intended to be used with the Apache web server instead. This limitation does not mean that OpenBSD's httpd cannot host Nextcloud. In fact, it is a good platform for this sort of application. It just means the administrator has to rewrite the hstaccess rules in a format httpd understands. A webmaster who is not up to this task can always install Apache from the repository instead.

OpenSMTPD [7] is the OpenBSD alternative to SMTP servers, such as Postfix or Exim (Figure 4). It can be deployed with anti-spam filters, antivirus filters, and DKIM.

Figure 4: OpenSMTPD lets you deploy an SMTPD (email) server. The configuration is very simple, especially if compared with popular alternatives.

OpenBSD has its own X server, known as Xenocara, that doesn't require root privileges (Figure 5). relayd is another little gem. It is a daemon that can be used both as a reverse proxy, TLS accelerator, load balancer, and switch-over device for high availability applications.

Figure 5: OpenBSD uses its own X server, which runs without root privileges. The default window managers are spartan, but you can install modern desktop environments such as KDE or Xfce from the repository.