I'd heard that there were some.. risk of increased attack surface, lets say, by allowing userland access to namespaces for devices/mount points, but I'm not familiar with what this would really look like. What could be done to mitigate these security concerns so that everyone is comfortable enabling it?
"increased attack surface ... but I'm not familiar with what this would really look like"
There's a related LWN article on this called "Anatomy of a user namespaces vulnerability" [0].
Basically, the kernel has a bunch of places where it checks for various capabilities. Unprivileged usernamespaces let you gain various capabilities in a limited fashion, but those limitations are based on the kernel itself recognizing that you only have those capabilities in said limited fashion.
For an easy example, a root user in a usernamespace (aka an unprivileged user on the host) is allowed to mount a new tmpfs in their namespace, or mount proc... But it's still not allowed to mount /dev/sdx since that device belongs to the real root user.
Necessarily, that means there are different ways to check if someone has permission than the simple "is the caller uid 0"; there has to be for tmpfs "are they CAP_SYS_ADMIN in their current namespace", while for /dev/sdx it has to be "CAP_SYS_ADMIN in the root namespace".
It simply amounts to there being more total codepaths that an unprivileged user can reach because, for example, they can now pass the tmpfs mount check (intentionally), and perhaps there's a mount option that wasn't fully thought through.
"What could be done to mitigate these security concerns"
Docker's seccomp filters would have actually stopped quite a few exploits here by totally gimping user namespaces to be useless. So yeah. maybe that's not the answer.
There's really not an answer though. You can't prove something is secure and bug-free. It has been a while since a really meaningful userns exploit and there are a lot of people that believe it to be a useful thing to have.. a bunch of distros have enabled it. People are still wary because of its history. I think at this point all that's left to mitigate these concerns is time. The implementation isn't likely to change drastically any time soon.
