This is barking up the wrong tree.
Using IFUNC to patch sshd was kind of elegant, it achieved rootkit like behaviour with a pre-existing mechanism. And sure, it might be possible for a secure daemon like sshd to drop enough privileges that it could protect itself from a malicious dynamically linked library.
But IFUNC was not required, neither was systemd. The game was lost as soon as the attacker had arbitrary code installed in a semi-common library. It doesn't have to get linked directly with sshd, it only needed to be linked into any program running as root, at least one time.
Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.
IFUNC, systemd, and the patched openssh are all irrelevant to the issue, that was simply the route this attacker took to leverage their foothold in libxz. There are thousands of potential routes the attacker could have taken, and we simply can't defend from all of them.
> Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.
I do not understand how you even expected sshd to sandbox itself. Its entire purposes is to (a) daemonize , (b) allow incoming connections in and then (c) forward (possibly-root) shell statements. All 3 things are 100% required for sshd and would have already allowed an attack like this. Any talk about sandboxing here (or dropping privileges) is wishful thinking.
I recently tried to make something properly sandboxed and, my goodness, we have basically crafted an ecosystem where everything needs access to everything. No wonder docker, despite all it's faults, is how everyone does it. You need an entire linux distro completely accessible in your sandbox.
It was not essential to the exploit, but that does not mean it was irrelevant. More commonly used libraries are watched harder. The exploit was made much, much, worse by its indirect use by way of systemd. Approximately nobody wanted that feature and it still went in. That's something we need to be able to discuss.
But the fact that it was done indirectly from systemd has nothing to do with IFUNC.
Did anyone look into whether OpenBSD has privilege separated sshd enough for that exploit to not be possible?
OpenBSD exposes pledge() and unveil(), which allow programs to only access things they declare they need. So, even if the running SSH process gets exploited, it can't do anything the user it's running as can't do. sshd afaik runs as a root process which after authentication forks into another process, running as the target user.
There is always selinux if we want to add protection against arbitrary code running as root. Just because something operate as root does not mean it must have privileged access to everything.