CLONE_NEWUSER doesn't actually change what your user is outside of that container/namespace. You get to map exactly one outside user to exactly one inside user. On systems where unprivileged users are permitted to call it, you can map your host user account to exactly one account inside the namespace, of which root is basically the only useful choice. Any interactions between the namespace and the rest of the system continue to treat you as your original UID.

The original implementation of CLONE_NEWUSER did actually convert users to vectors, or at least namespace-user tuples, which would have allowed unprivileged users to use the kernel UID mechanism for actual privilege separation. But that was dropped, I believe mostly because it was too much churn to the rest of the kernel and thus too risky. The current approach means that code that just thinks about root-namespace users continues to do the right thing.

The primary thing Chromium's sandbox seems to gets out of CLONE_NEWUSER is the ability to call chroot without shipping a setuid binary.

Oh, of course you're right. I implemented this stuff in gaol and completely forgot I had to stay as root inside the namespace because you can't setuid to unmapped users.

I stand (embarrassingly) corrected.

I've never heard of CLONE_NEWUSER before, it looks interesting. I don't think it's in FreeBSD.

My concern is that you can clearly browse and save files, so there is something that has access. Maybe it's much more secure than I thought, but I tend to be really skeptical towards programs of such length being perfectly secure.

CLONE_NEWUSER / user namespaces is Linux-specific, yes. (Though see my other comment.)

I believe the Chromium sandbox mostly applies to things like renderers, where you can just hand it a buffer and a bunch of inputs and it'll effectively contain things like HTML parser bugs or libpng buffer overflows. I'm not totally sure if browsing itself is sandboxed.