💾 Archived View for perso.pw › blog › articles › rarely-known-openbsd-features.gmi captured on 2024-08-18 at 17:25:49. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-05-10)

-=-=-=-=-=-=-

Some OpenBSD features that aren't widely known

Comment on Mastodon

Introduction

In this blog post, you will learn about some OpenBSD features that can be useful, but not widespread.

They often have a niche usage, but it's important to know they exist to prevent you from reinventing the wheel :)

OpenBSD official project website

Features

The following list of features are not all OpenBSD specific as some can be found on other BSD systems. Most of the knowledge will not be useful to Linux users.

Secure level

The secure level is a sysctl named `kern.securelevel`, it has 4 different values from level -1 to level 2, and it's only possible to increase the level. By default, the system enters the secure level 1 when in multi-user (the default when booting a regular installation).

It's then possible to escalate to the last secure level (2), which will enable the following extra security:

This feature is mostly useful for dedicated firewall with rules that rarely change. Preventing the time to change is really useful for remote logging as it allows being sure of "when" things happened, and you can be assured the past logs weren't modified.

The default security level 1 already enable some extra security like "immutable" and "append-only" file flags can't be removed, these overlooked flags (that can be applied with chflags) can lock down files to prevent anyone from modifying them. The append-only flag is really useful for logs because you can't modify the content, but this doesn't prevent adding new content, history can't be modified this way.

OpenBSD manual pages: securelevel

OpenBSD manual pages: chflags

This feature exists in other BSD systems.

Memory allocator extra checks

OpenBSD's memory allocator can be tweaked, system-wide or per command, to add extra checks. This could be either used for security reasons or to look for memory allocation related bugs in a program (this is VERY common...).

There are two methods to apply the changes:

The man page gives a list of flags to use as option, the easiest to use is `S` (for security checks). It is stated in the man page that a program misbehaving with any flag other than X is buggy, so it's not YOUR fault if you use malloc options and the program is crashing (except if you wrote the code ;-) ).

OpenBSD manual pages: malloc (search for MALLOC OPTIONS)

File flags

You are certainly used to files attributes like permissions or ownership, but on many file systems (including OpenBSD ffs), there are flags as well!

The file flags can be altered with the command `chflags`, there are a couple of flags available:

As explained in the secure level section above, in the secure level 1 (default !), the flags sappnd and schg can't be removed, you would need to boot in single user mode to remove these flags.

Tip: remove the flags on a file with `chflags 0 file [...]`

You can check the flags on files using `ls -ol`, this would look like this:

terra$ chflags uchg get_extra_users.sh
terra$ ls -lo get_extra_users.sh        
-rwxr-xr-x  1 solene  solene  uchg 749 Apr  3  2023 get_extra_users.sh

terra$ chflags 0 get_extra_users.sh     
terra$ ls -lo get_extra_users.sh     
-rwxr-xr-x  1 solene  solene  - 749 Apr  3  2023 get_extra_users.sh

OpenBSD manual pages: chflags

Crontab extra parameters

OpenBSD crontab format received a few neat additions over the last years.

It's possible to use a combination of flags like `-ns`. The random time is useful when you have multiple systems, and you don't want them to all run a command at the same time, like in a case they would trigger a huge I/O on a remote server. This was created to prevent the usual `0 * * * * sleep $(( $RANDOM % 3600 )) && something` that would run a sleep command for a random time up to an hour before running a command.

OpenBSD manual pages: crontab

Auto installing media

One cool feature on OpenBSD is the ability to easily create an installation media with pre-configured answers. This is done by injecting a specific file in the `bsd.rd` install kernel.

There is a simple tool named upobsd that was created by semarie@ to easily modify such bsd.rd file to include the autoinstall file, I forked the project to continue its maintenance.

In addition to automatically installing OpenBSD with users, ssh configuration, sets to install etc... it's also possible to add a site.tgz archive along with the usual sets archives that includes files you want to add to the system, this can include a script to run at first boot to trigger some automation!

These features are a must-have if you run OpenBSD in production, and you have many of them to manage, enrolling a new device to the fleet should be automated as possible.

GitHub project page: upobsd

OpenBSD manual pages: autoinstall

apmd daemon hooks

Apmd is certainly running on most OpenBSD laptop and desktop around, but it has features that aren't related to its command line flags, so you may have missed them.

There are different file names that can contain a script to be run upon some event such as suspend, resume, hibernate etc...

A classic usage is to run `xlock` in one's X session on suspend, so the system will require a password on resume.

Older blog post: xlock from apmd suspend script

The man page explains all, but basically this works like this for running a backup program when you connect your laptop to the power plug:

# mkdir -p /etc/apm
# vi /etc/apm/powerup

You need to write a regular script:

#!/bin/sh

/usr/local/bin/my_backup_script

Then, make it executable

# chmod +x /etc/apm/powerup

The daemon apmd will automatically run this script when you connect a system back to AC power.

The method is the same for:

This makes it very easy to schedule tasks on such events.

OpenBSD manual page: apmd (section FILES)

Using hotplugd for hooks on devices events

A bit similar to what apmd by running a script upon events, hotplugd is a service that allow running a script when a device is added / removed.

A typical use is to automatically mount an USB memory stick when plugged in the system, or start cups daemon when powering on your USB printer.

The script receives two parameters that represents the device class and device name, so you can use them in your script to know what was connected. The example provided in the man page is a good starting point.

The scripts aren't really straightforward to write, you need to make a precise list of hardware you expect and what to run for each, and don't forget to skip unknown hardware. Don't forget to make the scripts executable, otherwise it won't work.

OpenBSD manual page: hotplugd

Altroot

Finally, there is a feature that looks pretty cool. In the daily script, if an OpenBSD partition `/altroot/` exists in `/etc/fstab` and the daily script environment has a variable `ROOTBACKUP=1`, the root partition will be duplicated to it. This permit keeping an extra root partition in sync with the main root partition. Obviously, it's more useful if the altroot partition is on another drive. The duplication is done with `dd`. You can look at the exact code by checking the script `/etc/daily`.

However, it's not clear how to boot from this partition if you didn't install a bootloader or created an EFI partition on the disk...

OpenBSD manual pages: hier (hier stands for file system hierarchy)

OpenBSD manual pages: daily

OpenBSD FAQ: Root partition backup

talk: local chat in the terminal

OpenBSD comes with a program named "talk", this creates a 1 to 1 chat with another user, either on the local system or a remote one (setup is more complicated). This is not asynchronous, the two users must be logged in the system to use `talk`.

This program isn't OpenBSD specific and can be used on Linux as well, but it's so fun, effective and easy to setup I wanted to write about it.

The setup is easy:

# echo "ntalk		dgram	udp	wait	root	/usr/libexec/ntalkd	ntalkd" >> /etc/inetd.conf
# rcctl enable inetd
# rcctl start inetd

The communication happens on localhost on UDP ports 517 and 518, don't open them to the Internet! If you want to allow a remote system, use a VPN to encrypt the traffic and allow ports 517/518 only for the VPN.

The usage is simple, if you want alice and bob to talk to each other:

This is a bit archaic, but it works fine and comes with the base system. It does the job when you just want to speak to someone.

Conclusion

There are interesting features on OpenBSD that I wanted to highlight a bit, maybe you will find them useful. If you know cool features that could be added to this list, please reach me!