Random relinking at boot comes to httpd(8) and smtpd(8)

Random order relinking of critical components is an OpenBSD feature specifically designed to make it harder to exploit bugs in the resulting binary. sshd(8) was the first of the network-facing daemons to get the random treatment (see this previous report).

Now in a series of commits that split one daemon (smptd(8)) into six separate binaries, Theo de Raadt (deraadt@) is bringing httpd(8) and smptd(8), both common in network facing configrations, into the random relink at boot fold.

httpd(8) was the first of the two:

List:       openbsd-cvs
Subject:    CVS: cvs.openbsd.org: src
From:       Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date:       2026-06-04 5:34:53
Message-ID: 162ecce711460607 () cvs ! openbsd ! org

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2026/06/03 23:34:53

Modified files:
	usr.sbin/httpd : Makefile 

Log message:
httpd worries me a bit, so I want to random-relink it at boot.
The new /etc/rc relinking components will automatically pick up this
new directory and process it.

and the sequence ended with a description of the operations on smptd(8):

List:       openbsd-cvs
Subject:    CVS: cvs.openbsd.org: src
From:       Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date:       2026-06-04 5:43:00
Message-ID: 162ecd0f03b93f85 () cvs ! openbsd ! org

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2026/06/03 23:43:00

Modified files:
	usr.sbin/smtpd : Makefile smtpd.c 
	usr.sbin/smtpd/smtpd: Makefile 
Added files:
	usr.sbin/smtpd/smtpd: Makefile.inc Makefile.inc.orig 
	                      Makefile.orig 
	usr.sbin/smtpd/smtpd-ca: Makefile 
	usr.sbin/smtpd/smtpd-control: Makefile 
	usr.sbin/smtpd/smtpd-dispatcher: Makefile 
	usr.sbin/smtpd/smtpd-lka: Makefile 
	usr.sbin/smtpd/smtpd-queue: Makefile 
	usr.sbin/smtpd/smtpd-scheduler: Makefile 

Log message:
smtpd was already fork+exec privsep, and starts 6 copies which are
the same binary.
I first decided to random-relink smtpd because of some recent close
calls (in the IPC codepaths, which could have played part in lateral
movement following a primary hole).  Then it dawned on me that I can
random relink each of the privsep binaries to be unique, in the same
style as sshd.
Each binary now contains a lot of code it does not need (and is not
reached, but the code remains).  That can be refactored as a later
step.
The new /etc/rc relink code will automaticall pick these up.
vague approval martijn, gilles, millert

The addition of random relinking for httpd(8) and smtpd(8) relies on recent work providing a generalised mechanism for boot-relink objects:

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2026/05/27 07:48:56

Modified files:
	share/mk       : bsd.prog.mk 

Log message:
A new variable (RELINK) makes rules for creating a relink tar file and
installing it in the correct place.  The variable needs to be a test
command which verifies the re-linked binary works correctly, which
requires it to exit(0).
This 1-liner will replace the large adhoc relink tarfile production
in the Makefiles of various relinked programs.

sshd(8) [and friends] were adapted to the new mechanism:

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2026/05/27 07:57:26

Modified files:
	usr.bin/ssh/ssh-agent: Makefile 
	usr.bin/ssh/sshd: Makefile 
	usr.bin/ssh/sshd-auth: Makefile 
	usr.bin/ssh/sshd-session: Makefile 

Log message:
Use the new RELINK feature in bsd.prog.mk to build the relink kits.

The code with the newly split binaries should land in snapshots on a mirror near you soon, and may already be available to test.