[3form]

So, a break out of chroot in a chroot jailed app would be a non-issue because I need root to set it up?

[yjftsjthsd-h]

If you need root to set up the escape, then yes that is relatively uninteresting. Like, we know chroot can't contain root.

[3form]

Thanks. It was not evident from the example whether root inside of the sandbox is necessary - I assumed creating arbitrary symlinks doesn't require any particular capabilities, and there's nothing special about the locations.

Though it's not clear to me now:

- why was this patched then?

- is the point about root that non-root wouldn't have access to passwd anyway?

[ori_b]

OpenBSD doesn't have separate user accounts for sandboxes. These sandboxes are not linux-style containers, they're narrowed views of the full install.

If you're root inside the sandbox, you're root outside it. This exploit requires you to already be root.

[3form]

But the issue of root and accessing outside of the sandbox is orthogonal, no? Even if you're logged in as XYZ, accessing XYZ's contents outside of the sandbox is still a breach and a problem. Or does this issue require actual root to manifest?

[ori_b]

This path was special cased used to allow restricted applications to access time zone files, which are needed for time functions. Not any symlink will do, it has to be the specific one shown in the example exploit, or one of a small handful of others that were special cased for similar reasons. The place these symlinks live are owned by root. This is the same root user outside the sandbox as inside it.

So, yes, you need to have root on the box to set up this exploit.

[3form]

I see, thank you for your time and patience spent to explain this. So there's no elevation, no general escape, and this got patched because it could possibly be used as a set-up-use-later backdoor style thing (such as dropping a setuid root binary somewhere in the OS). Yeah, not a thing I would use as an argument that it's a terribly insecure system.