OpenBSD Tips and Tricks

Getting the most out of your OpenBSD setup.

OpenBSD as an operating system is both secure by default and very versatile. However, there's always some potential room for improvement even in just the base install.

Before reading this article, if you want to harden your OpenBSD setup for security, you should read the following article from Solene: OpenBSD workstation hardening As some of the advice here is based upon her work, which will be referenced throughout this article.

Some of the advice in that article is extreme, but can be useful depending on your situation. Always consider your threat model before taking any steps with hardening your system. OpenBSD is secure by default, so you may not want to modify anything at all.

To wxallowed or nowxallowed, expanding W^X to the entire system

OpenBSD was one of the earliest operating systems to implement a W^X security policy into their base system. This basically prevents security issues that arise from how other operating systems at the time would allow a program to write instructions to an area of memory meant for data and execute said instructions. This opens up a potential attack vector for malicious applications to harm your computer.

While OpenBSD enables this feature for the base system, it doesn't enable them for packages installed from the package repository or the ports tree, and for good reason. Some applications still don't work properly with mandatory W^X enabled. Thus, the solution is to disable it for these programs by default.

OpenBSD does this by enabling the "wxallowed" flag on the /usr/local slice of your OpenBSD partition. However, there are potential security benefits to disabling it but also potential for breakage.

To do this, all you need to do is remount your /usr/local slice with the nowxallowed flag like so:

# mount -u -o nowxallowed /usr/local

If this command showed no errors, now would be the perfect time to test all of your important applications. Usually, programs that are incompatible (written improperly) will crash. If any of your important programs are no longer working correctly, then you can roll back the change with this command.

# mount -u -o wxallowed /usr/local

This will restore wxallowed to /usr/local, just like the default configuration.

Committing to nowxallowed

The problem with this approach is that it won't survive a reboot. This is because it's still enabled within the /etc/fstab file. Your fstab stores the configuration for each partition or slice that is to be mounted at boot time.

If you decide to apply this change long term, here's how to edit your /etc/fstab to make it permanent, even across reboots.

Run the following command in your terminal as root (or using doas)

# vi /etc/fstab

You can of course, replace vi with your text editor of choice.

Find a line that looks something like this

{insert uuid here}.h /usr/local ffs rw,wxallowed,nodev 1 2

and remove the wxallowed, making it look more like this:

{insert uuid here}.h /usr/local ffs rw,nodev 1 2

Using the same commands that you were taught for testing nowxallowed, you can also temporarily re-enable it and disable it when needed. This means you can disable wxallowed by default, and turn it back on when needed. But if you want to do it this way, remember to turn it back off when you're finished.

But if you need to toggle it frequently, it's probably best to revert your fstab file back to the default configuration.

Firewall tweaks

This block is based on advice from Solene's article

By default, OpenBSD's firewall blocks stateless traffic and lets anything pass out. This may be fine on a trustworthy home network. But on a server or even a laptop that you travel with, basically any situation where you cannot 100% trust the network you're connected to or any device on the network, you need to block all incoming connections except those you specifically require.

I'm not going to teach you how to use pf (the firewall included with OpenBSD), but if you want to have a truly secure system it is important to know how it works. If you don't know how to use pf, you can read the user's guide here

Basically, what you need to do is edit your /etc/pf.conf file with the following:

Replace:

block return pass

With:

block drop all pass out inet pass in proto icmp

You can also use 'block all' instead of 'block drop all' if you want to explicitly reject the packets instead of dropping them as if the system had never received them.

This should block all incoming connections except for ICMP for necessary communications with the network itself, and allow all outgoing connections. This may not be the most secure configuration for every situation, but it should work in most everyday desktop scenarios.

Auto updates

Though Solene does suggest a method for doing this here, I don't entirely agree with her method.

She suggests you install the anacron package to your system, even though OpenBSD comes with a perfectly good cron daemon by default. While I'm not here to question the efficacy or the superiority of anacron over OpenBSD's cron, I simply don't see why a third party package is necessary in this case.

In fact, you don't even need to edit a crontab file, since there's an /etc/daily script on the system already configured by default. But, you shouldn't edit that file directly.

Instead, create the file /etc/daily.local in order to have custom commands run every day. Don't worry, the system is already configured to run this file if it exists.

Your /etc/daily.local file should contain the following:

syspatch pkg_add -u

After saving your daily.local file, run the following command to ensure the permissions are correct.

# chmod 0644 /etc/daily.local

NOTE: If you're currently using a development snapshot version of OpenBSD instead of a release or stable version, you should use sysupgrade -ns instead of syspatch as the two branches are updated differently. You may also want to append fw_update to the file if you're using a snapshot to ensure that you proprietary firmware blobs are up to date in order to ensure continued hardware functionality.

NOTE: Sometimes, syspatch may require the user to reboot in order to apply the latest security fixes and to boot a newly re-linked kernel. This method of auto updates will prevent syspatch from informing you of such events. It may be wise to reboot occasionally to ensure that your system is truly up to date. This is usually never the case for packages, but you may need to restart any affected daemons via rcctl

Running Linux (and maybe Windows) Applications

There comes a time where you have a particular program that you must run, and it simply won't work on OpenBSD. Maybe it's a proprietary application that can't be recompiled, or the source has a bunch of Linuxisms and can't be easily ported.

You may have heard that OpenBSD has a Linux compatibility layer. Unfortunately, that information is outdated since it was removed around version 6.0. There is still a way to run Linux programs through virtualization, but it has numerous drawbacks that prevent it from being useful for computationally heavy tasks.

These things can be showstoppers when running a virtual machine under OpenBSD's VMM hypervisor:

• No support for multiple virtual processors
• No graphics support, requiring either VNC or X11 forwarding. Neither of which have hardware acceleration
• Lack of graphics support means the only naively accessible interface is a virtual serial console, which can cause issues when trying to install or boot certain distros.
• Lack of graphics support also means no Windows. macOS, Haiku, etc.

Unfortunately, VMM is the only option on OpenBSD. There's no VirtualBox, no VMWare, no Xen, or any type 2 hypervisors available on OpenBSD. Qemu is available in the package repository but it can't be used with VMM like you can use it with Linux and KVM, meaning Qemu can only do software emulation, which is extremely slow.

Instead of regurgitating official documentation by explaining how to set this up, I'll link to to the official FAQ page for virtualization on OpenBSD.

However, what I will say is that I would personally recommend choosing either Debian, Devuan, or Alpine as your distro as I know these to work. Ubuntu should work too so long as you don't expect to use the desktop.

Personally, I prefer to use Alpine with distrobox to run whatever distribution I need at any given time. This gives me the flexibility to use whatever package I need in whatever environment I chose to run it in (with limitations of course) without having to manage multiple VMs or worry about if the target distro will even work in vmm. However, the details of that are for another article.

The best way to interact with your new Linux VM is to have networking enabled in some form, and run an SSH server inside the guest operating system. Be sure to enable X11 forwarding via sshd_config if you need to run graphical applications and make sure xauth is installed to the guest as well.

Conclusion

These tips should improve your experience with OpenBSD, but as with anything calling itself "tips and tricks" you should ensure that it won't cause any issues that you either cannot fix without totally reverting the change.