alt Hacker NewsMaybe I'm misunderstanding the video, but it looks to me as if the situation is:
You are root inside a sandbox. As root-in-the-sandbox, you create a symlink and this gives you the ability to escape the sandbox.
(Whether this is interesting or not depends on whether anyone actually tries to use the sandbox facility in such a way as to give root-in-the-sandbox privileges to untrusted people or code. I don't know enough about OpenBSD to answer that.)
Replies
OpenBSD doesn't do different user accounts inside vs outside sandboxes; if you're root in the sandbox, you're root on the system.
So what? You're still root. You're relying on a sandbox to plug a few voids while you still effectively held keys to the kingdom before said voids were plugged.
I hear this excuse daily from developers who insist on running all their docker containers as root "because we have to".
If you're relying on a sandbox as your first line of defense you've already lost the war.
unveil was designed and intended to effectively sandbox root when combined with sufficiently strict pledge permissions. I don't think this exploit would have effected any existing OpenBSD services, but sometimes services need to keep around processes with higher privileges than the network-facing process, yet you still want to sandbox them as much as possible. For example, sshd uses a special auth process, and that process needs higher privileges to be able to access the password database. On OpenBSD this auth process doesn't need root, but there may be similar cases where you want to use unveil with a root process for defense-in-depth. Suffice it to say, it would be foolish to only use unveil with such processes.
The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.