OpenBSD

To wrap up this series of posts on security tools I’ve written for use on OpenBSD, I want to reiterate how the components work together, and how they raise the cost of attack. The tools together provide a way for protecting against unauthorized or accidental change (syslock), detecting unauthorized change (sigtree.pl), detecting unauthorized or unusual activity (reportnew), distributing authorized changes securely with verification (distribute.pl, install.pl, and Signify.pm), and moving data securely (rsync-tools). ...

This final post (apart from a wrap-up) is about the largest and most complex script, a 6,253-line file integrity monitoring program called sigtree.pl, first written in January 2000. It was inspired by the original free version of tripwire and by OpenBSD’s mtree, in the OpenBSD daily security script to compare a specification of file attributes and report divergences, mainly for checking permissions on key system files. One of the main issues with tripwire was keeping it up-to-date and the high volume of regular, expected changes. The modern solution to this issue is ensuring that changes are authorized/expected and that configurations meet policies rather than verifying file hashes. I think that is a better solution for enterprises, but I developed an alternate solution that keeps the granular monitoring and relies on the fact that I’m my only administrator and recognize my own changes. That solution is a dual-specification model, where I have a primary specification for each system and a secondary one, where the secondary one is automatically checked, changes reported via email, and then updated each night, so I get a daily report of changes per host. The primary specification is updated less frequently and manually, either weekly or every few weeks. ...

The next tool in the series, reportnew, is the oldest (first written in February 1999) and one of the largest and most complex (currently almost 4,500 lines of code, though it was only 500 lines in June 2003). Much of that gain has been in the last year; in May 2025 it was just over 2,400 lines. In this post I’ll describe why I wrote it, what it does (so far as I am aware) uniquely, and how I use it. ...

Now that I’ve covered two building blocks – syslock for managing immutable flags and rsync-tools for moving files around – in this post I’ll discuss more recent tools that put those together in order to manage the distribution of files across my systems. I originally looked at using something like puppet or chef to manage configurations on my hosts, but they both seemed overly complex for my needs and neither was built to handle my environment with immutable files. I decided to build a tool to install updates, thinking that perhaps I could set it to run automatically on a reboot by calling it in /etc/rc.securelevel before the system securelevel is raised, but in practice I’ve just used it manually. ...

The last post was about a tool for locking and unlocking files using immutable and append-only flags; this one is about copying files from one place to another, between hosts or (sometimes) on the same host, as a building block for automations without creating unnecessary security exposures. Both of these components will be used in later tools. rsync Basics rsync is a common tool used for efficiently copying files and directories from one location to another, including between systems and for backup purposes. I’ve used it for almost as long as I’ve been managing home systems. The base use case is to synchronize files owned by the same user, but for my main use cases, distributing administration-related configuration files and performing backups, more access is required. Since I don’t allow root logins, I need a non-privileged remote user with enough access to deploy files where they belong and to copy everything I want backed up. The most common way to restrict a non-privileged remote user to specific functions is to limit it to specific authorized commands that can be sent via SSH (secure shell), and to configure sudo or doas on the remote system for that non-privileged user to allow it to do what it needs to do, as specifically as possible. Specific commands are defined in the destination user’s .ssh/authorized_keys file. I used to use a very simple wrapper on the remote side that would only allow rsync to run, but came to the conclusion that I wanted stricter controls that limited what rsync could do. (An alternative tool for restricting remote SSH commands that I came across during research for this post is sshdo.) I set up a non-privileged user, _rsyncu, on each host where it’s needed and use separate SSH keys with specific commands for each specific function, and define privileged commands that it might need to execute, as narrowly as possible, using doas (I formerly used the more popular sudo but switched to doas when OpenBSD did; it is simpler and has had fewer vulnerabilities) ...

If you missed the overview post, you can see it here. This one is about managing immutable and append-only files on *BSD, Linux, and macOS. Immutable and Append-Only Files BSD-derived operating systems (including macOS) and Linux both support the concept of files being made immutable, so that neither their contents nor attributes can be changed. They also both support files being made append-only, so that the existing contents cannot be changed except by adding more data to the end. They do it in slightly different ways. ...

I’ve been using and administering OpenBSD systems since 1999 (OpenBSD 2.5). During that time, I’ve written numerous scripts to make things easier, more automated, or more secure, or sometimes just to improve my understanding of how things work. When I started managing my home systems, I ran several Internet-exposed services on my home network (DNS, mail, web, SSH). I used djbdns, qmail, and Apache httpd at the start before switching to nsd/unbound for DNS and postfix for mail, and finally to OpenSMTPD for mail. When I got tired of excessive inbound traffic I moved my authoritative DNS to a provider while keeping an internal zone and resolvers, and set up two cloud servers for mail and my public webserver. My home network became a hardened, minimal-exposure architecture that only allows Wireguard from expected sources and mail (after mutual TLS authentication with certificates) while continuing to run internal services. ...

 OpenBSD 5.9 (current as of this post is 7.5) introduced the "pledge" system call and 6.4 introduced the "unveil" system call, which together provide a means of more granular control of system access by processes running on the system to enforce least privilege.  When a program calls "pledge", it provides a list of categories of system calls (called "promises") that it is planning to make during the life of the running process (children have to make their own pledges and are not restricted), and attempts to make calls outside of those areas will cause the call to be blocked and the process to be killed. Additional calls to pledge cannot add new categories but it can remove them, so access can become more restrictive but not less restrictive. ...

 Unlike ChatGPT, Bard pretty much nailed it on the initial prompt. (However, Bard refused to answer my questions about the Mars Effect like the ones I gave to ChatGPT, even when reworded to be clear I was asking for descriptions of what the effect is and what explanations are offered rather than asking it to identify causes itself.) It does lose points for grammar in the second sentence, though! write a few paragraphs explaining immutable flags in OpenBSD including the commands for setting them and the difference between system and user immutable flags Sure. Here is a few paragraphs explaining immutable flags in OpenBSD, including the commands for setting them and the difference between system and user immutable flags. ...

 I was thinking about writing a blog post about file system immutability flags in OpenBSD, and thought I'd ask ChatGPT to write it for me. It appears to have gleaned its content from OpenBSD man pages, but it is highly misleading and inaccurate, misrepresenting the key distinction between system and user immutability flags. What it got right is that only the superuser (root) can set and unset the system immutability flag (schg/noschg) while users (if they own the file) can set and unset the user immutability flag (uchg/nouchg). But either flag can be set or unset on any kind of file. ...